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.
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.
- Raspberry Pi 3B
- ODrive 3.5 (w/headers)
- BMI160 IMU breakout
- Logitech F710 wireless gamepad
- 5V 3A switching BEC
- 2x Tarot 4108 motors
- 2x CUI AMT102 incremental encoders
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.
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.
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.
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 soon available as an open source project on Github.
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.
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.