Algorithms for Walking?

Discussions regarding building a walking robot at home. Most of the robots participating at Robo-One competitions are custom fabricated.
9 postsPage 1 of 1
9 postsPage 1 of 1

Algorithms for Walking?

Post by DocVanThorp » Sat Jun 14, 2008 9:27 pm

Post 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?
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?
DocVanThorp offline
Robot Builder
Robot Builder
Posts: 9
Joined: Wed Jun 11, 2008 1:13 am

Re: Algorithms for Walking?

Post by StuartL » Sun Jun 15, 2008 8:05 am

Post 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.
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.
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by limor » Sun Jun 15, 2008 3:21 pm

Post 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).
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).
limor offline
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by StuartL » Sun Jun 15, 2008 7:07 pm

Post 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...
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...
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by DocVanThorp » Sun Jun 15, 2008 7:44 pm

Post 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?
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?
DocVanThorp offline
Robot Builder
Robot Builder
Posts: 9
Joined: Wed Jun 11, 2008 1:13 am

Post by cyberdead » Fri Jun 20, 2008 11:57 pm

Post by cyberdead
Fri Jun 20, 2008 11:57 pm

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.
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.
cyberdead offline
Robot Builder
Robot Builder
User avatar
Posts: 13
Joined: Fri Jun 20, 2008 11:27 pm
Location: Hungary

Post by StuartL » Sun Jun 22, 2008 8:03 pm

Post 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.
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.
StuartL offline
Savvy Roboteer
Savvy Roboteer
Posts: 350
Joined: Mon Jun 04, 2007 3:46 pm
Location: Thatcham, Berkshire, UK

Post by DocVanThorp » Sun Jun 22, 2008 8:10 pm

Post by DocVanThorp
Sun Jun 22, 2008 8:10 pm

I was thinking a Parallax chip, which can clock at 75mhz (they've been overclocked to 80).

Whay do the calculations in the robot in real-time instead of in advance on a PC? Autonomy. That's what robots are about.
I was thinking a Parallax chip, which can clock at 75mhz (they've been overclocked to 80).

Whay do the calculations in the robot in real-time instead of in advance on a PC? Autonomy. That's what robots are about.
DocVanThorp offline
Robot Builder
Robot Builder
Posts: 9
Joined: Wed Jun 11, 2008 1:13 am

Post by cyberdead » Sun Jun 22, 2008 10:44 pm

Post 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.
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.
cyberdead offline
Robot Builder
Robot Builder
User avatar
Posts: 13
Joined: Fri Jun 20, 2008 11:27 pm
Location: Hungary


9 postsPage 1 of 1
9 postsPage 1 of 1