Passive Walking Robots

[UncleBob]

This robot walks WITHOUT power based on Ted McGeer's theory.

The term and its principles were developed by Tad McGeer in the late 1980s. While at Simon Fraser University in Burnaby, British Columbia, McGeer showed that a human-like frame can walk itself down a slope without requiring muscles or motors. Unlike traditional robots, which expend energy by using motors to control every motion, McGeer's early passive-dynamic machines relied only on gravity and the natural swinging of their limbs to move forward down a slope

phpBB [media]

phpBB [media]

phpBB [media]

phpBB [media]

phpBB [media]

And here are some vids of robot walking. Let's see if there are any difference

phpBB [media]

phpBB [media]

[UncleBob]

FabinovX can you write a function similar to the kondo stablise function ? I remember you work on something with the gyro previously. I know Bioloid has a default gyro function but I don't think it is as powerful as the one in the vid from kondo.

[27Loco]

Robot running in slowmotion (blog of the owner: http://frostyorange.blog.shinobi.jp/)

phpBB [media]

Using the gyro for dynamic walking. Must be really tough to code.

[FabinovX]

I'm not at home this week, but when back, i will try to give it a look.
But the Bioloid behaviour is really close to the Kondo one.
i think the big deal is with the calibration of the datas.
in static mode, the factor values must be bigger than in dynamic mode.
but i'm not shure i can test motion status in the callback.
i'm pretty shure it won't be possible due to timing issue...

[Fritzoid]

I've been looking into the issue of stabilized walking myself and there are some serious constraints dictated by both the hardware and the firmware.

FabinovX is right there isn't much time in the callback routine. Figure on less than 4ms to do everything that needs to be done. That's only enough time to read a few sensors, do a little math, update some offsets, and feedback a few characters to the user.

The sensors are also a big issue. Reading an A/D port in the callback is very fast but reading an off-board sensor like an AX-S20 can take up to 500us per word, ouch. Unfortunately the on-board AD conversion is so noisy that it's basically useless for accurate feedback.

Finally, the feedback loop has to be general enough so that it can be applied to all the walking motion sequences consistently.

So the job is going to be a challenge on a number of fronts, but not impossible.

[UncleBob]

are you saying that if I write my callback too long it will exit before it finishs ?

[FabinovX]

No, because Roboplus task manager won't you let download the soft if it exceeds the limit code size adressed to the callback feature.
If i remenber, it also give your errors when checking code if you try to call to much values from sensors or AX-12.
So it's quite difficult to deal with all these limits.

Cheers
FabinovX

[Fritzoid]

Your callback code needs to complete before another timer interrupt occurs. Interrupts occur every 7.8125 ms. If the next interrupt occurs before the previous one ends then the next interrupt is ignored. This means no motion update or callback is made for that interrupt. Missed motion updates will lead to slow and jerky movement. The non-callback code would also be effected as it runs outside of the timer interrupt handler.

I'm not sure what limitations are put on the size of the routine but there are definitely limitations concerning the instructions available. For example you can't use looping routines in a callback. A limit on sensor reads could become an issue too.