Well really you only need Six degrees of freedom to *simulate* anything -
that is, to get something moved into any given position (unless there are
other considerations like obstacles). The extra DOF in evolved systems like
legs probably come partly from floppiness in the joint or evolutionary
"baggage" not strictly needed for the job.
The computational problems of working out the kinematics for a 26 DOF system
are probably pretty intense too :o
No links to offer, but if you try looking around for "redundant
manipulators" you might get something. Academics have looked at
implications of having, say, a robot arms with a seventh DOF in the link.
Hi Randy, I think Full wasn't so much talking about #leg DOFs in that
citation as making a case that the overall "timing" relationships are
similar across pedalities [if there is such a word]. Bipeds step
leg-leg, quadrupeds go diagonal-diagonal, hexapods go tripod-tripod,
etc. Basically the standard gaits all use alternate stepping from one
"unit" [my word] to the other, regardless of the #legs in a "unit".
Regards how many DOFs to put into a leg is a different question. I
decided to try only 2 with my upright leg designs, but this is
somewhat minimal, and has led to severe ground clearance problems. A
3rd joint, which would allow the foot to fold under, like in a dog
walking/running, would solve about 90% of the problem I have been
seeing - [again, this is for an "upright" leg, as opposed to the more
common cantilevered arthropod leg].
Real animals have tons of degrees of freedom in their joints. Besides
the obvious, they also have the ability to splay legs out and in to
some extent [cross them over in turns, etc], and to rotate each limb
segment individually [try your wrist and shoulder, and ankle]. Also,
the feet have 20 bones or so, all movable w.r.t. each other, so you
can do heel-toe, heel rotations, shifting weight inside-outside, etc
[great for over broken ground]. In the hips, you have a few more DOF
[rotation and tilt, used in normal walking and broken ground], and the
spine is a real biggie in terms of #DOFs, esp in quadrupeds. Look at
the pictures of running cats and horses, and you see the spine goes
through signficant bending to increase the length and power of the
stride. The spine also comes in during turns [twist + shoulder
lowering and rotation], along with the mentioned leg cross-over bit.
Turning repesents another entire set of problems.
All in all, it's hard to imagine [in my lifetime] building a robot
that could take so much into account, so I think it's mainly a matter
of recognizing how few you can get away with for your particular
purposes. I chose 2DOFs/leg initially, but that is prolly too few. The
2 major problems that arise with this choice are ground clearance and
turning capability. A 3rd DOF to tuck in the foot, along with a
rotation capability to aid in turning would greatly improve my
designs. So, maybe 5 DOF minimum for an upright leg :).
- dan michaels
While we're talking legs here, I have played with a few different walkers,
which I will refer to as #of legsx #of axis per leg.
I have done a 4x3 which, controlled by a basic stamp, and evertually a SSC,
was ok(ish), but cumbersome. It had a tendency to tip, and the stamp was
tough to get smooth accurate accelerations out of.
I did a 3x3, which worked well, until I did robotic Tai-Chi, and had huge
masses(for an r/c servo) loading it, until it burned up a joint, and I got
I have played with a lynx motion 6x3, and 3 axis of motion was nice, but I
wanted to do inverse kinematics for nice motion on the ground, but didn't
want to take the unit apart to measure everything, so I shelved it.
Now I am looking at making my own, but I was considering going 6x2. I
realize that I either will "scuttle" as keep the body at the same height, or
"hump" as I track linearly along the ground, or a bit of both. I am not
necessarily looking at being able to "crab" as well as a 6x3, but thoutht
that if I put my legs at something like -30deg to parallel, 0 degrees to
parallel, +30 degreed to parallel, along the side, that I would be able to
accomplish two things. I would be better able to "crab", and I could shorten
my O.A.L. by reducing the overlap regions of my legs.
Do you have any thoughts on the merits/limitations of a 6x2 vs a 6x3 design?
Hi Mike. Just a couple of comments. Regards the inverse kinematics
problem you mentioned, do you think that the brains of real creatures
calculate differential equations, etc, when walking? No, they initiate
some kind of general [and I think, "approximate"] leg movements, and
then use feedback from proprioceptive and touch sensors, as well as
vision, to determine if the legs should be adjusted during the
movements. This becomes very clear when you walk over broken ground -
not many sidewalks in the jungle.
Regards reducing the issue of legs overlapping .... just a thought
problem. Why not think about using upright leg designs, rather than
the standard cantilevered leg designs, as a way to increase the range
of leg movements without the usual problems of leg interference? One
guide is to look at how the legs of horses and dogs move during
walking and especially running. Just some food for thought.
- dan michaels
Yes, that's much clearer now. Tnx.
I'm wondering of late if the problem ins't only one of expense. You have
your chip that does 20 RC Servo outputs. I have the 'Pods which do 26 RC
Servo outputs. But I only own one robot that has 18 joints, my
Lynxmotion H3 walker. I haven't spend as much time as I would have liked
programming gates, etc.
The idea of a scorpion appeals to me. Lots of joints there. But I really
don't want to spend $20-$30 a joint for motion control (although that is
a very reasonable price by industrial standards).
I wish there were something approaching muscle, relatively light weight,
and linear. Also a low cost way to measure its movement. I could make a
controller board to close the loop.
The stick diagram at
5 segements. It lacks the rotation you mention, tough. Have you
seen anyone build a leg like this? The the limitation cost, or
complexity, or control, or simply lack of application.
Seems like there is lots of DARPA money being thrown at movile robotics.
You'd think there'd be more obvious research on this. Maybe I'm just not
aware of it (completely possible).
So... what does it lack? How far are you along? Let's see, 8 legs, 2
joints, so 16 servos. Are there rotations at the top of the leg to
direct its motion? or is that the meaning of the "eventually 2 more for
body angulation"? Has it walked yet? Have you worked out the stroke of
this vertical leg?
On my Lynxmotion H3 walker, I had worked out a tripod gait at maximum
speed. I had no profiling on the RC Servo's motion. This spring I took
the walker with me on the road and demonstrated it at a couple
universities (UNI and UofW). I used it for a sight gag. It sat under a
box with the back side cut out. I made a big deal of introducing my new
ServoPod(TM) board, told them there were only two in existance, and one
was under the box. I pulled the box away to reveal the ServoPod(TM) on
the H3 walker, which a second and a half later, stood up and walked back
into the box, and then squatted back down inside the box. It simply used
the IR detector to tell if it had something close infront of it, and if
not, it would walk until it did.
When I did the L5 arm, I had to work out the RC Servo profiling, because
a arm moving at full speed between far positions was quite jerky and
unstable (enough momentum generated by impulse movements to "flop" the
base around.) I worked out trapezoid movements in software. I have
profiled velocity, with ramp-up and ramp-down, and a limit on maximum
Later, I did take what I'd learned doing the the profiling to my PID
routines. So I am to control multiple channels of velocity-profiled,
All that profiling needs to brought back to the walker to make the leg
movements slow and steady. Then also, the coordination of three joint
legs need to be worked out so the point of contact with the floor draws
a straight line as it pulls back. This appears to be a rather difficult
inverse kinematic problem, I haven't really tackled yet.
I've always hoped to have emergent gates with the legs, but I've pretty
much decided that is a "false grail". What to do about gaits other than
making preprogrammed ones, is still a puzzle to me.
In the meantime I am looking for a good robot base to show off 12 or 16
channels of servo control with gearmotor and an H-bridge, and a pot for
feedback. Hence my curiosity at dof in legs.
Hi Randy, Gimlee is really only lacking getting back to working on it.
I had to redesign the [upright] legs, because of ground clearance
problems with the 4 in the rear on the orginal design. This involved
lengthening the femurs and rearranging the legs w.r.t. distances from
the midline - in order to reduce the possibility of clash. The clash
is mainly due to the size of the servos themselves, and the fact that
the knee servos are simply mounted to the femurs. Rather simplistic
design - but I am mainly interesting in proof of concept. I also
redesigned the controller board, so I could have up to 20 servo
channels simultaneously with 8 additional channels for analog sensing,
touch switches, etc.
There are no rotations on the legs, but I have plans to add this one
day. It will be easy because the legs are all modular units, held on
with only 2 screws each. In the meantime, it will still turn using the
simple means - running one side faster than the other, etc.
My bug is controlled by a simple CPG [central pattern generator]. The
joint movements are based on trapezoids, and I can set up to 9
parameters/leg. Therefore, I can control positions and slewing. I can
also set the relative phase of each of the 16 joints. Same idea as
used with Nico, only expanded to 16 joints:
The ultimate plan is to use feedback from the joints to re-adjust the
CPG parameters in real-time - ie, if a leg touches something
prematurely [eg, before the end of its trajectory], then stop slewing
for this cycle, etc. Details to be worked out :).
With Brooks' hexapods, like Hannnibal and Attila, he actually got
emergent behavior - depending on how you define it. He didn't
specifically program in a CPG routine like I did, but rather a set of
rules for each leg/joint. "If leg is up, then move forward", "if leg
is fully forward, then move down", "if leg is down, then move back",
etc. Then there were some statements about relationships between
adjacent legs, in order to coordinate them, something like "if leg in
front is moving back, then lift this leg", etc. Basically, bits and
pieces of movements were coded in, but specific coordination was not.
Should be easy to do with the Isopod FSM scheme - take a look at some
of Brooks' earliest papers - downloadable:
Brooks, R.A. "A Robot That Walks; Emergent Behaviors from a Carefully
Evolved Network?", MIT AI Lab Memo No. 1091, February 1989
Brooks, R. A., "A Robust Layered Control System for a Mobile Robot ",
MIT AI Lab Memo No. 864, September 1985
Also, take a look at the paper by Cynthia Ferrell [Brazeal] that I
have cited here:
Personally, I would go for using joint and touch feedback to keep
things simple, as opposed to using kinematics equations. Real bugs
don't use them, after all. However, a bug probably doesn't care if
it's not going perfectly straight. OTOH, implementing the equations
would be a good selling point for the IsoPod, so ....
- dan michaels