Why Our Robot Fell Over (and What We Learned)
Last month, in front of forty visitors, our walking robot took three confident steps and fell flat on its side. Nobody was hurt and nothing broke except our pride. This is what happened, written the way we write all our post-mortems: focused on the system, not on blaming people.
What happened
The robot had walked the same route more than two hundred times in the lab. On demo day it was moved to the lecture hall, which has a polished floor. On the third step its left foot slipped, the balance controller over-corrected, and the robot tipped over.
Root cause
The balance controller assumed a floor with at least as much grip as the lab carpet. It had never been tested on a slippery surface.
Why we did not catch it
- All two hundred test walks happened on the same floor.
- Our simulator modelled friction as a single fixed number.
- The demo checklist covered batteries and network, but not the environment.
What we changed
- Varied test surfaces. The robot now walks on carpet, tiles, wood and a sheet of plastic every week.
- Randomised simulation. Each simulated walk picks a random friction value, so the controller learns to cope with uncertainty instead of one perfect floor.
- A site check before demos. One person visits the room the day before and tests a few steps on its actual floor.
Result
In the following month the robot completed 150 walks across five different surfaces without a single fall.
The lesson
A robot that works perfectly in one place has only proven that it works in one place. Test where things are different, not where they are comfortable.