Finally "PEDRO" the quadruped robot has taken it's first steps outside of simulation... Admittedly it suffers from the shakes and falls over continually, but it is still a milestone.

I finished the Microsoft Robotics Studio control service to the point where it can send out regular servo position updates over the wifi link to the robot, taking direction from the quadruped differential drive service which implements the walking algorithm.

Here's a short video of the shaky movements;

Obviously there is a lot to improve upon. The balance and stability control aspects of the software, although they worked ok in the simulation environment, are obviously not working too well on the physical robot. I will definitely improve these, but I'm more worried at the moment about making the servo movements a lot more smooth than they are now.

I was initially sending servo position and speed updates (via a SYNC WRITE command on the dynamixel network to the AX-12 servos) at only 10Hz, and the first thing I tried was increasing the rate of updates. Even increasing the rate to 50Hz or even 100Hz didn't improve things much. I also removed the speed control code and used a AX-12 speed register setting of zero which represents maximum speed with not much effect. A quick look at the AX-12 data stream using the completely cool and now indispensable logic analyser showed the root cause of the problem - relatively large amounts of jitter in the timing of the AX-12 packets.

So next I'll be working on improving this aspect so the robot can have smooth movements. Although some people have managed to cram inverse kinematics and other trig type calculations into Atmel AVR micros similar to those on the PEDRO robot, I think I would rather keep the robot platform as independent from the control methodology as possible to allow for completely novel approaches to be implemented on desktop computers and quickly tested. So step one will be to use more accurate timing within the Microsoft Robotics Studio code. Rather than use the TimeoutPort mechanism provided which according to online sources can have 16-20ms jitter (apparently improved in MRDS 2.0) I will use change the code to use timing based on the multimedia timer which should give much more accurate results.

Mind you I expect this will only be step 1, because there are many sources of varying latency in my robot system - wifi, processing delays on board the robot, SPI comms between the main micro and the AVR handling the servo comms etc. So I am thinking I might put a queuing system onto the AVR which handles the servo comms, and rather than just passing data onto the servo bus as soon as it is received, I might actually decode the AX-12 packets and buffer them so I can resend them out at precise intervals. If the buffer holds only a few packets then the delay between the PC end and the actual robot movement won't be that great (maybe 100ms?). I will have to make the rate that the packets are taken from the buffer and sent out to the AX servo bus adjustable with a long term average, so that the micro can tolerate timing differences between the PC end and the micro. For example if the PC end is sending out packets on an average interval of 20.4ms and the micro expects packets at exactly 20ms and is taking packets out of the queue at that rate, then the queue will eventually empty. If the micro measures the average arrival timing of the incoming packets and adjusts its interrupt driven timer for precisely sending out packets accordingly, then the buffer will stay more or less at its intended size.


  1. shimniok // May 3, 2009 at 1:26 AM  

    Very cool! Looks like a great start. Eager to see its evolution. -Michael

  2. Anonymous // May 11, 2009 at 8:35 AM  

    Wow! I was just surfing the web for info on servos controlled via wifi, and I've found your "pet" haha

    I must say I'm very impressed! Keep up the good work!

  3. Knightrous // August 28, 2009 at 9:48 AM  

    Just a suggestion to help with your development. If you camber/tilt the legs (at the shoulder joint to a 30-45 degree angle, you will get a lot more stability from the 3 remaining legs in contact with the ground during the walking cycle. This should help prevent Pedro from falling over. As you perfect the system, you can just decrease the amount of camber.

  4. Robots Australia // August 28, 2009 at 9:57 AM  

    Hey thanks Knightrous, you are spot on - since this post I've got a better method for ensuring the bot shifts stance so that the COM is within the stability triangle by at least 20mm, and also I changed the foot targets during stepping so it steps 'wide' by a few centimetres, which does just what you are saying, and makes it a lot more stable. I've been completely mired down on getting good regular 20ms timing out of windows and robotics studio for the movement messages, but when that is finally sorted, I'll post some more progress.

  5. Anonymous // January 19, 2010 at 3:59 PM  

    How To Make money with affiliate programs Today. Affiliate marketing is the easier and probably the most effective method to make money from the internet. It is basically, a kind of selling technique where potential buyers from your website are directed to the websites of sellers. For every click, the website owner gets a small commission.

    on line marketing

  6. Anonymous // February 1, 2010 at 10:46 PM  

    Affiliate Marketing On The Internet
    Affiliate Marketing is a performance based sales technique used by companies to expand their reach into the internet at low costs. This commission based program zsuch as email distribution in exchange for payment of a small commission when a sale results.

Post a Comment