crazyflie-behavior
Hide-and-seek drone
A Crazyflie nano drone that plays hide-and-seek with a small child, built with techniques from game NPCs: a map of the room, hiding-spot selection and line-of-sight checks, on a robot whose sensors are noisy and whose position drifts.
While the child waits behind a gate, the drone flies off, lands behind a wall and turns its motors off. The child hunts for it, helped by a flash-and-chirp hint every 15 seconds. When they pick it up, it lights up and the computer plays a fanfare.
Design decisions
-
ADR-0016
Safe because of how the game works
The drone flies only while the play area is empty, then lands and stops its motors before the search begins. A child only ever meets a drone with its motors off.
-
ADR-0008 · 0013
One narrow path to the motors
Only the safety layer commands the drone. The operator's kill switch is the single exception: it can only cut the motors, and it runs on its own thread so it still works if the tick loop hangs.
-
ADR-0012 · 0019
It always lands
The drone only turns off its motors when its downward sensor clearly shows it's on the floor. If that sensor stops working, the drone keeps descending slowly until a time limit says it must have landed. A bad reading can never shut the motors off in mid-air.
-
ADR-0020
Game instincts, robot rules
A game keeps playing and logs the failure. Here, a failure that leaves flight safe is logged and worked around, and one that makes flight unsafe makes the drone fail safe.
-
ADR-0002 · 0009 · 0023
Hardware behind an interface
Behavior code talks only to a drone interface, so the same logic runs against a mock, a simulator or the real Crazyflie, on a 20 Hz tick loop with a swappable clock for tests.
Every design decision is written up with the options considered, 28 records so far. I set the goals and make the calls; implementation is AI-assisted, and each record notes whose idea it was. Formatting, lint, strict type checks and tests, including architecture rules enforced as tests, run on every push.