Inspiration

When a building collapses, the first hour is spent finding out what's inside. Today a rescue team usually sends one specialized indoor drone, flown by one pilot, room by room. That drone costs about $30,000 (a BRINC LEMUR 2 was listed at $29,999 in a county sheriff's equipment listing). Time is the one thing trapped people don't have, so we asked: what if we searched the whole building at once? Not one expensive drone, but a team of cheap ones that fly themselves, split the building between them and build one shared map. That's Mayfly. Send the swarm.

What it does

Mayfly sends several small drones into a building at once. Each takes a different part of the building and flies without a pilot. A central GPU computer merges what they all see into one live 3D map. The map marks people, blocked passages and hazards, and the crew gets a route in.

Published research backs the idea. Two ground robots mapping together cut indoor mapping time by about 50% (Xia et al., Sensors, 2024). Up to three aerial robots improved indoor exploration by 26.4% (Kim et al., IEEE RA-L, 2024). Those are the studies' numbers, not measurements of Mayfly.

Rescuers run everything from a browser console:

  • They plan a mission on the floor plan with a geofence, pick a search pattern (for example split by room) and launch every drone with one click.
  • They watch live drone feeds on the shared 3D map, with a coverage meter and each drone's path.
  • When the console finds a person, it shows a camera snapshot, a confidence score and estimated breathing and pulse.
  • They send a route to the crew channel.

Try the console at https://disaster-swarm.vercel.app/ (it runs on demo data unless it's pointed at a running simulator).

How we built it

The drones don't think. Each one is a cheap quadcopter with a camera and an IMU that streams to one GPU computer, an ASUS Ascent GX10, and flies where it's told.

  • The drone link. Our E58 toy quadcopter speaks the reverse-engineered wifi_cam protocol from the open-source Turbodrone projecton UDP 8090. An ESP32-S3 runningMicroPython joins the drone's Wi-Fi and runs its own access point on the same radio. It forwards video and RC and streams an MPU-65
  • gpucore (Rust + CUDA). A PyO3 extension whose CUDA kernels compile at startup with NVRTC. It renders every drone's camera by vopth into a TSDF map. Each frame isaligned to the map with Gauss-Newton, anchored to fixed landmark planes such as walls and roof. Dual contouring turns the map intos. A native A* planner runs theretoo. - Planning. Scouts take the frt. Once the building is found, aperimeter team flies the outside while the rest go in through openings confirmed for 5 seconds. Some drones hold back as a relay bo connected.- Detection. A YOLO26m model (Ultralytics) with four classes: person, door, fire, smoke. It runs as an FP16 GPU service for th and on the live E58 stream.- Live state. One SpacetimeDB module holds the whole mission: drones, survivors, the map, events, 15 fps camera feeds and cobes to it. Only the simulator canwrite state; viewers can only submit commands. - The console. TanStack Start,three.js point-cloud viewer.- Vitals. We benchmarked the Presage SmartSpectra SDK on clips we built from real photos with an injected pulse and breathing. ## Challenges we ran into - Lost video frames. The protoout 7 chunks with no retransmit, so5% packet loss costs about 30% of frames. Our first ESP32-S3 relay kept 19.2% of frames intact. A receive thread got it to 86.1% andout 24.6 fps) on a direct link.
  • IMU drift. Our first IMU path tracker kept snapping back to the origin. The new one fades drift out slowly: on a 7-minute resnapped back once, against 33 times before.
  • Vitals from drone video. Whep, it returned the injected heart rate within 0.5 bpm after about 12 s. On our degraded "drone-quality" clips (shake, noise, low JPEG quality) it returned `ChestNotVisi

Accomplishments that we're prou

  • A real drone streaming live: therough our relay and show up in theconsole as a "REAL E58" tile next to the simulation.
  • A full swarm (we've run 32 drone simulation on a single GX10.
  • Being clear about what's real. Here's where things stand:
    • Real: E58 video and IMU thction, the SmartSpectra benchmark.
    • Built, not flown: the flight controller (49 tests) has only been tested with the props off. Flight commands deliberately don'tause it has no login yet.
    • Simulated: the multi-drone swarm, the shared map and the planner. Vitals in the live console come from a stand-in that ed.

What we learned

  • Coverage per minute matters moreone airframe is, and coverage grows with the number of drones in the air.
  • Things don't always look the same in reality as the sim. An example is packet loss between real world relays making it way more important to build error into the simulation and redundancy into the system itself

What's next for Mayfly

  • Real swarm flight tests: fly the E58 through the relay, then several at once.
  • A Raspberry Pi relay (scripts wrhe S3 and fix its frame loss.
  • Live vitals from drone-quality video, by finding which degradation breaks SmartSpectra.
  • Ground robots like Boston Dynami for rubble drones can't flythrough.

The market is growing. Grand View Research puts drone-as-first-responder at $3.5B in 2026 and $11B by 2033 (17.7% a year), and drones. Our buyers are urban search andrescue teams, fire departments and sheriffs, who already buy single indoor drones.

Built with

Rust, CUDA (NVRTC, cudarc), PyO3, Python, PyTorch, Ultralytics YOLO26, ROS 2, SpacetimeDB, TanStack Start, React, Tailwind CSS, three. ESP32-S3, MPU-6500, PresageSmartSpectra, ASUS Ascent GX10, Remotion

Built With

Share this project:

Updates

Submission history