Crazyflie Drone Swarm

The simulation test bench for a Yale drone swarm: one or several Crazyflies fly through obstacle worlds while avoidance methods from published papers are measured against each other.

Undergraduate Researcher, O'Hern Lab · sim-to-real · Sep 2026 to now

Scale: O'Hern Lab · Yale

Results

• 3 of 3 obstacle worlds cleared with no contact (A* and EGO)
• 0.81 s → 0 time drones overlapped in a 4-drone swap
• 8.1 cm hover error traced to one constant
• 15 s regression check across 9 flights

The problem

A drone swarm has to work on real hardware, where every crash costs parts and days. Before anything flies, the project needs one place to run any controller or planner in simulation, see exactly what happened, and compare methods on the same tests.

What I built

• A Crazyflie 2.1 Brushless test bench on Crazyflow (JAX + MuJoCo): waypoint and path flight, a controller slot, and a log of every 100 Hz control tick.
• Three obstacle-avoidance methods, each traced to its paper: A* on a grid, a potential field, and a simplified EGO-Planner, compared across three obstacle worlds.
• Multi-drone flight where drones share timed plans and plan in priority order (after EGO-Swarm), with formation, crossing, circle-swap and area-sweep missions.
• Sim Lab, a local web app that shows every test flight as a video beside a top-down map, flies any test again from the browser, and flags results made with older code or settings.
• Plug-in slots so other controllers and planners run through the same tests unchanged, and a 9-flight regression check that runs in about 15 seconds.

The hard part

The simulated drone hovered 8.1 cm off its target height, and tuning gains would have hidden the cause instead of fixing it. I traced it to a thrust constant in the firmware controller that over-drives the Brushless motors by 1.61x, then predicted the offset from that constant before measuring it: 8.1 cm predicted and 8.1 cm measured, and 1.45 cm against 1.5 cm on a second drone model. Fixing the cause matters because the same firmware runs on the real drones.

How it fits together

• Missions + worlds to Planner slot (goals)
• Planner slot to Controller slot (trajectory)
• Controller slot to Simulator (commands)
• Simulator to Flight logs (every tick)
• Flight logs to Sim Lab (replay)

Invariant: every planner and controller goes through the same slots and the same tests, so results compare like for like.

Decisions

• Every method is traced to a paper and labeled faithful, simplified or my own, so a result is trusted for exactly what it is.
• My avoidance methods are baselines, not the project's planner: the bench exists to measure planners fairly, so any planner plugs into the same slot and faces the same tests.
• Sim Lab marks a result out of date when the code or settings behind it change, so a new method is never compared against a stale run.

What's next

Training swarm policies with reinforcement learning in JAX, then the first flights on real Crazyflies: one drone, then a squad of four.

Tech: Python, JAX, MuJoCo, Crazyflie, Path planning.

By David Antwi (david.antwi@yale.edu). Markdown version: /work/drone-swarm.md. Full profile: /llms.txt.