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 common 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 we’ll see later on. Let’s get to it.

Inverted pendulum robot with controller


The main hardware components of the robot are: a Raspberry Pi 3B; an ODrive 3.5; a BMI160 IMU; a Logitech F710 wireless gamepad for remote control; two PMSM motors; and two 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. I designedcCustom plastic mounts for mounting the Raspberry Pi, ODrive and IMU on the profile. Finally, I mounted wires and the BEC 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 connects 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 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:  Tinymovr: An Integrated Brushless Motor Controller


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: there, the MPC robot would return to setpoint without any overshoot, even on major disturbances.

200Hz is often a challenge for the Pi, and in extreme cases the MPC may not converge within the timeframe. Even though the model is not optimized, this still demonstrates the computational requirements of MPC. It also justifies the increased research interest in MPC as computational power becomes available.

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


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 trying to maintain the position of the robot; since this is difficult to attain perfectly, it ends up oscillating around the target position. Using a velocity target instead for the MPC could potentially eliminate oscillations.

The following video demonstrates robot performance in various scenarios.

Robot Testing


This post discussed the design of an agile inverted pendulum robot with some novel features. Through the use of servo-control of PMSMs and MPC control of the robot, good stability and control was achieved, while the maximum speed of the robot is estimated really high. Ideas for development include the addition of more DoFs 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:

3 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.