Quadruped Robot Part III: Movement, Balance and Testing

This is the third and final part of a post series on the design of a low-cost, 8-DOF quadruped robot using cheap servo motors. The first post in the series dealt with the assembly and testing of a single leg module. The second post discussed the integration of four individual leg modules to make the quadruped robot, as well as the design of the control and power electronics.  This post will dwell on the software side of things, focusing on leg control, gait programming and testing. 

Leg Position Control

Instead of using Inverse Kinematics, leg position control implemented a variant of Perceptual Control Theory (PCT). In practice, what the algorithm did was to perform several fast forward-kinematic calculations (with precomputed trigonometric values), each time measuring the error to the desired cartesian position and correcting by following pre-determined actuation recipes for each actuator. Very rough, (pseudo)code below:

Of course there are various bits and pieces missing from the above code to be functional. I plan to publish the whole codebase at a later time. In retrospect an Inverse Kinematics solution might have provided more precise cartesian control. However, this solution turned out  good enough for general movement.

Read also:  Quadruped Robot Part II: Assembly, Electronics

Balance and Gait Control

PCT was also used at higher control levels, for maintaining robot balance, controlling leg extension, and ensuring leg contact when desired. These control modules commanded cartesian movements to the leg routines which in turn translated them to angular commands.

The power of PCT is that it can naturally handle multiple commands, whether they are conflicting or not. This allowed the higher level routines to command positions in parallel which formed components of the final action taken.

Having these routines in place, the gait became a very simple implementation. At the rate of the gait, a subroutine isolated the next leg in sequence, lifting and advancing it at the same time. As soon as the leg reached it’s target the main routine got control of it back and lowered it. These individual leg lifts intertwined with body advances at a slow pace. After a complete four-leg advance cycle, the legs were in their natural position to assume the next gait sequence.

Testing & Lessons Learned

I’ve tested the quadruped on a number of terrains ranging from flat to uneven, including one with challenging obstacles. The latter is shown in the video below:

The robot is able to traverse quite challenging terrain, but is quite slow. This is partially due to gait programming which needs optimization. However, another limiting factor are the servo motors themselves, in two ways. First, the resolution of the position control of these cheap servos leaves much to be desired. Second, the latency caused by the mechanical buildup of the servo (DC motor, gearbox) is significant and irreducible beyond a certain point, which I’ve found to be around 130ms. 

Another issue that turned out quite unexpected was related to the IMU. It turned out that the time to sample the Pololu MinIMU9 v3 was around 2.5ms through I2C, which led to a max loop rate of around 350Hz. Ideally, the loop should run at least at 500Hz, ideally around 1kHz for better response.

Combined with the sluggish servo response, this led to sloppy movement during ground sensing, IMU-enabled closed-loop motion, and the only solution to amend that was to reduce the speed of the gait and enforce a purely static gait solution with no dynamic elements.

The last issue was the leg design, which turned out not to be able to allow sensor contact under many different contact angles. As seen in the video above, this sometimes leads to the leg touching outside of the sensor area, which causes all sorts of disturbances to the gait planning algorithm, and often throws the robot completely off-balance.


This was the third and last part in a post series on the design and development of a small and cheap quadruped robot. The post presented briefly the software side of things and discussed the performance of the resulting robot, as well as some lessons learned during it’s development.

You may also want to read the first and second post in this post series.

What do you think of this project? Share your experience in the comments below!

For more exciting experiments and tutorials, subscribe to our email:

4 replies on “ Quadruped Robot Part III: Movement, Balance and Testing ”
  1. Cool robot! An option to try out for further stabilizing higher level loops (if you have something like “leg length”) is to use velocity servos instead of position servos, that way you remove one integration from the loop.

    1. Thanks! Velocity is not explicitly used in the loop, but I guess it could help. The main concern with these servos though are their latency and poor accuracy. Better brand servos would definitely allow more stable gaits.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.