Skip to main content
Back to blog

Six weeks of DomeCommand: from a unified baseline to honest fusion

· 3 min read
Vivek Gudapuri
Vivek Gudapuri
Founder, DomeCommand

I write up the ideas here as posts, but I have not kept a plain record of what actually got built, and when. This is that record, from the unified baseline at the start of July through the middle of the month. It is all R&D in simulation, roughly a 70% proof of concept, human on the trigger. Nothing here has been fielded. The terse list is on the changelog page.

A single baseline (v1.0.0)​

The month started by collapsing several earlier attempts into one unified command-and-control platform: a Rust server and a sensor-simulator backend, cut as platform_v1. Before that there was a stretch of foundation work in May and June, initial scenarios, a first backend, a counter-UAS demo with signals ingestion, and geofences. Useful, but scattered. The baseline was the point where it became one system.

The interesting engineering question for a counter-drone system is not how it behaves on a good day. It is what happens when the network drops and half the picture goes with it. The v3 rewrite put a typed domain and a live decision loop underneath, then added a behavior-tree DSL for assets and threats with comms-degradation predicates. That is the machinery for a system engineered to survive lost links, modeled as policy guards in simulation. To be clear about the boundary: the coordinate loop here is simulated, not running on a real mesh.

Fusion around three questions (v1.2.0)​

I wrote a whole post on this, so I will keep it short. Sensor fusion got rebuilt around three separate questions: does this thing exist, what is it, and whose is it. Kinematics can never be allowed to make something hostile. What I am proud of is what came next: a fusion audit that fact-checked the design doc against the code and corrected two of its own conclusions. At that point the data model claimed more than the code delivered, and writing that down honestly is what set up the next release.

Fusion becomes honest math (v1.3.0)​

This is where the claims and the code met. A Kalman-filter estimator core, an interacting-multiple-model tracker for hover, cruise, and maneuver, a simulated thermal sensor cued by radar, and per-platform bias estimation. The planner also learned to ask before it acts: plans are authored, reviewed, and require operator approval before anything auto-executes. The review is a model in the loop with a human approving each step. It is not an autonomous authority, and I am not going to describe it as one.

Autonomy modes reach the console (v1.4.0)​

Most recently, autonomy modes and click-to-surveil tasking reached the operator console, with more simulated sensors, and multi-hypothesis tracking began with a k-best assignment engine. Phase A only. The harder phases are still spec, not code, and every sensor in this release is a simulated model, not hardware.

The honest gaps​

If you read one section, read this one. The effectors and sensors are simulated. The mesh coordinate loop is simulated. Multi-hypothesis tracking is at its first phase. The planner asks a human before it does anything. This is a proof of concept that is built to degrade gracefully and to be honest about where the stubs are. The full list, release by release, is on the changelog.