A cheap drone now forces a response that can cost a thousand times more. Send a hundred at once and the hard part is no longer the hardware. It is the decision: what to send, at what, and when, faster than a person can make it.
Good news to share. Inturai Ventures (CSE: URAI) has signed an exclusive letter of intent to acquire the technology behind DomeCommand, together with a perpetual, worldwide licence to Distri, the open-source agentic harness it runs on. It was announced on July 6, and it is a good home for this work.
In the first post I said DomeCommand is a bet on two things. This one is about the first: sensor fusion, and why I think the interesting version of it involves sensors that move.
Let me start with the honest version of the problem, because most descriptions skip it.
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 demo version of any drone system quietly assumes three things: that GPS works, that the radio link holds, and that the drone is smart enough to fly itself. A real fight grants you none of those. GPS gets jammed. The link drops. Half the airframes are cheap things with no brain on board.
So the interesting engineering question for DomeCommand isn't "how well does it work on a good day." It's "what happens on the bad day, and the worse one after that." This post is about how the system is built to degrade: to keep doing something useful as each assumption gets taken away.
Suppose you want to test how a defense holds up against a hundred drones arriving at once, from three directions, with a radar blackout halfway through.
You cannot go and film that. Real saturation attacks are rare, expensive to stage, and impossible to repeat on demand, and the whole point of testing is repetition. This is the quiet problem at the center of building anything like DomeCommand: the data you most need is the data you can never collect. So you generate it instead.
We are putting a lot of time into the simulation engine for exactly this reason. It is where the synthetic data gets exercised in full, across combinations we could never stage: fleet laydowns against threat patterns, run and re-run until the failure modes show themselves.
Long before any of the swarm work, there was a tiny quadcopter hovering over my desk, and me not quite believing it could hold itself in the air.
My first real flight-controller project was Udacity's Flying Car and Autonomous Flight Engineer Nanodegree. The course is four projects, and they are more or less the four things an autonomous aircraft has to do: fly a shape (backyard flyer), plan a route through a city (3D motion planning), control the vehicle along that route (build a controller), and work out where it is in the first place (estimation and sensor fusion). I wrote mine in Python and the code is still on GitHub. It is a basic implementation, which is exactly what makes it a good way to explain this.
Underneath, it comes down to two jobs. Know where you are. Decide what to do about it. Everything else is detail.
