Optimal Line-Following Drone
Codename BOLDA reinforcement-learning path planner for the MathWorks Minidrone Competition Europe 2026: a Parrot Mambo follows a red line and lands on the marker, with the policy shipped as baked weights and zero toolbox dependency.
The competition
MathWorks Minidrone Competition Europe 2026, Round 1, flown in simulation. A Parrot Mambo takes off, follows a red line of two to seven straight sections across a 4 × 4 m arena, finds the red circular marker and lands with at least a fifth of its body inside it, all inside a 100 s window. Scoring is lexicographic: C code generation gates everything, then sections navigated, then path accuracy including the landing, then time. Our team, BristolOptimisedLine-FollowingDrone, replaced the hand-tuned path-planning block in the supplied Simulink project with a trained reinforcement-learning policy. I owned that policy. It was the team's primary submission.
The policy
Eleven inputs at 5 Hz: line error, look-ahead heading as sine and cosine, marker error, body velocity, height error. One output, a bounded step on the north/east position reference, ±0.360 m per 200 ms cycle. The bound lives in the output layer, so the action is safe by construction. 11 → 128 → 128 → 2, ReLU, tanh squash. SAC from scratch plateaued, so I warm-started by imitating a recreation of the UNISANNIO 2020 winner, then fine-tuned under domain randomisation. It ships as baked weights and three matrix multiplies, zero RL or deep-learning toolbox dependency. On held-out surrogate tracks it beats the recreated winner on tracking RMS, 0.0438 m against 0.0462 m, at equal sections and landings; UNISANNIO is faster.
Flights
The numbers that matter come from the real Simulink model, scored on ground truth rather than the drone's own estimate. Three campaign flights on held-out generated tracks: real Unreal footage with the flown path, surveyed track and landing circle composited on. Twelve seeds the policy was never tuned against went 12 of 12 at the 0.20 m pad gap. Landings sit 3-20 mm from pad centre. The five small plots are ground-truth flyovers rendered from the saved logs. The last clip is the downward camera bus, logged from the running model and pushed back through the deployed front-end, so the overlay is exactly what the policy saw.
Failures → mechanisms
Every mechanism answers a measured failure. A healthy-looking 100 s flight followed the line beautifully, never armed LAND, then re-flew the route backwards; doubling the coast window across the pad gap fixed it. A perfect landing was rejected when scored off the estimator: ground truth put the miss at 9 mm, the estimator said 347 mm, so scoring moved to ground truth. The arena's yellow decoy square nearly passed for the marker; a colour test now refuses it. An early archive shipped without any of the runtime functions. Code generation is the gating criterion, so it would have scored zero. Hence verification at the archive level. Wind beyond what the policy trained on degrades it; the sweeps show where.
Vision
120 × 160 RGB frames, toolbox-free. Red is isolated by channel difference. The line is read through an annulus, the crown, whose forward cone acts as corner memory. The marker is found by exact erosion with a colour test that refuses the yellow decoy. The loop is the onboard camera with the crown overlay drawn on. The policy trained against domain-randomised frames, so the textured sim3d floor was never a surprise.
The real aircraft
The physical Mambo flies: piloted hops with the live downward camera and FreeFlight telemetry, and a steady hover seen from outside. Hardware preflight passes 13 of 15 checks. Autonomous deployment is blocked on one thing, an Embedded Coder install, not on the controller.
Report
The LaTeX technical report: system, dynamics model, vision simulation, reward, training and results. The archive that went to MathWorks carries a shorter ALGORITHM.md; this is the long version, with the surrogate benchmark and the caveats that also went into SUBMISSION.md.
