Algorithms for Walking?
Algorithms for Walking?
by DocVanThorp
Sat Jun 14, 2008 9:27 pm
Can anyone give me some info about algorithms for making a robot walk?
Seems to me that most small bipeds are positioning the center of gravity above the center of one foot, moving the other foot forward, then moving the c.g. into position above the other foot. Fairly simple, fairly stable even with slow actuators, but possibly not as fast as a more dynamic algorithms that move the c.g. forward before the foot drops. How important a factor is momentum when programming small bipeds?
Seems to me that most small bipeds are positioning the center of gravity above the center of one foot, moving the other foot forward, then moving the c.g. into position above the other foot. Fairly simple, fairly stable even with slow actuators, but possibly not as fast as a more dynamic algorithms that move the c.g. forward before the foot drops. How important a factor is momentum when programming small bipeds?
Re: Algorithms for Walking?
by StuartL
Sun Jun 15, 2008 8:05 am
DocVanThorp wrote:How important a factor is momentum when programming small bipeds?
I haven't got walking working yet, although I'm pretty close to a dynamically balanced standing stance, and I think I already know the answer to this.
VERY.
It seems that the robot's inertia, especially rotational inertia, is incredibly important even for standing. By the time you want it to actually move I suspect it's critical.
by limor
Sun Jun 15, 2008 3:21 pm
Hi,
You've hit a very good issue. The current control paradigm used for the majority of humanoid robot is open-loop which means the algorithms used are not "dynamic" they are predefined and executed blindly. Except where gyros are used, to counter imminent falls in real-time.
The catch-and-play functionality allows users to trial-and-error walks and gaits in an attempt to make them as stable and repeatable as possible.
To implement real closed loop control, a more powerful processor has to be involved and the Atmega should only serve as a real-time intermediator. there are established ways to make humanoids walk through closed loop control. google for example ZMP (zero moment point).
You've hit a very good issue. The current control paradigm used for the majority of humanoid robot is open-loop which means the algorithms used are not "dynamic" they are predefined and executed blindly. Except where gyros are used, to counter imminent falls in real-time.
The catch-and-play functionality allows users to trial-and-error walks and gaits in an attempt to make them as stable and repeatable as possible.
To implement real closed loop control, a more powerful processor has to be involved and the Atmega should only serve as a real-time intermediator. there are established ways to make humanoids walk through closed loop control. google for example ZMP (zero moment point).
by StuartL
Sun Jun 15, 2008 7:07 pm
As of this afternoon I have dynamic standing stability. It's not infallible (i.e. if you push it hard enough for it to fall over it still falls over) but if you push it a bit he'll sort it out.
If you push him a bit too much he currently shuts down (i.e. turns all the servo torque off) to avoid stripping servo gears. Next step (badoom tish) is to make a step instead...
If you push him a bit too much he currently shuts down (i.e. turns all the servo torque off) to avoid stripping servo gears. Next step (badoom tish) is to make a step instead...
by DocVanThorp
Sun Jun 15, 2008 7:44 pm
Sounds more difficult than I had thought.
So what kind of processing power is going to be needed? What kind of precision is needed for the calculations? I had thought that i could do it with a fast SX chip and lookup tables. I've seen video of soccer playing robots that move around the field pretty effectively, and I'm pretty sure that they are using off-the-shelf microcontrollers.
Is there open-source software for this?
So what kind of processing power is going to be needed? What kind of precision is needed for the calculations? I had thought that i could do it with a fast SX chip and lookup tables. I've seen video of soccer playing robots that move around the field pretty effectively, and I'm pretty sure that they are using off-the-shelf microcontrollers.
Is there open-source software for this?
by StuartL
Sun Jun 22, 2008 8:03 pm
DocVanThorp wrote:I've seen video of soccer playing robots that move around the field pretty effectively, and I'm pretty sure that they are using off-the-shelf microcontrollers.
Most of the stuff you see in the videos are precoded sequences of moves, occasionally you see ones with IMU mixing into the sequences. For these you could almost do it with a 1MHz microcontroller and a few 10ks of flash...
I'm newbie, but wouldn't be faster, if all the critical counts would be made on PC? And the small microcontrollers are, just for execute the recieved joint coordinates.
Faster, yes, but it seems unnecessary. I *think* we can just get enough processing power out of an Atmel ATMega128 at 16MHz to do full inverse kinematics for a humanoid at 40Hz. There's not a lot left, though, and we're now talking about rewriting the dynamixel servo code to get the servos to do more of the hard work, leaving the core MCU for coordination and inverse kinematics only.
by cyberdead
Sun Jun 22, 2008 10:44 pm
Okay, i agree with you Doc. What if we want more calculations, will be enough that small MCU for it? For example picture proccessing for shape recognition, or i want my robot to do terrain adaptation (i think these are complex problems).
Other thing, i made the inverse kinematic calculation with MATLAB, and it toke 2-6 sec to calculate it. I heard that the optimal time for the entire proccessing, shouldn't by more then 1 ms, so 2-6 sec is really much, but correct me, if I'm wrong, please.
Other thing, i made the inverse kinematic calculation with MATLAB, and it toke 2-6 sec to calculate it. I heard that the optimal time for the entire proccessing, shouldn't by more then 1 ms, so 2-6 sec is really much, but correct me, if I'm wrong, please.