Home

NumidAI — Early wildfire detection by AI

— Wildfire detection · Edge AI · Real Time

Early wildfire detection.
Embedded. Verified on-device.
No cloud inference.

NVIDIA Jetson Orin NX · C++ / DeepStream · staged on-device verification chain

NumidAI turns a single edge device and any standard camera stream into an autonomous wildfire detection system. It is built around one operational truth: the difference between a contained ignition and a disaster is decided in the first minutes — and a system that cries wolf gets ignored.

The first stage is deliberately tuned for sensitivity, so weak nascent plumes are never missed. Precision is then built downstream: every candidate is tracked and characterised over time, and ambiguous ones go through an on-device semantic verification stage before any alert is emitted. The sensitivity/precision trade-off itself is moved, not just the threshold.

Video never leaves the site. Only alerts, their visual proof and telemetry go out.

Small plume-like signal tracked over four successive instants
A small plume-like signal, tracked over four successive instants (enlarged detail of the temporal mosaic).

100 %

fire events detected — FIgLib test split, strict out-of-distribution

3 min

median time-to-detect — operations profile + partial L3*

0.06 %

false alarms among emitted alerts — fewer than on per day, per stream

24 W

one module, four streams — 100 % on-device processing

* FIgLib’s one-frame-per-minute format only allows part of the L3 stage used on a continuous stream to run. Full protocol and result tables available on request.


Demo

Two real-world cases: prescribed burn detection · industrial plume rejection


Verification chain

Every signal retained by L1 becomes a tracked event. Its descriptors — spatio-temporal dynamics, visual signature — are computed from the first detection and updated for its whole lifetime. Only candidates that need disambiguation are sent to semantic verification. What makes the architecture sustainable is that volume collapses at every stage.

Verification chain: video stream → L1 detection → tracking and descriptors → L3 semantic on demand → decision and registry
The most expensive analysis only ever sees a subset of candidates. Volumes are qualitative — orders of magnitude, not a tuning.

L1 — Real-time detection

Full-frame scan · Weak-signal sensitivity

Scans the entire frame continuously and reacts to the faintest plume-like signals — a few pixels on the horizon line. Tuned for sensitivity; a few milliseconds per frame.

Tracking & signal descriptors

Every candidate, followed for its whole lifetime

Each candidate is tracked from first sighting to expiry. Its spatio-temporal dynamics and visual signature are characterised continuously — flickering artifacts are discarded at no cost, stable signals frame what the rest of the chain has to judge. No per-site training or configuration.

L3 — Semantic verification, on demand

On-device disambiguation · Off the real-time path

Only candidates that require disambiguation are examined, judged on their temporal mosaic — real fire smoke vs low cloud, valley haze, chimney, glare, dust. Runs fully on-device, outside the real-time critical path. Its verdict is crossed with the current descriptor state to reach the decision.

Decision, registry & zone memory

One gatekeeper for alerts · A memory of the scene

A single decision stage emits, holds or closes each event, with anti-burst policy and visual proof attached. After several concordant rejections at the same location, a temporary zone memory activates and stops spending the most expensive stage there. Nothing is suppressed for good: zones auto-expire, and any significant evolution of the signal — growth, intensity, plume-like signature — triggers a fresh verification. The operator can also qualify rejections (glare, road, low cloud, dust) from the web UI, enriching the site memory with no retraining and no integrator.


Benchmark — FIgLib

Camera-based smoke detection has no common evaluation bench: published numbers each live on their own data and definitions. We chose to evaluate on the public academic reference for this use case — FIgLib (HPWREN, Southern California): 314 real fire-ignition sequences filmed from lookout towers, with a published state of the art to compare against (SmokeyNet, Remote Sensing, 2022).

FIgLib was never used to train NumidAI. Evaluation runs on SmokeyNet’s published test split, frame-by-frame like them, in strict out-of-distribution: fires, sites and conditions the system has never seen.

System (frame-by-frame) Precision Recall F1 Mean TTD
ResNet34 1-frame (published baseline)81.6 %76.6 %78.9 %2.81 min
SmokeyNet 2-frame89.8 %76.5 %82.6 %3.12 min
SmokeyNet 3-frame (best published)90.9 %76.1 %82.8 %2.94 min
NumidAI L1, strict OOD90.9 %77.6 %83.7 %2.18 min
SmokeyNet: figures as published by the authors on their test split. NumidAI: L1 stage alone, same frame-by-frame counting, same decision threshold.

What frame-by-frame doesn’t tell you

An alert system is judged per fire detected, per delay, and per false-alarm load imposed on the crews. NumidAI natively operates in a temporal regime: it exploits the persistence of signals, so isolated, unstable detections never qualify as alerts. FIgLib, sampled at one frame per minute, sits far below that regime — so we adopt a measurement convention to bring the bench closer to it: an alert is declared after two consecutive detections, one minute of persistence, the benchmark’s own step. On a real stream this persistence is observed in seconds; the convention is an approximation, more constraining than real operation. Measured per event on the same split, strict OOD:

Profile — 2 consecutive detections Fires detected < 5 min Median TTD FP (%) FP/h
Sensitivity profile100 %87.8 %2.0 min5.7 %2.82
Operations profile + partial L3*100 %75.6 %3.0 min0.10 %0.038
Per fire event, strict OOD. FP (%): share of emitted alerts that are false. FP/h: false alarms per fire-free hour, per stream — different denominators, not derivable from each other. * FIgLib’s one-frame-per-minute format only allows part of the continuous-stream L3 to run.

FIgLib is a true-positive-oriented bench, centred on known ignitions: it under-represents the diversity and frequency of field false positives (morning haze, low cloud, grazing light, dust, night lighting). That’s precisely where the full verification chain earns its keep — and what a field pilot has to measure.


Operator interface

The module serves its own web UI — nothing to install, reachable locally or over the network. Every journal event links to the temporal mosaic the verification was judged on: the verdict and what produced it, read together. Structured telemetry (MQTT, WebSocket, HTTP API) plugs into an existing supervision; since the decision is made on board, the uplink carries events, not video, and stays usable on a poor or intermittent link.

NumidAI dashboard: live stream, verification in progress, session summary
Dashboard — a no-alert session: 38 min on a hard site in grazing light, 11 signals examined and rejected (detailed in the false-positives block below). Click any screenshot to open it full size.

A confirmed ignition — journal and its evidence

Session journal: successive confirmations on a real ignition
Session journal — successive confirmations on a real ignition, with score, signal size and verification latency. · click to expand
Temporal mosaic of the same confirmed fire event
The temporal mosaic of one of these events — the evidence the verdicts link back to. · click to expand

Same mechanism, another site

Session journal: successive confirmations on another site and another plume type
Session journal — successive confirmations on another site and another plume type. · click to expand
The corresponding temporal mosaic
The corresponding temporal mosaic. · click to expand

False positives — hard site, grazing light

Back to the no-alert session of the dashboard above: everything the verification examines is rejected and no alert goes out. In its journal below, after several concordant rejections at the same spot, the temporary zone memory activates — “held” is not a hesitation, it’s an economy: the system has already ruled on that zone and stops spending the most expensive stage there. Any significant evolution of the signal triggers a fresh verification.

Rejections, automatic holds by zone memory, and operator confuser qualification menu
Rejections, automatic holds by zone memory, and the operator’s confuser qualification menu (glare, road, low cloud, dust). · click to expand
Fullscreen view of a held event on a few-pixel signal
Fullscreen view of a held event from the same session, on a signal a few pixels wide. · click to expand

Screenshots of the NumidAI web UI displaying streams decoded on the module, live or replayed. Streams used: HPWREN (University of California San Diego) and explore.org (Institute for Wildlife Studies).


Stack

Hardware & I/O

  • NVIDIA Jetson Orin NX 16 GB · ≈24 W
  • RTSP H.264/H.265 · USB · CSI — 720p min, 4K recommended at long range
  • Fixed and step-rotating cameras (scene recognition)
  • 4 simultaneous streams per module
  • Alerts out via MQTT · WebSocket · HTTP(S) API

Software

  • C++20 · NVIDIA DeepStream 7.x · TensorRT
  • Detector trained on a ~300k-image proprietary corpus (day/night, seasons, terrains, confusers)
  • Embedded semantic verification model
  • Lock-free async architecture · web UI served on-board
  • No cloud compute — video never leaves the site

Status & known limits

Working prototype on target hardware, exercised on continuous or replayed public streams and benchmarked on FIgLib. Next critical step: a long-duration validation on operational streams, in the field — the production false-alarm rate and early recall (fires caught in their first minutes) are the metrics that matter to end users.

An alert system is chosen on its failure cases as much as on its averages. Known limits, stated upfront: night performance is not yet sufficiently characterised (thermal / NIR is the identified path); continuously panning cameras are not handled (step-rotating ones are, via scene recognition); the full L3 chain in continuous-time regime is still under validation.

Looking for a field pilot: one monitored massif, one season, real streams. Benchmark protocol and detailed result tables available on request.


Contact

For field validation partnerships, technical collaboration, or any inquiry — see the About page →