Very sweet, how much do you expect it to weigh? Do you have any walking
I've always avoided walking robots because it seems like they have a higher
power requirement than a rolling one. With wheels one only needs to move
the robot, with legs, you have to lift it as well.
A few kilos, not sure exactly yet. It will depend on the batteries. I can
shed some weight by cutting away some of the base if I need to (drill large
holes to make a honeycombe base). Or I could swap the servos for more
powerful ones. I just wanted to stop planning and start building :-)
No not yet. I have a few in mind. I'll suspend it off the ground on a tether
and experiment by sending it lists of position / time settings, then get it
to play the lists.
Yes but I was looking for a control application that emphasised real time
control of many motors. I plan to make the step by step build details
available once I get it walking. I'll also make the executable available so
you can program a PIC yourself without needing an expensive controller.
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
If money is not much of an object, the NiMH batteries have a very high power
density. It is about 6 lbs (5 lbs 13 ounces) for a 12V 7AH lead acid
battery. For NiMH, you can get AA batteries that have 2300 mAh (2.3 AH)
they weigh about one ounce each. You will need 3 banks of 10 batteries to
be 12.5 volts at 6.9 AH and is about 2 lbs (1 lbs 14 ounces), less than a
third of the weight.
$60 dollars for the NiMH (assuming $2.00 per battery)
$14 dollars for the lead acid battery.
So, for about 4X the money, you can get 1/3 the weight.
Thank you for the info. I have been thinking about NiMH. I have seen 1800mAH
for half the price of 2200mAH (from the same manufacturer). I have also been
thinking about Li-Ion batteries. There seem to be quite a few sources of
"cheap" Li-Ion for mobile phones on eBay. The biggest hurdle here would be a
Actually I wouldn't need 12.5v, 7.2v would be fine - even less weight :-)
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
I have 3 walkers, and all use NiMH AA-cells, 1800-2100 mAh. These work
well, are light in weight, and will run the smaller bots for quite a
while. Gimlee, Nico, and Nico2 ...
Lead-acid batteries are probably much too heavy for a walker,
especially given the energy capacity of this type of battery. I would
probably go with NiMH "C-cells" rather than use a 7.2AH SLA.
I see a lot of walkers on the net made of machined aluminum, but this
is also very heavy for a walker. Heavy base requires stronger servos,
and these in turn require larger batteries. It's a vicious circle.
Anymore, the first thing I try to do is design a light-weight frame,
meaning some kind of plastic instead of aluminum. Gimlee uses an
aluminum plate for body, but it's basically underpowered for its
- dan michaels
I did a nifty Algo for the EH3-R from Lynx Motion. It does inverse
kinematics for each leg, with a sort of "coathanger" gait.
It does vectored motion, so it can "crab" in any direction. Added a wireless
playstation controller. Lots of floating point math, but some good ideas
I put Li Ion batteries on it from Lightflightrc.com , along with a voltage
comparator circuit to keep from frying them. LiPoly would be better, but the
budget didn't allow at the time.
Videos at http://www.bio-bot.com/bio-botsite/lynxmotion /
I was going to list it on Ebay this weekend, to sponsor the next wave of
robotic madness, but now I just don't know...
Hi Mike, I notice you don't believe in small AVI files ;-). I
downloaded maytag, and it looks pretty much as I expected! Oh, man.
[actually, my HD ran out of space this morning and I spent half the day
doing file maintainance. Bummer].
At any rate, I was going to mention that Sergio's hexagonal leg
attachment design was probably going to involve a lot of trig-math,
which you no doubt have been enmeshed in with EH3. Do you think that
design is superior to the usual hexapod leg-attachment scheme? It's
probably on the same level of verstaility as a synchrodrive, turn on a
dime, etc ....
but I imagine you need to solve a lot of maths before it can take even
a couple of simple steps. No ????
Yes, lots of math, but lots of control. Almost like having 6 robotic arms
all doing inverse kinematics. In my math, I inclluded the ability to
configure the legs for any rotation relitive to the body, so it would also
work on an inline hex as well. It is basicly like a synchro in it's ability
to simply re vector, though a bit more flexable in that it can jump vectors
in 90 degree increments a lot faster, though there is little utility there.
As far as what a "usual " leg attachment is, I do not pay enough attention
to R/C servo hexapods to know. His design is similar to Lynx's and if I
recall, Colin Mackenzie's as well. It differs from Crust Crawler's in that
the hip of the crust crawler uses a linkake and cantilever arrangement.
Regards "usual" leg attachment, it wasn't clear, but I was actually
referring to the usual scheme of attaching the front and rear legs on
the sides of the beast, inline with the middles, rather than at equal
angles around the perimeter, as in EH3 and Sergio's. With the inline
arrangement, it's easy to get straight-ahead walking. With the equal
angle perimeter arrangement, you have to solve a lot of trig to get
straightline walking, although turning is highly versatile. I also
noted Colin's Twitchie/etc several years ago.
It's a nice challenge to do all the maths, but I was wondering whether
you think you really gain much by going to the trouble, as compared to
using the simple inline leg arrangement, where the maths is relatively
Also, when you get to more complicated gait movements, it seems the
computational complexity would keep increasing. Eg, if the bot is on a
sideways slope, and attempting to maintain the body level, all of the
foot trajectories will be different, etc. In the same situation with
the inline arrangement, pretty much all the legs do exactly the same
thing, one after the other, so once you figure out what to do with the
front leg, all the others follow. Randy Dumse recently commented on the
complexity of doing the inverse kinematics over on yahoo TRaCy. I think
he was referring to EH3, also.
Mike and I have gone back and forth on the walkers. He'll do a revision,
then I will, and so on. Yes, I probably was talking about the EH-3, but
specifically the EH-3I inline (as opposed to the EH-3R the round body).
The extra trouble of doing all the math allows articulated movement of
each leg. For instance see the movie of the inline walking at 45 degree
It can also walk forward
and sideways crab style.
What I'm working on now is getting it to rotate while walking.
Eventually, I should be able to get it to circle something while
pointing at it, a sort of stalker manuever.
You can't get these kinds of life like motion without dealing with each
leg as an independent entity.
The math isn't that bad, in that once you solve for one leg, you solve for
Once I have an active sensor on there, I may go to something more reflexive.
As it stands, any walker without feedback is walking only because the
surface it is on
accidentally happens to match its expectations. Reflexive walking would
require an "ingrained"
sense of matching desired direction and leg sensor feedback to an
appropriate servo response.
While inverse kinematics is clearly over processing, it does allow one to
make precise motions
and could be an interesting training tool for a more sophisticated learning
algorithm, representing an ideal
In my maths, I have ground height in the calcs, so it is one step away for
ground heights for each leg. I wanted to build a software package that was
extensable to inline
or odd leg arrangements. I eventually plan to do a 10 legged scorpion, with
each leg on a side being of different length
and orientation to the body. Again, my maths are not far off. When I do the
scorpion, i will likely implement one smaller processor per leg, like an
TiniARM or Plug A Pod, and link them via CANbus. At this time, I will start
considering the neural calcs and feedback sensors, where I will need a lot
more munber crunching. I will also be doing it with DC servo motors, not RC
My maths are ground track accurate, with very little scrub. To do the maths
for an inline or a straight line walker is no different. I got impacted at
work, so I handed further development off to Randy Dumse of NMI, since it is
a great showcase for the capabilities of the ServoPod. He is building in
rotation tangental to a point on a plane. This will require the legs to
follow an arc or psuedo arc of different radii depending on leg position
relitive to the body and the center of the arc.
One feature of the math is the gait waveform tappinge different legs into
the same waveform, but at different phases
allows expansion of the gait. By amplifying the height of the gait, I can
make the legs more or less scary looking as they cycle through. It can mince
The thing here is that I did a lot of this simply because I could. I wasn't
putting an undue burden onthe ServoPod. I didn't have to resort to serial
comms ro some servo accessory, and I could do 20K plus floating point
operations per second without having to get clever with my code. Since then,
Randy has optimized my code, because that is the sort of thing that bugs
him, but I wasn't against hasing 20% of my processor cycles in the interest
of getting things done.
challenges. (or a way to develop artificial neural networks)
I am working is IsoMax, a superset of FORTH.
It is pretty easy. It uses postfix notation, which takes a bit of getting
used to, but it is worth it. The ServoPod has 26 register based PWM channels
which makes things easy too.
Gary Parker and his students at Connecticut College have been
doing some interesting work using Genetic Algorithms to evolve
efficient gaits for hexapods. They've also looked at adaptive
learning for systems in which, for example, one leg is damaged
or otherwise subparr. Perhaps you can find some useful
information at the following URL:
Actually, most hexapod walkers have to expend some energy just holding
themselves up, and will slump down when you turn off the power. This is
one of the prices you pay for having cantilevered legs. Eg, get down on
the floor and extend your arms & legs out away from your body, and try
holding yourself up with only your fingertips and toes touching the
floor. One of the advantages of vertebrate skeleton design [except for
some amphibians and reptiles] is that vertebrate legs are "rotated"
under the body so the bones+skeleton directly hold more of the weight
and the muscles can do less work.
Maybe cantilevered legs are not a good design
for larger robots just as they are not for
larger animals? I suspect a reptile rests on
its tummy when not running about? Perhaps
the design is only suitable for small robots.
The other problem I see with this design in
larger robots is the surface area it takes up.
Also in a domesticated robot a rather large
mechanical spider scampering down the passage
would be rather scary :)
A domestic robot needs to be "cute" and
It should also be silent or at least have
a nice motor sound.
This is exactly the point. When is the last time you saw a 400 kg
spider? [heaven forbid]. An 80-tonne dino with cantilevered legs is
probably physically impossible, especially when the femurs of those
guys were somewhat wider and taller than a man.
BTW, you might be interested that crocs can gallop ... pretty
phenomenal to watch ...
You notice that most of the japanese android designs are rather
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.