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
Touchdown counts only on a steady downward range reading. Without one, a slow final descent continues until a time limit, so a failing sensor can't cut the motors 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.