What is sensor fusion? One drone, four sensors, one picture
"Sensor fusion" usually gets said as though it closes the topic. You have radar, RF, cameras and acoustics, you fuse them, you get the truth.
The naive version of that idea is where most bad pictures come from. Here is the concrete version, traced tick by tick off our own test data.
Every sensor is blind somewhere
The reason fusion is not addition is that the inputs are not the same kind of thing.
| Sensor | Sees | Blind to |
|---|---|---|
| Radar | Range, bearing and speed, at distance | Small low-signature quadcopters; clutter near terrain |
| RF | Control and video links, often before the drone is visible | Autonomous drones that do not transmit |
| EO/IR | Visual and thermal confirmation, a close-up identity | Distance; weather, smoke, darkness |
| Acoustic | Rotors, at short range | Anything past a few hundred metres; wind |
Each answers a different question, at a different range, with a different error. Sum them and you get the classic failure: a screen full of confident tracks the moment anything appears, each carrying a threat label it has not earned. The system looks decisive and is guessing.
One drone, four sensors
A drone closes on a protected asset at 25 m/s from 400 m out. Four sensors come online in the order they realistically would: radar first, acoustic behind it, then RF, and the camera last, once the range is short enough to resolve anything.
Three of those four abstain on identity. They report where something is, not what it is, and they say so rather than guessing.
| tick | sensors reporting | existence | class | the operator sees |
|---|---|---|---|---|
| t2 | radar | 20 | unknown | Contact, position only |
| t3 | radar, acoustic | 30 | unknown | Contact, position only |
| t4 | radar, acoustic, rf | 40 | unknown | Contact, position only |
| t5 | + EO camera | 50 | uav_multirotor | Threat, identified |
| t6 | all four | 61 | uav_multirotor | Threat, identified |
One object stays one track the whole way through. The identity resolves on that same track rather than spawning a second one.
Corroboration buys existence, never identity
Row t4 is the one worth stopping on.
Three independent physics agree an object is real and closing, 346 m from something that matters. The existence score has climbed well past the confirmation threshold. And the class is still unknown, because not one of those three sensors carries identity.
That is the distinction the whole engine is built around:
- Existence. Is it real? Earned by corroboration across distinct modalities, scored, and allowed to say "not sure yet."
- Identity. What is it? Earned only from a sensor that can answer that question, and left honestly unknown until one does.
Stack ten radars and you still cannot tell a quadrotor from a large bird. More of the same evidence moves the first number and never the second.
Which is why a track is never marked hostile on its movement alone. It takes a camera that has actually seen a drone, and doctrine enforces that rather than trusting the maths.
Why class cannot be a hard gate
Getting that trace out of the code meant changing something that made cross-modality fusion structurally impossible.
Both trackers gated clustering on class equality. An honest radar reporting unknown could therefore never associate with an EO detection reporting uav_multirotor. One drone became two tracks, one per modality, and the radar plot could never be identified by the camera looking straight at it.
The rule now is that class is soft evidence and never a hard gate:
- Associate on kinematics. An abstaining sensor is compatible with any class.
- Conflicting concrete classes still refuse to merge. A bird is not a quadrotor.
- Abstentions cast no class vote, so a radar corroborates an EO class without diluting it back to unknown, and a track whose contributors all abstain stays honestly unknown.
What t4 is actually telling you
A confirmed object is bearing down on something you care about and no amount of more of the same sensing will identify it. Every fixed sensor that can see it already does.
That is the moment the system should stop reporting and go and earn the answer: send something with a camera to close the range. It only works if some of your sensors can move, which is the argument in dynamic sensor fusion.
The numbers above are not a mockup. They come out of a test that regenerates them from the running fusion engine and fails if they drift, so this page cannot quietly disagree with what the system does.