Project Firefly: autonomous drones for early detection of ember fires
Abstract
Ember fires, ignited by burning material carried ahead of a wildfire by wind and heat, are a significant cause of rapid wildfire spread. They are small, scattered over large areas and can become uncontrollable within minutes, so they must be found fast and located accurately. Project Firefly addresses this with a heterogeneous swarm of low-cost, loss-tolerant drones and a ground station. Once the operator has defined the search area, the drones work with no operator in the loop. A leader drone sweeps a wide area with a thermal camera, and a surveyor drone is dispatched to confirm each detection up close. All computation runs onboard, the drones share state through synchronised databases over direct drone-to-drone links, and confirmed fire positions are reported to the ground station.
Introduction
During a wildfire, embers can be carried by wind and heat over distances ranging from a few meters to several kilometers ahead of the main fire front, leading to many independent new ignitions across large areas at the same time. The detection window is short: spreading at 20–50 m/min, a centimetre-scale ignition can become an uncontrollable fire in minutes. The ignitions are also small and often hidden by vegetation and smoke, and thus hard to detect.
This sets three requirements for a detection system. It must cover a wide area, because ignitions can appear anywhere ahead of the front. It must detect them fast, because the window is only minutes long. And it must locate them accurately, so that responders can manage their resources on site and in real time. As soon as an ember fire ignites, we need to know about it and where it is.
The project was a response to Vinnova's Radical Innovation challenge "Utmaning drönarsvärm 2025", which asked for drone swarms collaborating with a high degree of autonomy to perform complex tasks in environments that are difficult to monitor or pose significant risks. Building on Qamcom's expertise in aerial perception and remote sensing, sensor fusion, and wildfire management and geolocation, we developed the drones, the onboard autonomy and the swarm coordination needed to meet these requirements.
System concept
Commercial drones and high-end sensors are generally too costly to be treated as consumables, as operations in close proximity to a fire front or ember fire would require. We therefore designed and built a highly loss-tolerant system, consisting of cheap units that are fast to deploy and replace, with good-enough sensors and edge algorithms optimised for one task: detect and transmit. The driving principle was that more eyes in the right places beat perfect vision in the wrong places.
The system is a heterogeneous swarm of a leader drone and one or more surveyor drones, plus a ground station (Fig. 1). The architecture scales to N surveyors; the project demonstrated it with one. The leader sweeps the search area, detects thermal hotspots and ranks the resulting fires, at present by heat and size. In the future, the ranking could also draw on additional sensors and on external services such as a fire spread simulator. The highest-ranked fire is assigned to a surveyor, which flies to it and confirms it up close. It then sends back the confirmed fire record (position, footprint and temperature), which the leader uses to reprioritise.
The ground station is the operator's interface, not part of the control loop: it sets the search area, shows the feed and receives confirmed fires, and the drones carry on if its link drops.
Three features define the system:
Fully onboard computation
Flight control, navigation, sensor processing and detection all run on the drones. Direct drone-to-drone communication, without relays, over links that are bandwidth-constrained and can be unreliable in terrain such as valleys.
Direct drone-to-drone communication
Without relays, over links that are bandwidth-constrained and can be unreliable in terrain such as valleys.
Autonomous swarm coordination
There is no central controller; each drone manages its own tasks, reprioritises when new tasks appear and keeps operating when communication is lost.
Hardware
For the reasons above, we built our own aircraft instead of relying on commercial platforms (Fig. 2). This also strengthened Qamcom's competence in drone systems. Leader and surveyor share the same hardware, and the target unit cost at scale is around 8 000 SEK.
Flight controller
A Mamba F722 MK4 stack (STM32 F7 with integrated IMU and barometer) runs the open-source iNav firmware. It runs the control loop in angle and GPS modes and drives the motors via integrated electronic speed controllers. It is cheap, well supported and has spare UARTs for peripherals.
Onboard computer
A Raspberry Pi CM4 on a carrier board reads the thermal sensor, commands the flight controller and talks to the other drones. The Pi camera connects over CSI with hardware-encoded video, and the platform enables OpenHD for long-range video downlink.
Thermal sensor
The thermal camera is an 80×62-pixel indoor unit costing roughly 1 000 SEK, adapted for use in the air. Working within its limits, instead of integrating a better sensor, keeps the swarm affordable.
Software
Design principles
Each drone runs about ten small single-purpose programs, supervised by systemd, which restarts any that get stuck. Instead of exchanging messages, the services share state through SQLite/Spatialite databases. Each drone writes to its local database, only the changes are transmitted between drones, and records are only appended, never overwritten, so a dropped packet or a crash never leaves a half-updated picture. Fast sensor data and slow mission state are kept in separate databases, and statuses are integer codes to keep LoRa packets small.
Algorithms
- Path planning: a lawnmower sweep covers the search area within the geofence and no-fly zones, with lines spaced so that the camera footprint leaves no gaps. A point-to-point planner flies to a confirmed fire, detouring only around no-fly zones.
- Hotspot detection: at this resolution a fire is only a few bright pixels, so detection relies on a heat threshold and a minimum blob size tuned to the sensor.
- Geo-localisation: the drone's position, altitude and camera angle project each hotspot to a GPS position, using geometry reused from Qamcom's AI platform. Frames with an uncertain pose are discarded, because a small tilt error shifts the mapped fire by metres.
- Hotspot clustering: detections that are close in time and place are merged into one fire with a single position, footprint and temperature. A fire is confirmed only once its cluster has stayed stable for a set period (Fig. 3).
- Prioritisation and inspection: fires are ranked by heat and size, and a drone is assigned to inspect each one up close.
- Mission optimiser and simulator: these check battery coverage and run whole missions in software.
Communication
Database synchronisation is hidden from the control algorithms, which simply watch the database for new tasks. The first implementation used cheap, long-range but slow 100 SEK LoRa modules, with the leader deciding who may broadcast (its only central role).
Development and demonstration
We developed the whole system over five months, including field tests and a final demonstration. In the field tests, the leader and surveyor roles were each verified against real fires outdoors before the full system was run together. The first measured geolocation accuracy, ±10 m at 50 m, became the baseline for tuning.
The final live demonstration took place at Vinnova's demo review in Västervik on 28 May 2026, with two drones in the air. Detection and geolocation worked live on the first attempt. The drones were launched by hand, and everything after launch was fully automatic.
Conclusions and further work
Ember fires demand wide coverage, fast detection and accurate location. The project showed that a swarm of low-cost, loss-tolerant drones can meet these needs. Cheap, replaceable units make wide coverage affordable. Fully onboard autonomy, with no operator in the loop, keeps detection fast. Geolocation, clustering and close-up confirmation by a surveyor turn a few hot pixels into one reliable fire position that responders can act on. The detect–locate–coordinate pipeline is not specific to fire.
Since the successful live demonstration of Project Firefly in May 2026, this work has evolved into Starling, Qamcom's own drone platform. Its one rule is that a database is a component's only interface. A mission, such as fire detection, is an app that reads what it needs and writes back what it found. Hardware is a config file, so a camera, radio or flight controller can be swapped without rebuilding the app, and full multi-drone missions run in simulation on the real code. Platform v1, the fire-detection app and end-to-end simulated missions are in place, flight runs on one CM4, and swarm radio links are next.
The next step for these links removes the leader's broadcast role with a leaderless MAC protocol (DESYNC/M-DWARF), in which nodes find their timeslots peer to peer, over a 5.8 GHz WiFi-based radio with CRDT-based SQLite synchronisation (cr-sqlite), so that every node stores and forwards data to nodes that lack it. Further directions include scaling to N surveyors with dynamic leader–surveyor assignment, gas, smoke, acoustic and multispectral sensing, external services such as a fire spread simulator, tiered deployment with commercial UAVs, and targets beyond fire, such as people, vehicles and infrastructure.
Download the white paper here.