There are numerous reasons why most robots
you see are clunky and slow. In a nutshell, this is to make them
predictable and human-safe, which pretty much trumps everything else.
I will try to outline and motivate some of the design decisions that
make robots slow and clunky in general. I don't particularly agree with a
lot of these but I can see why people chose them (mainly cutting costs
and falling back on good ole reliable albeit clunky technology where
possible). Feel free to disagree, and correct me where I'm wrong.
-----------------------
Mechanics: High weight + unpredictable actuator performance => Clunky robots.
1. Safety issues: Robots like the Pr2 are heavy and powerful and can break your head.
Design reasoning: Making really slow robots is the easiest way to ensure that they don't break your head.
Alternatives : Good control algorithms (hard to implement properly and
require custom hardware; more on this later), lightweight materials
(expensive, hard to source correct parts, and much harder to machine).
2. Power issues : Heavy robots => Powerful motors (~100s of Watts)
=> Heavy batteries + amplifiers + I/O electronics + voltage
transformers => Heavier robots.
Design reasoning: In a
nutshell, you can cut corners here and there but once you decide to make
a slow heavy robot, you need heavy electronics to move it.
Alternatives : Non-electric actuators like pneumatic muscles etc. (much harder to control).
3. Actuation mechanism : The Pr2 uses a belt to transmit forces from
the motors to the joints. Belts are hard to control at high speeds
because of unpredictable flexion etc.
Design reasoning: Belts and cable drives are good for transmitting forces over weird angles and distances in confined spaces.
Alternatives: Some really well thought out actuator design (I'm not the expert here).
4. Gravity compensation : A common theme in robotics is to gravity
"balance" robots, which means to counterbalance limbs with weights so
they don't just fall over. But it also double's the robot's inertia.
Some gravity compensation is necessary and there is a tradeoff between
high inertia vs. doing less work against gravity. The tradeoff is
problem specific, which makes it hard to build general purpose robots.
Design reasoning: Gravity balanced robots don't fall on you if there is a power outage. They also do less work against gravity.
Alternatives: Can have some actuator-brake combinations that achieve
the same result, but those are bleeding edge, expensive and hard to
control. And/or robots with detachable limbs etc. but those are
complicated as well.
5. Performance issues: A light mobile
robot will vibrate, shake in the wind, introduce dynamic coupling
between limb motions and the base etc etc. So make it heavy.
Design reasoning: Dealing with weird unpredictable vibrations due to
external causes is hard. Controlling a heavy robot is much easier.
Alternatives: Lets just say that better control algorithms can and
should handle this stuff. And this is an area of active research.
-----------------------
Control: Inelegant (read inefficient and hacky) algorithms typically
require powerful computers => Powerful computer (100s Watts) =>
Heavier batteries => Clunky robots.
1. Humanoid robot
control algorithms: Controlling robots is a complicated problem.
Controlling them during fast motions requires modeling the dynamics,
which makes the problem much much harder. Moreover, while interacting
with humans, robots must respond in real time. Hence the controller must
react fast enough to prevent collisions etc.
Design reasoning:
Slow down the robot to give it time to react to unforseen
circumstances. Having the computer on the robot is necessary to prevent
wifi control signal jitter and delays.
Alternatives: High
performance torque control (much faster algorithms). This is a long
discussion, but in short, the algorithms are complicated, they require
expensive torque sensors, low level access to the motors and sensors,
and very fine engineering. The Pr2 is just not designed for this stuff.
The DLR lightweight arm is much better. Search youtube for the Justin
robotic platform.
2. Vision: Need high speed vision to prevent unwanted collisions
Design reasoning: Vision sensors are slow (10-100 Hz).
Alternatives: There are high speed vision neuromorphic sensors, but
they are very new technologies [Read Tobi Delbruck's work]. And they are
low resolution at the moment.
3. Touch: Most robots don't have
touch sensors. So touching or grasping anything is vision based,
requires a lot of precision, and is really really slow.
Design reasoning: Touch sensors are expensive, hard to place on curved surfaces, and even harder to monitor all the time.
Alternatives: Well, just add touch sensors and soft skin, which will
enable a whole new variety of super-fast safety mechanisms.
I've worked a fair bit with the PR2, and I think it comes down to this:
1) Industry robots, like many answers above this correctly said, are
typically engineered to do just one thing - and do it well. The
humanoid robots built for research sacrifice speed for diversity.
2) Industry robots also rely on external sensors tailored to the task.
In a typical PR2 video, you will see the robot use laser/camera for
feedback. A lot of the research videos you see are typically meant to
show proof of concept of some particular task, and not necessarily to
make the whole system run fast. For example, in my lab we were
investigating autonomous laundry folding - for some of the videos the
emphasis was on the PR2's ability to reason about folding, and not about
real time vision per se. So we don't try too hard to make it go as fast
as possible.
3) Specifically, if you increase joint speeds on
the PR2, the arms just go crazy and vibrate a lot whenever they reach
the target. The controllers are not designed for super quick motion.
There are two solid reasons for this.
First, the factory robots are performing pre-programmed actions without
visually verifying the location of what it's working on. This means
that there is almost no computation done to ensure alignment between
each action. You think that the spot-welder robots are looking to make
sure that the car is still in the right place between zapping each weld?
Nope. There's a sensor that makes sure the car is in the right place,
and then a blind robot goes through all of the pre-programmed actions.
This is only possible because all of the cars on the line are exactly
the same shape.
Second, factory robots are production
generation products. When software goes into production, considerable
effort goes into making sure that it's running as efficiently as
possible. When a robot is going to do something a hundred thousand
times, it is more time-saving to make sure it's not wasting effort in
advance. With research robots, they are mostly just proving that the
robot can do it at all. Efficiency can always be achieved later if
someone decides that it is a practical behavior for the robot.
To specifically address "can't the stepper motors move faster", that is
an optimization. Having a motor that moves at multiple speeds is a
distinct optimization that a researcher wouldn't bother with because
it's one more complication getting in the way of doing it at all. An
efficient robot wouldn't use the same speed for putting its arm back in
the "out of the way resting" position as it would use for picking up a
beverage. Given that, they know that the slowest speed will work for
everything, so they just use that.
My R&D mantra is this:
Do it once, do it right, do it well. In that order. If you try to jump
straight to "do it well" you'll never even make it to "do it once".
If you want to get more about Industrial Robot，Industrial Robot manufacturers or suppliers, Industrial Robot for sale, please follow http://en.ofweek.com/Industrial-Robots-10011808
沒有留言:
張貼留言