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.
From the field
-
First flight 1
First hover through its own code
The first hardware session ended with a 60-second hover at 0.5 m, run by the project's own tick loop and safety layer, landing 4 cm from the take-off mark.
-
ADR-0048
Near the floor, the flow sensor lies
The drone slid as it landed. The analysis showed its optical-flow reading goes bad close to the floor, so take-off and landing now cross that zone level, holding vertical speed only.
-
ADR-0061
Slow climbs, traced into the firmware
In the third session, climbs stalled near the floor. The flight logs and the firmware source showed the firmware's starting thrust sat far below what this drone needs to hover, so the adapter now sets it at connect, to be checked in the next session.
Every design decision is written up with the options considered, 61 records so far. Real flights follow a written field-testing plan: pass criteria set before each session, results fed back into the design. Implementation is AI-assisted; here's how I work with Claude.