TOPS - Traverser of planar surfaces

By Andrew Gregory. Posted

Quadrupedal robots are quite peculiar. While most robots perform tasks that humans and animals can’t quite accomplish, quadrupeds mimic natural movements, which is harder to do.

This very challenge is what has inspired me to build several of my own robot dogs over the years. So, what exactly goes into building a robot dog? Just how close can you come to replicating an actual dog? And how cheaply can this be done?

Setting out to answer these questions led me to build my latest quadruped named TOPS (Traverser of Planar Surfaces). TOPS is an open-source twelve degrees of freedom (DOF) quadrupedal robot that can walk, trot, and dance. Other than the motors, bearings, and screws, TOPS is fully 3D-printed.
The name TOPS also spells SPOT backward: SPOT being the famous Boston Dynamics robot.

This project was heavily inspired by the YouTuber James Bruton, who built openDog V3, another open-source quadrupedal robot. The goal of this project was not only to create a functional robot, but to make a robot that provided a sense of realism. Getting a quadruped to walk is one thing, but getting a quadruped to walk with dynamic motion is another.

Making Motion

The actuator design of TOPS was the first step in the build process. The most ideal actuator design for a quadrupedal robot is one that follows the quasi-direct drive (QDD) scheme. A QDD actuator can be defined as an actuator that has a low enough gear reduction (under 10:1) to retain the benefits of a direct drive actuator (like efficiency, speed, and backdrivability) while also having a high torque output. To ensure that high torque is achieved with a low gear ratio, it is best to use a high-torque motor. I decided to use Eaglepower 8308 90KV brushless motors that I found on AliExpress for only $60 each. Apart from being cheap, I chose these agricultural drone motors because of their flat and wide pancake-like shape.

Pancake-style brushless direct current (BLDC) motors have high torque densities due to having a large gap radius or distance from the centre of the motor to the rotor. I found the theory and design of an optimal actuator best summarised in an article by the MIT Biomimetic Robotics Lab entitled ‘Optimal Actuator Design’.

These motors gave me plenty of power for just $60

After motor selection, I had to figure out the gear reduction. Planetary gear drives are the common choice for QDD actuators due to their compactness and simplicity. I decided to go with a 9:1 planetary gear reduction since it puts the peak theoretical speed of the actuator at around 222 rpm at 22.2 V. This seemed to be more than fast enough. I used helical gears since they provide gradual contact between engaged teeth, making them both quieter and able to withstand higher loads when compared to standard spur gears.

Motor control was the next item on the actuator design list. Motor controllers are what transform a purely mechanical actuator into a dynamic robotic limb. While drones and RC cars use ESCs (electronic speed controllers) to control a brushless motor, field-oriented control (FOC) controllers are the preferred boards for robotic applications.

FOC is a control method for brushless motors that allows for closed-loop position, velocity, and torque control. FOC controllers can smoothly drive a BLDC motor with an attached load, which is why they are best suited for robotics. FOC controllers essentially turn a BLDC motor into a virtual spring that can be dampened or stiffened by changing different gain parameters. This added compliance to a robot’s actuators enables abilities like shock absorption, recovery from being pushed, and the ability to walk across uneven terrains. The FOC controller that I chose to use for this project was the ODrive S1. The controller setup is quite simple: the motor’s three phases connect to the controller and an encoder magnet is added to the motor’s shaft. An onboard or external encoder is then able to read the motor’s position. From there, the motor can be calibrated and configured with different settings.

All Together

The full actuator design has three sections: bottom, middle, and top. The bottom section houses the ODrive controller which reads the position of the brushless motor using the ODrive’s onboard encoder.

The middle section houses the brushless motor. This section features slots around the radius of the housing which act as air vents for the passive cooling of the motor.

Planetary gears give good reductions without taking up too much space

The top section houses the planetary gear-box and the output shaft. The sun gear is directly mounted onto the BLDC motor and the planet gears are suspended on a planet carrier. The actuator utilises 13 3D-printed parts that I printed on my Creality CP-01.

Below are the specs for a single actuator:

  • Total costs: $247

  • Total weight: 935g

  • Dimensions: 133 mm × 105 mm

  • Peak torque:16.36 Nm.

First leg design

With the actuator design complete, the next step in making TOPS was to design a single 3DOF leg. I went through two different leg designs before moving to the full robot design.

A 12DOF quadrupedal robot is made up of four legs, each leg having three actuators. The three actuators are the abduction/adduction (abad), knee, and hip actuators; each is named after the joint that they control.

One design choice that was made early on was to integrate parts of the leg design into each actuator’s design rather than designing the leg around a standard actuator. In other words, each of the actuators has a slightly different exterior design. This helped to limit the number of extraneous parts needed.

The knee actuator, which rotates the forearm, uses a 1:1 belt pulley reduction to reach the knee joint. The forearm is made from a carbon fibre tube. The foot is in the shape of a sphere and was simply 3D-printed for this prototype. In total, the single-leg prototype weighed 3.42kg.

To test the leg, the actuators were connected to a Teensy 4.1 microcontroller via UART.

The motor controllers help hold the motor in the right position

While the ODrive’s onboard encoder can measure the absolute position of the BLDC, it cannot measure the absolute position of the output shaft due to the 9:1 reduction. I therefore decided to use limit switches to home the actuator.

The first step in programming the leg was to derive inverse kinematic equations to accurately place the foot in a known position in 3D space. The derivation process largely consisted of simplifying the leg design into a series of lines and solving for different angles by forming triangles with those lines. These equations allow the computer to know exactly how to position each actuator to place the foot at an input X, Y, Z position.

Second leg design

Following the first leg design, I saw room for improvement in the areas of weight, communication, homing, and overall aesthetic.

To reduce the weight of the leg, I decided to add weight-reducing slots and holes to all of the parts; however, the biggest weight reduction came from completely redesigning the knee actuator. Previously, the knee actuator design, like the other actuators, had a 9:1 planetary gear-box. It was then connected to a 1:1 belt pulley system to reach the knee-joint. This time, I decided to remove the planetary gear set from the knee actuator and incorporate the 9:1 reduction into the belt pulley system instead. This also reduced the overall width of the leg, therefore needing less torque to be applied to the abad actuator.

The second leg design prototype weighed 2.98kg, which is 0.44kg lighter than the initial prototype. Previously the communication protocol used to communicate the ODrives with the Teensy was UART. Unfortunately, the Teensy only has eight UART ports when twelve are needed for the full robot. I decided to switch to CAN bus communication.

CAN bus is commonly used in modern vehicles, and it simplified the wiring as only two pins on the Teensy are needed: CAN High and CAN Low.

All the actuators for one leg

Another change made in the second prototype was to get rid of the limit switches for homing and, instead, utilise the physical limits of each joint. When performing the homing sequence, each joint is moved to its physical limit. Since this position is unchanging, it can be considered the home position. This home position can then be worked into the inverse kinematic equations as constant offset values.

Full robot design

With the second prototype made, I felt comfortable moving onto the full quadruped design. I used four carbon fibre tubes to make up the frame of the robot. Each leg then slides onto two of the tubes and is secured with clamps built into the abad actuator housing. The front of the robot houses a small 16×2 LCD screen to show the robot’s current mode of operation.

TOPS is controlled with an eight-channel RC remote and is powered by a 6S (22.2 V) 5200mAh LiPo battery. The actuators are directly powered by the battery while the Teensy is powered by a 5 V regulator. The battery is monitored by a voltage display on the left side of the robot.

It took three weeks to print everything on my single printer, after which I had to put everything together.

First, I built the twelve actuators, then the four legs. Finally, I brought these together to make the full robot.

Assembled QDD actuators

I decided to cast the feet in 30A silicone, which is somewhere between the squishiness of a rubber band and an eraser. First, I had to 3D-print the sole and the mould.

To cast the feet, each sole was suspended in the mould and then I poured in the A-B silicone mix to cover the surface of the sole. As a result, the foot has a squishy and high-traction silicone exterior and a rigid 3D-printed sole that allows it to be connected to the forearm.

Gait sequencing

The basic principle of programming a quadruped to walk is to have a pair of diagonal feet in contact with the ground at any given moment: this maintains balance and is otherwise known as trotting. Getting a single foot to take a step forward involves four commands:

  1. Move foot up

  2. Move foot forward

  3. Move foot down

  4. Move foot backward to original position

Getting the robot to walk forward is essentially a two-step sequence. First, two diagonal feet must simultaneously take a step. As these feet touch the ground, the two other diagonal feet begin to take their step. As those feet begin to touch the ground, the sequence is repeated.

To walk in another direction, step 2 of the above step sequence is replaced with the desired direction of travel (backward, right, or left), and step 4 is replaced with the direction opposite to the direction of travel (forward, left, or right) to move the feet back to their original positions.

My actuator ready to be assembled into the robot

To rotate the robot, a slightly different approach is taken. In this case, diagonal feet are moved sideways but in opposite directions. While the sequences themselves are simple, programming them is a bit more challenging. There are many variables to consider, like the amount of time each leg is off the ground, how far the legs lift off the ground, how big each step is, and how fast the legs accelerate. These factors not only determine if the robot can walk in the first place, but how dynamic that walking motion is.

Looking back

  • Total cost: $3300

  • Total project timeline: three months

  • Total weight: 13.4kg

  • Weight of 3D-printed parts: 4.5kg

  • Full battery run time: 10–15 mins

Constructing a robotic system from the ground up was a great engineering exercise. As it turns out, a 3D-printed planetary gear-box can work quite well for large-scale projects with heavy loads. I plan to continue to try out different gearing, motors, and manufacturing methods for more optimal actuator designs. In terms of dynamic gait, I think that TOPS performed fairly well; however, there is lots of room for improvements.

The main mechanical limitation of this project is that the knee-joints skip a lot due to the small contact area between the belt and the smaller gear. Tensioning the belts did not fully solve this issue. In the future, I think it would be best to keep a similar configuration to the initial leg design and have the gear reductions built into the knee and then use a 1:1 belt pulley.

One of the shortcomings of this project on the software side is having to manually calibrate each leg on startup. This became quite a labour-intensive process throughout the testing phase.

Another software shortcoming was a lack of environmental feedback. In the future, it would be best to use an inertial measurement unit (IMU) so the robot can correct itself if it encounters something unexpected.

I also feel that the stepping sequences are a bit rudimentary and could be smoothened to reflect a more natural gait. I hope to address these in my future robot dog projects. Until then, it’s safe to say that TOPS is my most advanced robot dog to date.

From HackSpace magazine store


Subscribe to our newsletter