mike moore
Projects / Bobble-Bot

Bobble-Bot

A two-wheeled balancing robot, built so that students and hobbyists could play with feedback control on something real.

archive7 posts2018 – 2019 bobble_controllers
Assembly
robot Bobble-Bot 2view exploded
Bobble-Bot 2 exploded assembly view, parts separating and coming back together
Bobble-Bot 2, exploded. Every part of the robot, from the wheels and motors to the Pi and the battery.

Bobble-Bot is a two-wheeled inverted pendulum. It is a classical problem in control theory, which is exactly why it makes a good teaching platform: the maths is in every textbook, and the robot falls over the moment you get it wrong.

I wrote the balance controller, the Gazebo simulation used to develop it, and the CAN bus drivers between the Raspberry Pi and the motor controller firmware. The controller runs in real time on the Pi. All of it is open source, because the point was for other people to be able to pick it up.

Fig. 1
Two 3D-printed Bobble-Bot chassis on a cutting mat, with the CAD model on the monitor behind them
Two printed chassis on the mat, and the model they came from still open on the screen behind. Most of this project happened in that gap.
Fig. 2
top Gazebo bottom the robot same manoeuvre
The simulation above, the robot below, driving the same square. This is the whole argument for developing against a sim: when the two move together you can trust the one that does not fall over and break.
Fig. 3
sim Gazebo + ROS controller real-time, Pi
The simulation on its own, which is where nearly all of the controller work happened before it ever ran on the robot.

What I wrote about it

These are from 2018, moved here from the old site before that domain was reused. Oldest first, which is roughly the order the work happened in. The text is unchanged.

The controls post lost four figures with the old image host. Three are back: both halves of the equations of motion and the gain table come from my 2018 thesis defence, and the control-law diagram is redrawn from the cascade described in our IEEE paper. Each says so in its caption.

All seven are here. Four figures did not survive the move: three screenshots in the CI post and one still in the Matlab post. The CI post carries a marked plate where each one stood, so the gap is visible rather than silently papered over. The Matlab still was replaced with a recording of the same experiment, which says so in its caption.

Fig. 4
chassis 3D printedboard hand fitted
A hand fitting a circuit board into the 3D-printed Bobble-Bot chassis on a workbench
The part the simulation cannot do for you. Printed chassis, a board going in by hand, and a bench that is not a rendering.

The bit that carried over

Two habits from Bobble-Bot are the reason the pendulum work looks the way it does. The first is developing against a simulation from day one, so that a change can be tested before it can break hardware. The second is treating the analysis as code — recorded runs into a notebook, plots regenerated from a script rather than screenshotted once and pasted somewhere.

Fig. 5
tool Jupyterdata rosbag
A Jupyter notebook showing tilt-tuning plots from recorded Bobble-Bot runs
Tuning the tilt controller from recorded runs in a notebook. Same idea as the Monte Carlo work on the pendulum, several years earlier and with cruder tools.
Fig. 6
An oscilloscope showing a square wave with cursors measuring a 1.000 ms period
The loop, on a scope. Cursors at 1.000 ms — a 1 kHz control loop holding its period on a Raspberry Pi, which is the whole reason for the real-time kernel.

There is a paper about the real-time control side, Real-Time Control of a Self-Balancing Robot Using ROS, if you want the more formal version.