For quite some time, I’ve been developing a two wheeled balancing robot. You know, like a Segway. But in this case it is somewhat smaller, as to minimise damage when hitting something at high speed. That happens rather often, due to the very high maximum speed of this robot.
This post will cover the architecture of the robot, explaining all ins and outs. Many balancing robots have been made before, but this one has some nice features that make it very well behaved. Also, everything has been designed to make the robot easy to replicate. As one of the goals of this project is to get other people to work on the robot, all source files will be made open source. Also, in a future post I hope to document how to build one.
Just to be clear: the purpose of me making this project open source, is not for people to get such a cute, fun robot, that they’ll play with and then never use anymore. The purpose is to educate other people, to share knowledge, and to create and extremely good performing robot together. Just because. Because developing technological things without purpose is fun.
In order to balance an unstable system, negative feedback is required. The diagram below illustrates the approach. Besides a feedback loop, a sensor to measure an error (or rather the sytem response), and an actuator to minimise the error, are required.
Sensing and actuation
Getting a sensor with sufficient accuracy and bandwidth is relatively easy; in this case the well-known (and mostly cheap) MPU6050 IMU is used. The accelerometer provides a long term stable, but noisy signal, especially if you accelerate fast. The gyroscope on the other hand gives an accurate, high speed signal, with drift however. Combining the two using a simple complementary filter gives a stable signal, representing the angle of the robot.
Next, an actuator needs to be selected. A common choise is a DC motor, for example for its low cost or simple control. However, a DC motor has in general a too low torque to directly drive the wheels of the robot. A gearbox is used to increase torque, but several disadvantages are introduced as well. Cheap gearboxes have severe backlash and friction, which make the control loop non-linear, and therebey making everything a lot more complicated.
This is where the stepper motor comes in. This idea isn’t new, serveral other examples of balancing robots with stepper motors are available. For some examples, see here, here or here. Steppers are quite suitable for the job: direct drive, relatively high torque, low inertia (which isn’t true for a DC motor with high gear ratio), and no backlash. Stepper motors are commonly used in for example 3D printers, and can hence be found for a low price (about €10 each). Driving the steppers is also done with 3D printer related parts. A so called step stick, containing a DRV8825 IC, arranges all the power electronics, accepting a logic step and direction input.
Then comes the software. In my opinion, this is the part where the most difference can be made. The above description holds for a lot of balancing robots. With suitable software / control implementation, a lot of differentation can be made. The software of this robot runs on an ESP32, a dual core microcontroller with integrated WiFi and Bluetooth. Using an ESP32 allows for several nice tricks, such as control with a smartphone via WiFi / Bluetooh (not implemented yet), OTA, wireless data logging, etc.
Currently, the software runs two control loops at 200 Hz. See below for a schematic view of the two (cascased) controllers. The first control loop tries to minimise angle error, i.e. keeping the robot upright (in case of a zero reference). The second control loop either controls position or speed, depending on user input. If no input is present, position is regulated to be zero. Otherwise, the outer controller manipulates robot angle to obtain a speed equal to the speed setpoint. To give an example: if the robot is standing still, and a positive (forward) speed setpoint is given, the robot tilts forward until it reaches the desired velocity. When standing upright, the inner control loop moves the wheels backwards, such that the robot will tilt forward.
For powering the robot, I currently use a 6S1P (24 V) 2650 mAh LiPo battery. That’s quite a big one: it allows for up to 5 hours of driving time. So, such a big battery is not strictly required. Besides this battery being relatively cheap (in Wh/€), a big mass on top of the robot makes the robot fall “slower”. This makes stabilising the control loop easier, and, it also looks more natural in my opinion. A sturdy case has been 3D printed to fit tightly around the battery, to allow for protection. The high voltage of the battery allows the steppers to be run at extremely high speeds. Note that 6S is over the top, and 3S will give sufficiently high speeds.
The last part to add is a PCB. For the first robot versions, I developed some experimental PCBs. For the current version, I’ve drawn a simple PCB, based on commonly available modules (IMU / step-stick / ESP32 dev board), which allows for easy assembly. The PCB is drawn in KiCad, which is open source software. In case you want to make something yourself (on an experimental PCB), see the PDF of the schematic in the Git repo.
The total cost of the robot is quite limited due to use of standard components. Electronics are about €10, steppers €10 a piece, battery between €5 and €30. The frame can be printed cheaply (see Git repo for source files), or simply zip tie everything to a piece of wood. Currently I use an RC transmitter / receiver, which drives the cost up, but as soon as WiFi/Bluetooth control is implemented, it isn’t required anymore.
To end this post, some more pictures of the complete robot(s). Yes, it has a small brother :).
Source files can be found in the Git repo. It is highly appreciated if you contribute to the project!
The subolders in the repo also contain readme files, explaining how to assemble the electronics, and how to setup the software environment.