I thought I would post some info on some of the work that has gone into making the quadruped robot "PEDRO" walk in Microsoft Robotics Studio simulation environment.

Here's a video which briefly shows the latest hardware progress before moving on to demonstrations of some elements of the control software. The robot hardware and onboard firmware is now basically ready - though as you can see in the video I'm only up to manually moving one joint at a time until some more PC end software is written.



The control software is written in C# and implemented as robotics studio services. Using Microsoft Robotics Studio has allowed the control software to be tested out on a simulated robot before being let loose on the real nuts and bolts hardware. It is amazing how often a simple software bug seemed to make the simulated robot do complicated yoga poses that I'm sure would have led to stripped gears on the real bot...

The most important element of the control software is the inverse kinematics routines. These take a foot position vector relative to the robot body and work out the necessary joint angles to put the foot into that position. Once this important function is in place, you can then make a leg step simply by moving the foot position through the desired curve, and the leg joint angles are all taken care of by the inverse kinematics.

After the inverse kinematics was working well, the next step was simply adding some other ways to set the foot positions by setting a body movement relative to the ground. Although this sounds complicated, to move the body forward relative to the ground, for example, all you have to do is adjust all the feet position vectors backwards a bit, and again, the inverse kinematics takes care of the rest. Body rotation is handled much the same way; a method is provided to rotate the body which actually rotates the four feet position vectors (or however many feet are actually on the ground at the time) around the body centre.

The actual stepping motion is created by choosing a target for the foot position using the current movement direction and current desired body rotation. The path the foot follows during the step is an elliptical one so that the foot moves almost directly straight up off the ground at the onset of the step motion and similarly comes down at footfall almost vertically. This should help in clearing obstacles (or carpet etc.). Once the target foot position is chosen and the step is started, the software updates the foot position and servo rotation speed using the calculated path every iteration. Meanwhile the other three non-stepping legs are being moved by the body motion functions - ie. every iteration the body stance is shifted in the desired movement direction.

Another important component of the control software is the methods I have added for calculating the robot's current centre of mass. This is calculated using the known current position of all the joints and the mass of each segment. It is important to know the centre of mass in static walking so that stability can be maintained by shifting the body pose before a foot is lifted off the ground. For example if a particular foot is selected as the next to step, then the body centre of mass should be compared with a triangle formed by the other feet. If the centre of mass falls vertically within the triangle, then the robot will be stable with that foot lifted off the ground. If not, then the body stance can be shifted before the step is started so that the centre of mass falls within the stability triangle.

The step order is most critical for stable walking, and I found that for forward motion, stepping the rear then front leg on one side followed by the rear then front leg on the other side resulted in the best stability. Currently PEDRO's walking algorithm adapts this basic pattern for whichever quadrant the desired direction of travel falls in. For example if the desired direction is pretty much side stepping to the right, then the best foot step order will be front left, then front right, then rear left then rear right. I have also worked in the desired rotation into the algorithm which picks the next foot to step, and if the desired rotation is more dominant than the translation movement, then the best order for rotation takes over which is stepping around the clock ie. if rotating clockwise, then step front left, front right, rear right, rear left.

This method is working quite well in practice, however I would like to replace it with something a little less scripted. I did try choosing the next foot to step based on which foot could possibly step the furthest in the desired direction, however this wasn't particular successful. I won't do any further work on this right now however, because it will be far more exciting to test out the walking algorithms as they are with the real robot, and this is hopefully not too far off. I have to finish the software service which communicates with the robot using tcp/ip, passing on the joint movement messages to the onboard controller. With a bit of luck the real robot will walk just as successfully as the simulated one, but I'm tipping there will be problems to solve...

Recently I bought a wireless Xbox controller purely for use with Microsoft Robotics Studio, to remote control the PEDRO quadruped robot and steer it around the floor. To get to this pretty simple goal, a lot of steps are needed - I already had a simulation of the robot going in Robotics Studio, and even walking, but in a very 'canned' sequenced fashion, with all the joint angles moving between key frames that are hard coded. See this blog post for a video of the rather unsteady robot simulation walking in a straight line. This method won't do if you want to control the robot in an unplanned fashion where the direction and speed of walking are able to change at any time, so a more sophisticated approach is needed.

Since then I have written several robotics studio services to support the robot. One communicates with the real physical robot (still in progress), another controls the simulated robot. These two implement the same 'generic contract' as robotics studio terms it, so other services can be built to interchangeably communicate with either the real or simulated robot without any recompilation. A third robotics studio service implements the 'generic differential drive' contract so that it can accept differential drive control signals from other services which use this contract. This service contains all the software which implements the new walking algorithm capable of rotation, walking in any direction and varying the speed of the robot. The output of this service is essentially a continuous set of joint angles which can get sent to either the real robot control service or the simulation robot service.

The beauty of allowing the walking service to accept differential drive control signals (also called skid steering) is that potentially many different services can be connected up to control PEDRO, even though the original authors of the services have not even seen the robot. The drawback is that there is not much control with just a left and right motor speed signal for a 14 degree of freedom quadruped robot! However I will allow more complicated forms of control in the software which will work with services I create, as well as the more standard differential drive control. Another cool little side benefit is that the standard dashboard service supplied with robotics studio accepts input from the mouse or game controllers like the wireless Xbox controller and so can be used to remote control your robot with a convenient wireless handheld device. Because of this, I had to buy one to try it out!



I'm still working on a video which describes the technical detail behind the actual walking algorithms, and I'll post it when its done. Of course making the robot walk in simulation, and making the real robot actually walk across your floor might be two very different things - and this is something I'll hopefully find out pretty soon as the hardware has progressed really well.

The physical robot is now fully wired up with all the AX-12 servos connected up to the onboard controller which is communicating over WiFi quite well. I can manually drag a slider up and down and move individual joints one at a time using a slightly modified version of Scott Ferguson's DynaCommander software. I haven't fitted any battery to the robot yet, so it is still tethered to a power supply, because I would like to put a dummy weight equal to the battery weight (nearly half a kilogram for the one I want to use) onto the robot to make sure it can lift and carry this weight comfortably. This way if the robot can't in practice support the heavy battery I can still source and fit a lighter battery option with less run time.

I'm currently working on the service which will replace the simulation and communicate with the real robot. When that's tested and debugged it will be really interesting to see if the walking software that works so well in simulation can work as well in reality!