Designing and Building an Agile Inverted Pendulum Robot

In several previous posts on this blog we went through the design/learning of control policies for virtual inverted pendulum robots in digital simulation. In this post we are going to discuss the design and building of a real-life inverted pendulum robot. While inverted pendulum is a very common theme in robotics, this particular design has some features that are not so commonly found in other robots. In particular, these are the use of servo-controlled Permanent-Magnet Synchronous Motors (PMSM) and robot control via Model-Predictive Control (MPC). These features give the robot increased agility as will be seen later on. Let’s get to it.

Inverted pendulum robot with controller

Hardware

The main hardware components of the robot are a Raspberry Pi 3B, an ODrive 3.5, a BMI160 IMU, a Logitech F710 wireless gamepad and two PMSM motors and corresponding incremental encoders. The Pi gets power from a 5V 3A BEC.

BOM is as follows:

Disclaimer: This post includes affiliate links to product listings on eBay. Please read our Affiliate Link Policy for more information.

The Raspberry Pi has several responsibilities. At first, it is responsible for receiving measurements from the IMU and movement commands from the gamepad, and applying a complementary filter to improve the raw IMU values. In addition, it is executing the MPC code and converting the model output values that represent force to required current. Finally, it is sending the generated commands to the ODrive. In turn, the ODrive provides low-level motor control based on the commands received from the Raspberry Pi and the position signal from the encoders.

Robot Design

In order to facilitate rapid prototyping, the robot frame is based on a 2040 V-Slot profile which was cut to 250mm and where all components mount on. Design-wise the most involved component is the motor, encoder and wheel mount, which secures all motion components on the profile with minimal screws being required. In addition, custom plastic mounts were designed for mounting the Raspberry Pi, ODrive and IMU on the profile. Finally, wires and the BEC are mounted using either velcro straps or zip ties.

All STL files for the 3D printed parts are available in Thingiverse.

Software & Control

The Raspberry Pi executes an MPC controller at a rate of 200Hz, and generates current commands which it then sends to the ODrive through the UART port and a custom binary protocol. The ODrive runs a custom firmware that decodes the commands and sends motor position information as a response. The IMU is connected through the SPI port on the Raspberry. The Raspberry gets both gyroscope and accelerometer values and performs simple fusion using a complementary filter.

The robot control software is written in C++ using the MPC framework of the dlib library. The state-space equations are derived from this Matlab tutorial website, which presents a very detailed overview of the inverted pendulum modeling and the transfer function derivation. The parameters for the robot model and the MPC controller have been experimentally determined, and for that reason some of the parameters may in fact be inaccurate.

Read also:  Designing a Brushless Quadruped Robot

Performance

In retrospect, MPC took quite some time to get right. I had to spend quite a bit of time to ensure that the robot transfer functions and controller parameters are correct, and during that course there were several non-obvious decisions that I had to make. As a matter of fact, for quite some time a reference PID controller managed to balance the robot better than MPC! However, after much effort the robustness of the MPC approach was evident. A conspicuous behavior of MPC, for instance, was on handling disturbances, where the MPC robot would return to setpoint without any overshoot, even on major disturbances.

It is useful to note that the Raspberry Pi is sometimes challenged at the rate of 200Hz, and in extreme cases the MPC controller may not converge within the allowed timeframe (5ms). Even though the model in this case is not optimized at all, this still demonstrates the computational requirements of MPC, and justifies the increased interest in the technique as computational power increases.

The control software for the inverted pendulum robot will be available as an open source project on Github in the near future.

Testing

Overall the robot was able to perform fairly well in various trials. The only evident issue is the presence of a small oscillation when the robot is stationary. Initially ti was thought that the presence of cogging torque in the PMSM motors could be the reason behind this behavior. However, after performing anti-cogging calibration in the motor controller the problem still persisted (although to a lesser degree). Thus it seems that the oscillation could be due to misconfiguration of the MPC model parameter values, and is something that additional tuning could eliminate.

Another explanation is that the robot is running in position control mode, that is, it is trying to maintain the position of the robot and since this is difficult to attain perfectly, it ends up oscillating around the target position. Using a velocity target instead for the MPC could eliminate oscillations.

The following video demonstrates robot performance in various scenarios.

Robot Testing

Conclusion

This post discussed the design and building of an agile inverted pendulum robot with novel features compared to the majority of existing designs. Through the use of servo-control of PMSMs and MPC control of the robot, good stability and control was achieved, while the theoretical maximum speed of the robot should be really high. Ideas for development include the addition of degrees of freedom to allow the robot to tilt and adjust it’s height, to achieve a more robust balancing.

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

2 replies on “ Designing and Building an Agile Inverted Pendulum Robot ”
  1. How did you choose which motor to use? I guess that you obviously wanted low cogging, so you decided to use a 22N24P motor, but how did you decide on the other motor parameters?

    1. I used the motors I had at hand from a previous quadruped robot project; there the main critera were cost vs. air gap radius. The Tarot 4108 was a favorable choice on the low price tag side (the immediate next air gap radius of 50mm carries a 3x/4x price tag increase).

      In that project cogging was not so much an issue since I was mainly using position control. However, if I were choosing motors for the balancing bot specifically I would certainly consider low cogging. I got away with using ODrive’s anti-cogging feature, but ideally a low cogging motor would behave best.

Leave a Reply

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