Brushless Robot Dog Updates

February 1, 2024


Following the success of integrating the Champ motion control algorithm into the Red Dog quadruped, the next step was building a strong enough brushless design to overcome the difficulties of the previous designs of having lower torque. To meet this end a possible design was sought after to get the most torque out of an actuator while also moving fast enough for the robot. 

The controller board must also be fast enough and reliable to send and receive commands to translate commands while also being able to properly identify each motor with its own motor ID. With all of these requirements in mind, the closest board was the developed board from MIT mini Cheetah developed by Ben Katz which uses an STM32 as its main processor. 


The brushless motors by themselves do not have enough torque for moving a heavy robot thus a gearbox must be built to satisfy the requirements. A 3D-printed actuator named OpenTorque Actuator from G-Levine was created and tested its performance with our current donated motors from T-motors U8. 


The results from such tests determined that they were able to properly transmit the torque. The results below show the amount of torque that they generated using a scale to determine the amount of weight force produced by the motors themselves and with the actuator. These results were then compared to find the difference in the loss of torque when using the gearbox. 

Motors alone
(weight g/1000*9.8*0.16)
8:1 Actuator gearbox

A modified version of the gearbox was created as the 8:1 while great in torque, it ran slower. To fix that we decided to create an alternative version which consists of 6:1, reducing the gearing ratio to lose torque but increase rpm. 

Motors alone
(weight g/1000*9.8*0.16)
6:1 Actuator gearbox

Having proved that these two configurations can provide enough torque the next step was to determine the position of the motors. Using the firmware installed in the boards we can see the position of the magnetic encoder in real time as shown below. 

Video file


The next steps were to determine and utilize these positions to adapt them to give the correct positions of the gearbox actuator.  The way the motor controller board can send and receive commands is through a can communication message. Each message can be sent to a specific motor ID using a can bus communicator. The commands are as follows, enable motor, disable motor, and position. For the motor to start it must be enabled before sending a position value. Each position command must have a position, velocity, kp,kd, and torque. 

Video file


To test the gearbox actuator, we used the mini-cheetah-tmotor-python-can library to test the position values on our actuators. Below we can see that the rotation occurs at almost the correct position. The minimal error in position could be due to the backlash of the gears inside the gearbox. 

Video file


To be able to test the actuators more efficiently, a GUI that allows us to input multiple values for position,velocity,kp,kd and torque was created. 

Video file


Below is a demonstration of the setup that we did for testing the torque of the actuator by calculating the amount of force produced by the actuator. To do this the weight value was recorded then using the force formula of F= ma. In this case, the mass is the weight of the balance and the acceleration would be due to a gravity of 9.8m/s^2 and finally the distance from the center to the end of the arm of 15cm.

Video file


6:1 gearbox actuator testing was done of the similar manner as the 8:1 to compare the torque values

6to1 with motordriver
Video file


The design of the quadruped body began with having a possible 8 DOF configuration, and a 12 DOF later on. The legs are located at the upper portion of the quadruped to reduce the weight at the end of each leg as this can hinder the performance of the quadruped. To achieve this the lower leg was built using a belt and pulley located at the end of the actuator and the start of the lower leg.





The leg was 3D printed using PETG and a metal pulley at each end. It was chosen to use a metal pulley to decrease the amount of backlash that could be caused by using this system. Below we can see a test of leg working at a set position. 

Video file




Having success with the motion of the leg it was time to test the leg to see if it could hold itself and move. The station was from a repurposed camera holder. Using the bracket holes the back of the actuator was screwed onto it. Below is a test of the leg at the station, from the video it can be seen that the leg can hold itself and even when external forces. At a later time, it was tested that the limit of the amount of force it could sustain itself was of 1kg.

Video file


Seeing the leg station was a success, we moved on to the hardware interface between the actuators and the champ motion software. Incorporating the commands through CAN highlighted in the Python library, a C++ code was developed to control the actuators similarly. The goal for this new control algorithm was to speed up the commands being processed by the Python library and also for the ease of incorporation into the champ motion software. After further testing and debugging a possible code was developed as shown below where it is shown that a specific motor is selected and spun at a specific position without each interrupting the other.

Video file


After further consideration of the backlash and the cost of building a 3D-printed actuator, we took the opportunity to buy already-made actuators with complete gearboxes and some with a different but similar controller board to the ones previously purchased. We recently received them in the middle of March and we are now building the testing stations to test them for the amount of torque they can produce as well as the accuracy of position.

CubeMars Shipping actuators


Cube Mars boxes
Cubemars 2.1 Motor driver with actuator


Testing Station for CubeMars actuator