DroneWatch AI, a multi-sensor drone detection demonstrator
What is DroneWatch AI?
DroneWatch AI is a software intelligence layer that fuses several weak, noisy signals into one explainable picture of drone activity around a protected site. It was built by Marius Andronie at Devaland. It is a concept demonstrator, not an operational system: the drone-threat signals are simulated, and the air-traffic registry is a live, real public ADS-B feed. It does not detect real drones, and no field-validated performance is claimed. It was built to prove the approach and to start conversations with defence partners. Read the full write-up at devaland.com/blog/dronewatch-ai-multi-sensor-drone-detection
Why does it matter for someone hiring Devaland for an AI or Python build?
It is public, inspectable proof of the harder half of AI engineering: real-time data pipelines, multi-source fusion, deterministic rules working alongside an LLM, false-positive suppression, and a live operational dashboard, all running on infrastructure Marius owns and monitors himself. If your problem involves streaming or multi-source data, anomaly detection, or an AI answer that has to be trusted and explained rather than merely generated, this is the same engineering.
What problem does it solve?
Commercial drones threaten airports, critical infrastructure, public events and borders. The usual answer is specialised counter-drone hardware, which is expensive, so coverage stays sparse. A single sensor is also noisy: radio-frequency alone, acoustics alone, or radar alone each throw false alarms, and operators get flooded with unfused, unexplained detections they cannot act on. The premise of DroneWatch is that the value is not another sensor, it is the software layer that makes the sensors you already have smarter.
Which signals does it fuse?
Five sources, into one picture per zone: radio-frequency (the drone's control and video link), acoustic (the rotor signature), telemetry (position and Remote-ID style data), registry and ADS-B (which flights are authorised, and this feed is live and real), and human reports (what a person on the ground sees).
How does it avoid false alarms?
False-alarm suppression is the central design choice. A single sensor blip never raises an alert. A registered, authorised flight, even a loud one, stays quiet. A HIGH assessment requires at least two independent sensors to agree plus a contact with no matching authorised flight. An alert that is wrong most of the time gets ignored, and in this domain that is the failure that matters.
What is the technical stack?
Python and FastAPI, containerised with Docker, behind Traefik with automatic TLS, on a VPS Marius owns and monitors. The detection path is a two-tier engine: deterministic correlation rules first, then an AI layer that explains in plain operator language why a given threat level is justified by the signals present. The AI layer is gated to escalations only and cached, so inference cost stays negligible. The operator console is server-rendered and polled with htmx, with a self-contained SVG radar scope and a tactical map (Leaflet) plotting live real aircraft from a public ADS-B feed around a chosen protected site. Alerts fire once per escalation to a dedicated channel, with no repeat flapping. Idle stays quiet.
What engineering patterns does it demonstrate?
Real-time ingestion from multiple heterogeneous sources, normalisation into a single fused event stream, scoring and correlation across sources, hybrid deterministic-plus-LLM decisioning (rules decide, the model explains), alert de-duplication and hysteresis so operators are not spammed, a live polled dashboard, containerised deployment with automatic TLS, health checks, an uptime watchdog, and automated off-box backups. These are the same patterns behind Devaland's other production systems.
How does it integrate with real systems?
The design ingests real sensors and pushes a scored track into an existing command system through recognised standards: Remote ID (ASTM F3411) and ADS-B for identification, ASTERIX and U-space / UTM for air and drone traffic, and STANAG 4586 / 4609 and Link 16 for military command and control. It stays strictly defensive: detection and early warning only, with any response left to a separate, authorised, human-in-the-loop system.
What is its origin and status?
It was entered in the EUDIS Defence Hackathon Spring 2026 in Romania, and has since been built into a working demonstrator. Marius's background is as an Army Engineer (Military Technical Academy, Bucharest), so he understands both the operational world and the software. The honest next step is a pilot at one real site with one or two real sensor types plus the live feeds, to measure the real-world false-alarm rate, the number that actually matters.
Can I see the live demonstrator?
The console is access-controlled rather than open to the public. The public overview is at dronewatchai.eu and the full technical write-up is at devaland.com/blog/dronewatch-ai-multi-sensor-drone-detection. If you are a counter-UAS or sensor company, a systems integrator, or working on European defence innovation, Marius is open to a conversation, contact through devaland.com/contact.
Can Devaland build something like this for me?
Yes, that is the AI and Python build service. The path is a paid proof pilot on your real data, one clear deliverable, about one to two weeks, credited toward the full build if it works. Start with the async intake at devaland.com/contact?service=ai-build. There are no sales calls. Note that DroneWatch itself is a demonstrator and Devaland does not sell an operational counter-drone product.
