Background
As part of the Mechatronic Systems module at Ruhr-Universität Bochum, students were offered an entirely voluntary side project — no grade bonus, no credit points, purely optional. Those who signed up received a kit of electronic components and a set of video tutorials (~13 hours of recorded instructions) to build a small self-balancing robot.
The robot's concept is similar to a Segway: two motorised wheels, an IMU sensor to track orientation, and a microcontroller running a control loop to keep the robot upright by continuously adjusting wheel speed and direction.
Hardware
- Microcontroller: Teensy — compact, fast, suitable for real-time control loops
- IMU sensor: inertial measurement unit tracking tilt angle and angular velocity
- Motors: two small DC motors with encoders for speed feedback
- Communication: Bluetooth module for wireless control via serial terminal
- Frame: custom chassis, hand-assembled and glued
- Electronics: all components hand-soldered onto the board
The Problem with the Official Tutorials
The video tutorials covered construction and wiring in detail — but stopped short of a working solution. At the final stage, where the robot was supposed to actually balance, the tutorial authors abandoned the project. The robot in their videos never achieved stable balance.
This meant that completing the project required going beyond the provided material and finding an independent solution.
What I Did
After working through the assembly and getting the hardware running, I analysed the reference code carefully and identified a bug in the control logic — a flaw in the way the IMU readings were being used to drive the motors.
I corrected the bug, tuned the control parameters, and extended the implementation. The result was a robot that balanced stably and could be driven in real time via Bluetooth from a mobile phone using a serial terminal app.
What This Project Demonstrates
This was a fully voluntary project with no academic incentive. I took it on because the intersection of mechanics, electronics and software genuinely interested me — and because I wanted to build something that actually worked, not just follow instructions.
When the official guidance ran out, I did not stop. Finding and fixing the bug in someone else's code, then extending it further, is the part I am most satisfied with.
