AIDEN — an autonomous wildfire-response fleet

The vision: a standing fleet, not a callout

Aerial firefighting today is a callout model. Something burns, someone notices, aircraft are dispatched from a base that might be a hundred kilometres away, and the fire gets however long it takes them to arrive. By then a quarter-acre spot fire can be a frontage no air tanker is going to stop. The XPRIZE Autonomous Wildfire Response challenge asks for the opposite: detect an incipient fire over a large wildland area and put it out autonomously, fast, day or night, without a pilot.

The Think Circuits concept — AIDEN, an AI-driven drone extinguisher network — is a standing fleet rather than a callout. Three layers:

Concept of operation: define a fire-exclusion zone on a map, a high-altitude observation drone detects an ignition, a suppression drone carrying suppressant reaches the early-stage fire, a small ground crew mops up. — Concept of operation from the XPRIZE submission: a defined fire-exclusion zone, persistent high-altitude detection, a suppression drone on the ignition while it's still small, a small crew to mop up. The map is an illustrative wildland–urban-interface zone, not a specific customer site.

Detection drones loiter high and wide, watching for the radiometric signature of a new fire — a persistent observation layer rather than a camera someone has to point. Suppression drones sit at distributed, solar-powered base stations spread across the protected area so that some drone is always within a short flight of any point — and carry a non-toxic suppressant payload. A central operations hub handles refuel, rearm, heavier maintenance, and human oversight. The economics of the whole thing turn on one number: the response-time bound. If you want a drone on any ignition within, say, nine minutes, the base-station spacing falls out of that — a hexagonal grid sized to the suppression drone's cruise speed — and so does the cost per protected square kilometre. That math is the difference between a science project and something an insurer or a utility would actually fund.

Block diagram of the detection drone: an AIDEN agent wired to satellite comm/GPS, terrestrial radio, an SDR radar package, avionics, and a zoom camera, behind a fixed-wing silhouette. — Detection-drone architecture (concept): a long-endurance, high-altitude platform — wide-area radar/optical sensing into an on-board agent, with mesh + satellite links.

Block diagram of the suppression drone: an AIDEN agent wired to satellite comm/GPS, terrestrial radio, a ground radar, avionics, fixed cameras, and a suppressant deployer, behind a quadcopter silhouette. — Suppression-drone architecture (concept): a heavy-lift VTOL carrying a suppressant payload, local sensing for terminal guidance, same agent + comms stack.

Fleet network topology: a detection drone, a satellite, a headquarters building, and suppression drones in hexagonal cells, connected by a terrestrial mesh network and satellite links. — Redundant fleet network: hexagonal base-station cells sized to the suppression drone's reach, a terrestrial mesh as the primary link, satellite as the fallback, and a headquarters in the loop. The hex spacing is what the response-time bound buys you.

The detection layer in the full proposal leans on a purpose-built long-range radiometric fire sensor — different radio signatures for flame, smoke, and background, readable from far enough away to matter. Those specifics are out of scope here; the parts of the system that actually exist — and that this post's demo recreates — are the optical detection pipeline and the fleet logic on top.

Vertical stack diagram of a suppression-drone charging station: charging contacts, solar panel and battery, GPS-RTK base station, satellite uplink, terrestrial radio, on a tower truss. — Base-station concept: solar power + battery, an RTK GPS reference, satellite uplink, mesh radio — and contacts to recharge and rearm a suppression drone between calls.

Detection scan pattern (concept): a single high-altitude drone steers its sensor footprint to tile a large area on a repeating loop — the persistent-observation idea, made concrete.

What's built

A concept submission is one thing; here's the system that actually exists.

A black hexacopter drone hovering low over burning brush at the foot of a wood retaining wall, partly shrouded in steam, a stream of water arcing down from its nozzle into the flames. — A suppression drone knocking down a brush fire — 2025 field test.

FlameCam — patent-pending wide-area fire detection. The detection payload is the piece of AIDEN under patent application. The goal is brutal: from a drone loitering high over a large area, pick out a new flame from kilometres away — on the order of ten kilometres — while it's still small enough to put out, day or night. The hard part isn't seeing something hot; it's not raising the alarm on everything that merely looks like fire — sun glint off metal, a hot roof, a reflection, a brake light. FlameCam's invention is how it earns confidence: it cross-checks the candidate across more than one co-registered view and only calls a detection when the signature holds up consistently, which is what kills the single-sensor false alarms that make naïve fire detectors useless in the field. It runs on a small embedded payload and streams its camera feeds and the live detection overlay over WebRTC, so an operator — or the dispatch brain — sees exactly what the drone sees. (US patent application pending; the rest stays under wraps while it is.)

The FlameCam detection sensor on a stand on a deck, aimed across the yard at a hand-held road flare burning in a galvanised tub of water. — Bench range test: the FlameCam sensor picking a real flame out at distance — a flare burning in a tub of water, deliberately set against the kind of glare and clutter that fools a single-sensor detector.

A targeted suppression payload. The suppression end is a stabilised gimbal carrying thermal and visible cameras and a pump-fed nozzle. It runs a small state machine — stored (safe, pointed away), armed (pointed down, motion-stabilised against the airframe, searching), firing (pump on, tracking the hot spot) — with a ballistics model that aims the stream given the drone's altitude and the gimbal pose. The point is that the drone doesn't just dump a load near a fire; it puts it on the fire.

Three-quarter view of a blue Think Circuits suppression hexacopter on a wood floor, showing the slung water reservoir, pump, wiring, and a downward-facing sensor turret under the body. — The suppression airframe: hexacopter, slung reservoir and pump, downward thermal/visible turret for terminal guidance.

A metal fire pan on a driveway with orange flames and a large white smoke plume drifting up the driveway — a controlled test fire. — The target: a controlled test burn — what the dispatch brain sends a drone at, and what FlameCam has to spot before it gets this big.

~12 s from a 2025 test: the suppression drone holding station low over the brush and laying a steady stream into it. (No audio.)

A wind-aware dispatch brain. When a fire is confirmed, which suppression drone goes? Not the one that's nearest in metres — the one that's nearest in time, and time depends on the wind. A drone heading upwind to a fire is slow; the same drone heading crosswind has to crab into it and loses ground speed too. So the dispatcher works in wind-adjusted travel time: it figures the real arrival time to every point given the current wind, carves the protected area into coverage cells — one per suppression drone, the drones spread out so the cells cover the area evenly — and sends the drone whose cell the fire falls in. Those cells are precomputed for each drone for a handful of wind presets, so the decision is instant.

A fleet-ops dashboard. Tying it together is a map view: every drone's position and heading, the detection camera footprints, the wind-adjusted coverage cells, the wind, ground-truth fires versus confirmed detections, and a per-asset status panel. Everything moves over MQTT — v1/agents/+/location, …/fov, …/flamecam/detections, v1/demo/wind, v1/demo/voronoi, v1/demo/fire_truth — with a scenario engine on the side that can script a whole incident (timed ignitions, wind shifts) and an "ignite here" button for live Q&A. Exactly that setup drives the team's refinery-protection walkthrough.

The fleet-ops dashboard, live

Embedded below is the actual dashboard — the same React + Mapbox app, the same map layers (coverage cells, wind field, camera footprints, fire markers, the fleet rail) — with one thing swapped out: instead of subscribing to a real MQTT broker, it runs an in-browser scenario player that publishes the exact same message stream the live drones and dispatch brain would (v1/agents/…/location, …/fov, …/flamecam/detections, v1/demo/wind, v1/demo/voronoi, v1/demo/fire, v1/demo/fire_truth). It loops the scripted refinery incident: a flare-stack anomaly, a wind shift, then a high-intensity tank-farm fire — detection drones break off to orbit, the dispatch brain picks the fastest responder by wind-adjusted travel time, and the coverage cells re-skew as the wind backs around. Hit Ignite (bottom-right) and click the map to stage your own fire.

Tight on screen space? Open the dashboard full-window →

How the demo works

What's real vs. stubbed. The dashboard, the Mapbox rendering, the map layers, the HUD, the click-to-ignite flow — all the original code. What's stubbed is the data source: the live system streams telemetry from the drones and the dispatch brain over MQTT; here a single TypeScript module replays an equivalent stream — drone motion, camera footprints, FlameCam detections, the coverage map, dispatch and clearance events — driven by a scripted timeline. The coverage cells use the same wind-adjusted travel-time estimate the dispatch brain uses, evaluated over the area and merged into the same staircased coverage polygons the real v1/demo/voronoi messages carry.

Why wind-adjusted coverage. A plain nearest-in-metres carve-up is wrong under wind: a fire that's closer to drone A but downwind of drone B should still go to B, because B gets there first. So the coloured cells are a coverage map drawn in travel time, not distance — each patch of ground belongs to whichever suppression drone reaches it soonest given the current wind. Watch them stretch and re-skew when the wind shifts from a Gulf sea breeze to a sustained southwesterly partway through the loop.

Why this is the interesting half

The cameras and the gimbal are good engineering, but the part that generalises is the layer in the middle: turning a stream of raw sensor data into a confirmed event, deciding who acts under a hard time bound, and coordinating a fleet over a flaky low-bandwidth link where each agent has to reason locally from a high-level objective. That's the same shape of problem whether the payload is a water cannon, a warehouse picker, or anything else you'd put a learned model on board. Wildfire just makes the deadline honest.

About the project. AIDEN is a Think Circuits team project. Kevin Weekly, who runs Think Circuits, leads the program — architecture, business case, the drones, the fleet-coordination and dispatch software, and the operations dashboard. FlameCam, the detection payload, is the team's main contribution: it started from an insight by the optical engineer; Kevin built a first prototype around it, the optical engineer and others built the next, and the team carries the signal processing, computer vision and detection results from there. The network-sizing analysis is a colleague's work. The team advanced to the finalist-announcement stage of the XPRIZE Autonomous Wildfire Response competition.

← Back to kevinweekly.com