ECE 484 Principles of Safe Autonomy · UIUC · Fall 2026

Crazy Drone: Contouring MPC and a Distilled Neural Tracker for Crazyflie Racing

1University of Illinois Urbana-Champaign 2Zhejiang University
Team ZJUI Meta

Crazy Drone flies a 43 g Crazyflie through gate courses at up to 2.8 m/s. The light-blue curve is the reference path; the orange dots are the 1 s trajectory the contouring MPC plans and re-solves every 10 ms.

Abstract

We race a Crazyflie 2.1 quadrotor through gate courses in the crazyflow MuJoCo simulator. The drone may only send collective-thrust and attitude commands at 100 Hz. It sees the true pose of a gate only when it is within 0.7 m of it, and it has to finish five laps without touching anything, under action noise, mass randomization, shifted gates, wind, gusts and battery sag.

Our first controller adapts Model Predictive Contouring Control (MPCC) [1] to this interface. Instead of tracking a timed reference, the optimizer chooses its own progress along an arc-length path and trades speed against a gate-aware contouring error. It uses the system-identified closed-loop attitude model of the drone, a soft safe corridor around gate frames and obstacles, a disturbance observer, and replanning whenever a gate is revealed. Solved with acados [2] in about 1.3 ms per step, it finishes 90 of 90 simulated races on the three provided tracks.

Our second controller distills the MPCC optimizer into small neural networks. The planner is kept unchanged; only the solver is replaced. The networks are trained only on randomly generated tracks, first with behaviour cloning and then with DAgger, with the MPCC as expert and safety pilot. Along the way we found and fixed a margin bug in the expert itself. An ensemble of five 64×64 networks (67k parameters) finishes 88 of 90 races on the provided tracks, which it never saw in training, within 0.3 s of MPCC's lap times, at 0.7 ms per control step and with no optimizer on board.

90/90MPCC races finished on the 3 tracks × 3 conditions
88/90Distilled network ensemble, on tracks never seen in training
17.0 sMean time for 5 laps of the U-turn track (MPCC, nominal)
0.7 msNetwork control step, vs. 3.5 ms for MPCC (median, incl. features)

Simulation Videos

Model Predictive Contouring Control

acados SQP-RTI at 100 Hz; the orange dots are the 25-stage, 1 s prediction.

Learning-Based Tracker (Distilled MPCC)

Five 64×64 MLPs, averaged; the green curve is the 2.8 m of path the networks see.

The Task

Each track is a sequence of square gates (0.72 m frame, 0.40 m opening, at 0.7 m or 1.2 m height) plus thin vertical obstacle poles. Gates must be crossed in order and along their local \(+x\) axis, five laps in a row. Touching a gate, a pole or the floor, or leaving the flight volume, ends the race. The provided tracks are a circle (4 gates), a U-turn with 180° hairpins (4 gates) and a figure-eight lemniscate (6 gates).

  • Interface. At 100 Hz the controller receives position, attitude, velocity and body rates, and returns \([\phi_c, \vartheta_c, \psi_c, f_c]\): roll, pitch and yaw angles and the collective thrust. The Crazyflie's onboard attitude loop does the rest. Physics runs at 500 Hz.
  • Partial observability. Gate and obstacle poses are reported at their nominal values until the drone comes within 0.7 m. The hardware environment masks motion-capture poses in exactly the same way.
  • Disturbances. Every run has action noise, random force noise of ±0.1 N, ±5 g mass and inertia randomization and a random start pose. We also test with shifted gates (up to ±0.15 m, ±0.15 rad, revealed late) and with wind: 1.1 m/s steady, 0.8 m/s gusts and 10 % battery sag.

Method I: Model Predictive Contouring Control

The path is replanned whenever the true pose of a gate or obstacle is revealed.

Contouring instead of tracking

A classical pipeline fixes a timed reference \(\mathbf{p}_{\mathrm{ref}}(t)\) and tracks it. If the drone falls behind, it chases a reference point that may no longer be reachable. MPCC drops the time. The reference is a purely geometric path \(\mathbf{p}_d(\theta)\), parameterized by arc length, and the progress \(\theta\) becomes a state of the optimizer, with \(\dot\theta = v_\theta\). The tracking error \(\mathbf{e} = \mathbf{p} - \mathbf{p}_d(\theta)\) is split along the unit tangent \(\mathbf{t}(\theta)\) into a lag part and a contour part:

\[ \mathbf{e}^l = (\mathbf{t}^\top \mathbf{e})\,\mathbf{t}, \qquad \mathbf{e}^c = \mathbf{e} - \mathbf{e}^l . \]

Every 10 ms we solve, over a 1 s horizon of 25 stages,

\[ \min_{\mathbf{u}_{0:N-1}} \; \sum_{k=0}^{N} \Big( q_l \|\mathbf{e}^l_k\|^2 + q_c(\theta_k)\,\|\mathbf{e}^c_k\|^2 + \|\mathbf{u}_k\|^2_{R} - \mu\, v_{\theta,k} \Big) \quad \text{s.t. dynamics, input and corridor constraints.} \]

The progress reward \(\mu v_\theta\) pushes the drone forward. The contour weight keeps it on the racing line. Because the speed profile is the result of the optimization, the drone slows down for tight turns and gates and speeds up on straights, and it may cut corners between gates.

Adapting the paper to a 43 g Crazyflie

Romero et al. [1] control a 0.85 kg racing quadrotor through its four rotor thrusts. We can only command attitude and collective thrust, so we use the model the simulator integrates, which is a system-identified model of the closed loop “Crazyflie + onboard attitude controller”:

\[ \dot{\mathbf{v}} = \tfrac{1}{m} R(\boldsymbol\eta)\begin{bmatrix}0\\0\\c_f f\end{bmatrix} + \mathbf{g} + \tfrac{1}{m} R D R^\top \mathbf{v} + \hat{\mathbf{d}}, \qquad \ddot{\boldsymbol\eta} = \mathbf{a}_\eta \odot \boldsymbol\eta + \mathbf{b}_\eta \odot \dot{\boldsymbol\eta} + \mathbf{c}_\eta \odot \boldsymbol\eta_c, \qquad \dot f = \tfrac{1}{\tau_f}(f_c - f). \]

Each Euler angle responds like a damped spring to its command (roll/pitch: 13.7 rad/s, damping 0.46, steady-state gain 0.73), and the thrust lags its command by 80 ms. As in the paper, the optimizer chooses the rates of the commands, which keeps them smooth and bounded. The state has 18 dimensions: position, angles, velocity, angle rates, thrust, the three commands, \(\theta\) and \(v_\theta\).

What we added for safety

  • Gate-aware contour weight. A sum of Gaussians centred on the gates \(\mathbf{g}_j\), \[ q_c(\theta) = q_{\mathrm{nom}} + q_{\mathrm{gate}} \textstyle\sum_j \exp\!\big(-\|\mathbf{p}_d(\theta) - \mathbf{g}_j\|^2 / 2\sigma^2\big), \] is small between gates and large inside them. The drone may cut corners, but it threads the gates precisely.
  • Soft safe corridor. At every stage the contour error must stay below the clearance to the nearest frame, pole or obstacle minus the drone's radius, and obstacles get soft keep-out cylinders.
  • Caution near unrevealed gates. Progress speed is capped at 1.5 m/s within 1 m of a gate whose true pose is not known yet. When the pose is revealed, the path is replanned.
  • Disturbance observer. An estimate \(\hat{\mathbf{d}}\) of the unmodelled acceleration (wind, mass error, battery sag) enters the model. When it is large, the controller slows down.
3D view: the drone between two gates with a light-blue reference path and an orange dotted MPC prediction
Reference path (light blue) and the 1 s MPC prediction (orange) in the simulator.
Two top-view snapshots of the path ahead and the MPC prediction, which leaves the path between gates and rejoins it inside the gates
Top view at two instants. The prediction (orange) cuts the corner between gates and rejoins the path inside them.

Method II: Distilling MPCC into a Neural Tracker

Only the outlined orange block is learned. Everything else is shared with the MPCC controller.

Distill only the optimizer

The planning half of MPCC is cheap and has nothing to learn, so we keep it exactly and let a network replace only the nonlinear program. The network is a path tracker. It sees 20 samples of the path ahead, 0.14 m apart (2.8 m, as far as MPCC's horizon reaches at top speed), the contour weight, corridor radius and speed cap at those samples, the drone state, the previous command, the disturbance estimate and the two nearest obstacles. All of these are expressed in a heading frame centred on the drone, so the network cannot memorize where on the map it is. It outputs the change of the roll, pitch and thrust commands, which is MPCC's first optimal input. That makes its commands as smooth and bounded as MPCC's by construction.

Random tracks, DAgger, and an expert-in-the-loop safety pilot

To show that the tracker works for any path, we train only on procedurally generated tracks (3–6 gates, random headings and heights, 0–3 obstacles placed near the path, nominal / shifted / shifted + wind conditions). The three provided tracks are held out for testing. Behaviour cloning alone reaches only 32 % success on held-out random tracks, because small errors compound into states the expert never visited [6]. With DAgger [3], the student flies and MPCC labels every visited state in shadow mode. If the student leaves the corridor by more than 2 cm, MPCC takes over for 1 s, still labelling, which yields exactly the recovery data the student needs. A fifth of the episodes are MPCC flights with correlated command noise (DART [4]). Success rises to about 79 % after four iterations.

Fixing the teacher. A student cannot beat its teacher, so we stress-tested MPCC itself on 60 random tracks. Every failure was a gate-frame hit. The drone's collision box has a 0.099 m half-diagonal, but the corridor reserved only \(r_{\mathrm{drone}} = 0.10\) m, which left 1 mm of margin inside a gate. With 0.13 m the expert's success on random tracks rose from 53/60 to 59/60 (nominal), with unchanged lap times on the provided tracks.

Ensembles, not RL, closed the gap

PPO fine-tuning [5] with a shaped reward and MPCC as a safety monitor did not improve the policy within our budget (two runs, about 1M steps each). The remaining failures are rare near-misses at gate frames, and their signal was drowned in noise. What worked was averaging five independently trained networks. Their imitation errors are partly independent and cancel in closed loop, exactly where single networks fail: a few centimetres inside a gate.

Results

Top views of five-lap flights on the circle, U-turn and lemniscate tracks; the MPCC and network trajectories nearly coincide Top views of five-lap flights on the circle, U-turn and lemniscate tracks; the MPCC and network trajectories nearly coincide
Five laps on each provided track (top view, same seed, default disturbances). Blue: MPCC. Orange: the distilled ensemble, which has never seen these tracks. Gate frames are drawn with the crossing direction as an arrow; × marks an obstacle. The two controllers fly almost the same racing line and their 5-lap times differ by at most 0.32 s.

MPCC on the provided tracks

Track Condition Success 5-lap time [s] Best [s] Max gate offset [m] Solve, mean / max [ms]
Circle nominal 10/10 25.10 ± 0.31 24.70 0.109 1.29 / 6.65
Circle shifted gates 10/10 24.86 ± 0.76 23.91 0.100 1.26 / 6.34
Circle wind + battery 10/10 27.03 ± 0.59 26.44 0.120 1.23 / 6.71
U-turn nominal 10/10 17.01 ± 0.18 16.82 0.079 1.31 / 3.32
U-turn shifted gates 10/10 17.23 ± 0.39 16.67 0.105 1.24 / 5.74
U-turn wind + battery 10/10 18.53 ± 0.57 17.96 0.098 1.20 / 5.83
Lemniscate nominal 10/10 25.83 ± 0.44 25.36 0.108 1.25 / 3.72
Lemniscate shifted gates 10/10 26.14 ± 0.64 25.14 0.119 1.23 / 4.89
Lemniscate wind + battery 10/10 28.43 ± 1.08 27.49 0.115 1.19 / 4.67
10 seeds per row, 5 laps each, no solver failures. Gate offset: largest distance from the gate centre right after a gate is passed (the opening's half-width is 0.2 m). Worst-case solve times were measured with nine simulations in parallel; all are far below the 10 ms budget.

Learned controllers vs. the expert

Controller Parameters Provided tracks Random test tracks
nominal / shifted / +wind
Step time
MPCC (expert) — 90/90 124/144 (47 / 39 / 38) 3.5 ms
Ensemble 5 × 64×64 (ours) 67k 88/90 117/144 (47 / 36 / 34) 0.7 ms
Single 128×128, distilled from the ensemble 35k 85/90 111/144 (46 / 35 / 30) 0.6 ms
Single 64×64, DAgger 13k 74/90 101/144 (44 / 32 / 25) 0.6 ms
Single 64×64, behaviour cloning only 13k — 32 % (validation) 0.6 ms
Provided tracks: 3 tracks × 3 conditions × 10 seeds, 5 laps. Random tracks: 48 held-out tracks × 3 conditions, 3 laps, on seeds never used for any design decision. Step time is the median of the whole control step; the networks themselves take about 30 μs.
  • Same speed as the expert. On the nominal provided tracks the ensemble's 5-lap times are within 0.3 s of MPCC (circle 25.09 vs 25.21 s, U-turn 17.39 vs 17.08 s, lemniscate 26.36 vs 26.09 s), and up to 1 s slower in wind.
  • Generalization. The networks never saw the provided tracks, yet they finish 98 % of the races there and reach 94 % of MPCC's success on held-out random tracks.
  • Shared weak spot. The remaining failures of both controllers are mostly gates that are shifted and revealed late, where the mid-flight replan bends the path at speed.

Limitations & Next Steps

  • Sim-to-real. Radio and estimator delay are not modelled. Forward-predicting the initial state over the known delay before solving (or before querying the network) is the standard remedy, and delay and estimator noise should be added as randomizations before training.
  • Replanning latency. The spline planner runs inside the control step, so a gate reveal can cost 0.1–0.3 s once. On hardware it belongs in a background thread, with the drone flying the old path until the new one is ready.
  • Supervision. The ensemble still crashes in 2 of 90 races. A supervisor that hands control back to MPCC when the drone leaves the corridor, the same rule we used to collect data, would combine the network's speed with MPCC's recovery.
  • RL. Fine-tuning with PPO needs a far larger sample budget, such as GPU-vectorized simulation, or a lower-variance signal at the gates.

BibTeX

@misc{zheng2026crazydrone,
  title  = {Crazy Drone: Contouring MPC and a Distilled Neural Tracker for Crazyflie Racing},
  author = {Zheng, Hanbin and Wang, Shengrui and Wang, Siyuan and Li, Xiang},
  note   = {ECE 484 Final Project, University of Illinois Urbana-Champaign},
  year   = {2026},
  url    = {https://hanbinzheng.github.io/project/crazy_drone/}
}

References

  1. A. Romero, S. Sun, P. Foehn, D. Scaramuzza. Model Predictive Contouring Control for Time-Optimal Quadrotor Flight. IEEE Transactions on Robotics, 2022.
  2. R. Verschueren et al. acados: a modular open-source framework for fast embedded optimal control. Mathematical Programming Computation, 2022.
  3. S. Ross, G. Gordon, D. Bagnell. A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning. AISTATS, 2011.
  4. M. Laskey, J. Lee, R. Fox, A. Dragan, K. Goldberg. DART: Noise Injection for Robust Imitation Learning. CoRL, 2017.
  5. J. Schulman, F. Wolski, P. Dhariwal, A. Radford, O. Klimov. Proximal Policy Optimization Algorithms. arXiv:1707.06347, 2017.
  6. S. Levine. CS 285: Deep Reinforcement Learning. Lecture course, University of California, Berkeley. Lecture 2 (behaviour cloning, distribution shift, DAgger).
  7. ECE 484 Fall 2026 Quadrotor Project, University of Illinois Urbana-Champaign. Official team page: ZJUI Meta.