What is sensor fusion? One drone, four sensors, one picture
If you spend any time around counter-drone systems you hear the phrase "sensor fusion" constantly, usually as if it settles the matter. You have radar, RF, cameras, acoustics. Fuse them. Done.
It is worth slowing down on what that word actually means, because the naive version of it is the source of most bad pictures. So here is sensor fusion explained the way I think about it, with a concrete example you can follow tick by tick.
The naive idea, and why it breaks
The comfortable mental model is addition. Each sensor gives you a piece, you sum the pieces, and the total is the truth.
The problem is that the pieces are not the same kind of thing. Radar gives you a position and a velocity but has no idea what the object is. A camera can tell you it is a DJI quadrotor, but only once it is pointed at it and close enough to resolve it. RF tells you something is transmitting. Acoustic hears rotors. Each one answers a different question, at a different range, with a different error.
Sum them naively and you get the classic failure: a screen full of confident tracks the instant anything appears, each with a threat label it has not earned. The system looks decisive and is quietly guessing.
A concrete walkthrough
Let me make it real. This is a scenario straight out of our simulator: one drone closing on a protected asset at 25 m/s from 400 m out, seen by four sensors that come online in the order they realistically would.
| Sensor | What it reports | Can it identify? |
|---|---|---|
| Radar | position + velocity | No, it abstains |
| Acoustic | position + velocity | No, it abstains |
| RF/DF | position + velocity | No, it abstains |
| EO camera | position + velocity | Yes, "uav_multirotor" |
Radar picks it up first. Acoustic corroborates. Then RF. And only at the end, once it is close, does the camera get a good enough look to say what it is. Here is what the fused picture does, tick by tick:
| tick | sensors reporting | existence | class | what the operator sees |
|---|---|---|---|---|
| t2 | radar | 20 | unknown | 🟡 Contact, position only, unidentified |
| t3 | radar, acoustic | 30 | unknown | 🟡 Contact, position only, unidentified |
| t4 | radar, acoustic, rf | 40 | unknown | 🟡 Contact, position only, unidentified |
| 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, no matter how many sensors see it. The identity resolves on that same track. It does not spawn a second one.
The one distinction that matters
Read those five rows again and the whole idea falls out of them.
Existence and identity are two different questions, answered by two different kinds of evidence.
By t4 the system is very confident something is really there. Three independent sensors, three different physics, all agree on a real, closing object 350 m from the asset. The existence score has climbed past the confirmation threshold. And yet the class is still "unknown," because not one of those three sensors can say what it is. Radar, acoustic, and RF all abstain on identity. They are honest about it.
This is the part the naive "just add them up" model gets wrong. More corroboration buys you more existence. It does not buy you identity. You can stack ten radars and still not know whether you are looking at a quadrotor or a large bird. Identity only arrives at t5, when a sensor that can actually see gets close enough to resolve it.
So a good fusion engine tracks these as separate channels:
- Existence, is it real? Earned by corroboration, scored, and allowed to say "not sure yet."
- Identity, what is it? Earned only by a sensor that carries identity, and left honestly "unknown" until then.
Keeping them apart is what lets the console show the true state at t4: confirmed, corroborated, closing, and we still do not know what it is. That is a real situation, it happens constantly, and pretending otherwise is exactly how you end up with a fabricated picture.
Where this points next
Sit with the t4 state for a second, because it is the interesting one. You have a confirmed object 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 is.
That is precisely the moment the system should say: go look at it. Send something with a camera to close the range and earn the identity. Which is only possible if your sensors can move, and that is the idea I dig into in dynamic sensor fusion.
What we are building
The picture above is not a mockup. It is generated from a test in our fusion engine that regenerates the numbers from the running code and fails if they drift, so the walkthrough cannot quietly disagree with what the system actually does. The existence channel and the cross-modality association that keeps one drone as one track are what we are building on right now.
From there we are building the identity belief that measures how unsure we are, the affiliation logic that decides friend from foe under strict rules, and the collection loop that turns a high-uncertainty contact into a tasked "go identify it" mission. Each piece is a post of its own as it comes together.
If a picture that is honest about what it does not yet know sounds more useful than one that is confidently wrong, that is the whole bet. Follow along.