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...
Wonderful! can you tell me top robotics companies names?