Inspiration

In January 2025 the Eaton Fire tore through Altadena and Pasadena. Thousands of homes burned in a single night. Two problems stood out to us. Inside a burning house, firefighters search through smoke so thick they can't see their own hands. They move by touch and hope they hear someone call out. Once the fire passes, insurance adjusters have to visit every lot one at a time to work out what was lost, while families wait weeks for an answer.

The track asked how technology can find the people with the most urgent needs and make sure no one is overlooked. We decided to work at both scales: inside one house, guiding a firefighter to a victim they can't see, and across a whole neighborhood, giving responders and insurers a house-by-house picture from the air.

What it does

1. Haptic guidance bracelets (inside the house) A firefighter wears a bracelet on each wrist. A chest-mounted sensor pack watches the room. The bracelets buzz in patterns that point toward a likely victim and steer around obstacles, so the firefighter never needs to see.

  • mmWave radar detects people through smoke and thin interior walls. It also catches people who are lying still and only breathing, the victims who can't call for help.
  • Ultrasonic sensor catches close-range obstacles so we never buzz someone into a wall.
  • Phone is the hub. It hears distress sounds, tracks which way the firefighter is facing with its compass, runs the fusion algorithm, and sends buzz commands to the bracelets over Bluetooth.
  • Radar map app (native iOS) plots detections as blips around the firefighter. Red means still (possibly unconscious) and orange means moving.

2. Drone-Eye (across the neighborhood) A drone's camera feed flies over a burn zone. For every frame, Drone-Eye:

  • Works out which house it's looking at, matching the drone's GPS position, heading and camera angle against a parcel/policy database, and labels the frame with its street address.
  • Runs YOLO onboard to flag people, animals and visible flame as signs of life, and folds in radar hits from the field.
  • Sends the frame to a vision-language model that returns a structured, adjuster-style assessment: damage category, % loss, per-component damage (roof, walls, windows, structure, outbuildings), hazards and a written summary.
  • Turns that assessment into a first-pass loss estimate from the house's square footage and policy limits.
  • Shows everything on a live adjuster dashboard, with alerts for any house where signs of life were detected.

How we built it

Hardware: ESP32 boards (WEMOS LOLIN32 Lite) drive a vibration motor in each bracelet over PWM and advertise as BLE peripherals (Bracelet-L / Bracelet-R). Each write is two bytes: intensity and duration. A third ESP32 reads an HLK-LD2410B 24 GHz radar over UART at 256000 baud and forwards readings over BLE.

Sensor fusion: we split the space around the firefighter into 8 sectors of 45°. Each sensor votes on each sector, and the bracelets point at the winning sector:

$$S_k(t) = \lambda \, S_k(t-\Delta t) + 0.3\,M_k + 0.6\,R_k, \qquad S_k = 0 \text{ if an obstacle is within } 1\,\text{m}$$

\(M_k\) is the microphone's distress score and \(R_k\) is the radar's detection score. The decay term \(\lambda\) makes a cry from ten seconds ago fade unless the radar keeps confirming it. When both sensors agree we send a strong, fast buzz. When only one fires we send a soft one. When nothing does, the bracelets play a "keep sweeping" pattern.

iOS app: SwiftUI and CoreBluetooth. The LD2410B reports distance but not direction, so we take the bearing from the phone's compass. The firefighter turns slowly in place, and the app pins each reading on the map at that heading and range.

Drone-Eye: Python with OpenCV, Ultralytics YOLO11, and a FastAPI server with WebSockets. The camera input is pluggable: a webcam, an iPhone camera, a Raspberry Pi camera stream, or a video file. To simulate a drone, we point the camera at photos of burned homes. The damage assessment can use Claude or Gemini and is forced into a strict JSON schema. When there's no API key or no Wi-Fi, an offline color heuristic (char, ash and flame pixel ratios) keeps the demo running.

Challenges we ran into

  • Finding direction with a microphone is hard. A phone's mics are too close together to tell which way a sound came from, and fire noise drowns out everything. So we demoted the mic to a trigger ("someone is yelling") and let the radar own direction.
  • Our radar has no bearing. The LD2410B is excellent at sensing people who aren't moving, but it only reports distance. Pairing it with the phone's compass turned a one-number sensor into a map.
  • "Through walls" is mostly marketing. Cheap mmWave gets through drywall, wood and foam, but not brick or metal studs. We built the pitch around what it really does well: seeing through smoke and catching silent victims.
  • iPhones can't talk to hardware from a browser. There's no Web Serial or Web Bluetooth on iOS, so the radar map had to become a native app.
  • Hardware quirks: the radar needs 5V, which the LOLIN32 Lite doesn't supply. ESP32 Arduino core 2.x and 3.x also use different PWM APIs. On top of that, three laptops on two operating systems all had to run the same stack.
  • Picking the right house. Turning a drone's position and camera angle into a street address, so each assessment lands on the right policy, took more geometry than we expected.

Accomplishments that we're proud of

  • Bracelets that buzz in a direction sent wirelessly from a phone, built from parts we mostly already owned.
  • A radar that picks up a teammate hidden behind a board, even while they're only breathing.
  • A drone pipeline that goes from camera frame to address, to signs-of-life alert, to an adjuster-ready damage estimate in seconds.

What we learned

  • Sensor fusion beats any single sensor. A bad sensor is still useful when a good one can confirm it or overrule it.
  • Telling judges honestly what the hardware can't do made our design better, not weaker.
  • BLE, UART, compass math and Xcode signing, most of it learned during the hackathon.

What's next

  • Connect the two halves: when a bracelet finds a victim, the drone dashboard marks that house as occupied for incident command.
  • Replace the phone hub with a rugged unit mounted on the firefighter's harness, using the IMU and mic already built into the helmet.
  • Use real parcel and policy data, and run the vision model on the drone itself so it works without a connection.

Built With

Share this project:

Updates

Submission history