It's alive! But needs work...

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.