Ember

Architecture
Dashboard
Drone View

Inspiration

Forest fires move faster than infrastructure can keep up.

We kept coming back to the same gaps:

Satellites don't get all of the signals of a fire (thermal, carbon, etc)
A single team/camera cannot cover an entire forest on a frequent basis
Who and when gets notified when there is an incident, and how do you stop it

Ember is our attempt at all three. Drone swarms fly the forest on a schedule and look for fire, planning evacuation routes and identifying response deployment zones. Then an agent sends civilians a text telling them when and where to go.

What it does

Draw a watch zone on a desktop map. Ember suggests where to put edge servers so the drones stay in range, then shows coverage, live drone positions, and what each pass found: clear, at risk, or burning. From those detections, a fully autonomous operator agent detects and predicts: where the fire is likely to spread, where to combat it, and which routes civilians should take to escape it.

Challenges we ran into

Range. A single server can't reach drones spread across a forest. We split the system in two: edge servers handle the drones near them, and an edge manager handles the edge servers. Drones only ever talk to their own edge server, and every pair of services has exactly one channel between them.

Demoing without a forest. We had no fleet and no fire at the table. The 3D simulator can only show what the telemetry service reports, so the simulated drone had to send the same messages a real drone would. We mapped historical data to 3D models to build out a simulation of what the drone's cameras would be seeing.

Accomplishments that we're proud of

It works end to end. You can draw a zone, get edge server placement and coverage, turn drone detections into spread and evacuation maps, sign up with a phone number, and get a text about that zone.

We're also happy with how little the civilian side asks for: a phone number, a ZIP code, and replying to a text.

What we learned

Detecting a fire is only half of it. A detection doesn't help if the signal can't get out of the canyon, or if the warning goes to an app nobody installed.

We also learned to define the service boundaries before building features. Once each service had one job and one way to talk to the next, different people could build the drone sim, the signup page, and the text agent without breaking the map. Most of our worst bugs came from two parts of the system meaning different things by a "person": email vs. phone number, a contact row vs. a civilian, or a chat reply that made up a route vs. the planner's real one.

What's next for Ember

Improve goal-setting and path-planning algorithm with reinforcement-learning algorithms
Update drone work to use a real physics engine instead of kinematics only
Improve segmentation model by tuning model weights and finding more data