Search for questions, people, and topics Sign In

RELATED TOPICS Why are humanoid robots physically slow moving RELATED QUESTIONS

Companies,
compared to industrial robots? Are there any industrial or military robots
Products, and Is it a computation/sensing bottleneck or hardware bottleneck? based on Microsoft Robotics platform?
Services For example the willow garage pr2 is 6 to 20 times slower to complete a task
compared to a human: What are the technological obstacles to
Products creating biped (humanoid) robots?
Equipment
What are the key Architecture, UX and
Machines Development components required for
building humanoid robot platforms?
Robots
Would you have a problem destroying a
clone or destroying a sentient humanoid
robot?

What are the top humanoid robotics
platforms for research?

What programming language is used to
control industrial robots?

Robotics: Who are the foremost
roboticists in the world and what are
some of the projects that they are
While industrial robots can preform tasks faster then a human.
working on right now?
I realize that a industrial robot is pre­programmed and has a much simpler task
then a sensing "real time" interaction robot but what specifically is the limiting Can a killer humanoid robot be created
factor? for military use with the current
technology?

Question Update: Robotics: How can I start with my thesis
The question specifically refers to mechanical movement speed not technology on Bipedal Humanoid Robot? What basic
progress.  I should learn first?
For example, the video posted above (1:40) shows a sequence of the robot
Robotics: Can we combine
opening and manipulating bottles. The sequence is sped up 5 times yet the
microprocessors and AI to build a
movements are still slower compared to a human.
humanoid?
The core of the question is: why can't the robot simply move faster? Is it because
the stepper motors can't be fast and precise at that size?
Re­Ask Follow 34

10 Answers
Samir Menon, Doing my Ph.D. in robotics, control theory, and
computational neuroscience
Upvoted by Sid Hazra, worked for RI/CMU

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.

­­­­­­­­­­­­­­­­­­­­­­

Justin, below, tries to address a lot of the points above, and is a much better
implementation overall:

 2,180 views • 31 upvotes • Updated 1 Oct, 2012
 
Upvote 31 Downvote Comments 4+

More Answers Below. Related Questions

Are there any industrial or military robots based on Microsoft Robotics platform?

What are the technological obstacles to creating biped (humanoid) robots?

What are the key Architecture, UX and Development components required for
building humanoid robot platforms?

Would you have a problem destroying a clone or destroying a sentient humanoid
robot?

What are the top humanoid robotics platforms for research?

Karthik C Lakshmanan, PhD Student, Robotics Institute

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.
 713 views • 10 upvotes • Updated 1 Oct, 2012
 
Upvote 10 Downvote Comments 1+
 Anonymous

Humanoid research is not slow. 

We invented computers (good ones) ~60 years ago. We got UAVs ~20 years
ago. We got autonomous cars ~5 years ago, and we'll have humanoid robots
~15 years from now (that's ~75 years from start to finish).

Robots and computers are moving fast. Way fast. But even internet time takes
time.

There is only one major fundamental foreseeable bottleneck to robotics and
that is the lack of a commodity, at scale production, dense energy
storage device/platform. We simply don't have super dense/light
batteries with quick recharge times. This draws parallels with
transistors, as we needed at scale microchips, before computers become fast,
robust and actually quite useful.

We need ultra­capicators ASAP to power these robots well into the future. This
is a serious basic science/technology risk issue we need to address.

Computationally speaking I think you're talking about strong AI. We are
currently waiting on memristors to allow us to do implication logic
which should be faster than human reasoning within the next 2 decades.

The problem with robots is that they do deductive reasoning (which is great).
But that only works on clean and safe data. As you well know the world is
a messy, random, unstructured, undefined, fuzzy, hazy and an
ambiguous place.

These situations require statistical inference engines to predict what will
happen in the future. The problem is that statistical model generation is
currently rate limited by memory (see IBM Watson ­ multiple terabytes
of RAM).

Right now the slowest part of any computer is actually moving stuff
from memory into computation. 

Memristors fix this by bringing the 2 together, allowing you to rapidly create
predictive statistical models on noisy data found in an uncertain
world. This will then allow us to develop general strong AI (I make this
claim with a straight face ­ I'm dead serious).

So no bottlenecks ­ things take time ­ energy storage is a
fundamental science issue and we are still waiting on memristors
to allow us to make fast strong general AI.
 710 views • 14 upvotes • Updated 3 Jul, 2012
 
Upvote 14 Downvote Comments 3+

Robert Rapplean, Software engineer, roboticist, philosopher, political
analyst
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".
 1,285 views • 21 upvotes • Written 21 May, 2012
 
Upvote 21 Downvote Comments 1+

Hasan Poonawala

tl;(wont)r:  You are comparing the PR2 handling a towel system with
Industrial robots handling rigid end effectors. This is invalid.

Edit:
This question had something to do with towel folding when I answered it. It
doesn't anymore. As such, most of what I say below makes no sense.

The long part: 
Industrial arm robots are serial link (series of rigid bodies) manipulators
through and through, with well understood dynamics, full actuation, and
lumped parameters. More importantly, the number of states of this system are
finite and small (usually 6 for the end effector). This is an easy motion
planning and controls problem in 2013 and we can move the end effector of an
industrial robot at high speed with great accuracy. Moreover, we can recover
much of the performance when accounting for some real effects such as
flexibility, vibrations, actuator saturation etc.

On the other hand, the PR2 with a towel consists of two industrial arms joined
together by a towel. Two things happen: The system becomes a parallel link
robot, since now the object being manipulated (towel) has two serial link
manipulators affecting it. This is enough extra work (complicated inverse
kinematics and all that) . What is even worse is that the towel is not a rigid
body with finite degrees of freedom, but a very flexible thing with almost
infinite degrees of freedom. This vastly increases the complexity of motion
planning. Modeling the effect of the motion of the two robot arms on the towel
requires us to implement a model with a huge number of states.

As many roboticists will tell you, the time taken to solve motion planning
algorithms increases with the number of states of the system.

However, if the towel is moved very slowly, then it behaves a lot more like a
rigid body than a continuum. Try it yourself and you'll see what I mean. This
means that you can start using a simpler model of the towel and begin to get a
tractable algorithm for motion planning, by keeping all motions slow. 
 Added to this, I'm willing to bet that the lower­level control is quite simple,
since any high­speed feedback control will usually require inversion of a model.
As I mentioned, this model has potentially a lot of states. This is adding to the
computational burden, and with enough CS stuff going on, I would guess the
controls guys were told to keep it simple and stuck to a PD sort of law. You
have a second order system which means you might get overshoot and
oscillations if you command fast motions. 

So there are several practical reasons relating to modeling and control which
would immediately explain why the folks at berkeley kept things slow.

Edit: several is hyperbole, two reasons is what I should have said.
 237 views • 2 upvotes • Updated 17 Sep, 2013
 
Upvote 2 Downvote Comment 1

Write an answer

Related Questions

What programming language is used to control industrial robots?

Robotics: Who are the foremost roboticists in the world and what are some of the
projects that they are working on right now?

Can a killer humanoid robot be created for military use with the current
technology?

Robotics: How can I start with my thesis on Bipedal Humanoid Robot? What
basic I should learn first?

Robotics: Can we combine microprocessors and AI to build a humanoid?

Robotics: What would be the social and economic effects of the total
mechanization of physical labour?

Humanoid Robots: What are the key requirements in the widespread uptake of
humanoid robotic technology?

Robotics: I want to know how the arms of a humanoid swings relative to the
movement of feet. also i know the trajectory of the feet and hip of the biped...

Robotics: What would it take for a robotic probe to survive the Earth's mantle? Is
it physically possible?

Robots: If ALL human labor were automated, how would human laborers spend
all their free time?

Robots: Why are there not more autonomous wheelchairs?

Robotics: When will hairdressers be replaced by robots?

Robots: How can we protect ourselves against attacking nanobots in the future?

Robotics: Going back to school:  Is there a market for older, entry­level
engineers with a software background?

Robotics: Which approaches or algorithms are currently used to build
autonomous systems?

Top Stories
Sitemap # A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
About ­ Careers ­ Privacy ­ Terms