Deploy & integrate · Infrastructure

What to run it on

One machine per site runs the server. A second box runs detection, close to the sensors that need it.

The server

DomeCommand is one process plus a database. It runs on a single machine, and for a single defended site that is the deployment rather than a starting point.

	Minimum	Comfortable
CPU	4 cores	8 cores
RAM	8 GB	16 GB
Disk	50 GB	250 GB SSD, more if you keep long run history
GPU	None	None. The server does not need one.

The server does fusion, planning and the decision loop. All three are CPU work and none of them want a GPU. What wants a GPU is vision, and vision belongs somewhere else.

Run it at the edge, on site. The loop has to keep turning when the link to the wider network is poor, and the time-critical work is fusing the picture and re-solving the engagement. Both happen locally.

For a fixed installation we deploy on an Orange Pi 5 Plus with an NVMe drive. It is enough for the server, it draws little, and it survives a cabinet.

Where sensor detection runs

A sensing modality has an algorithm and a place to run it. For a camera the answer is forced; for anything that produces a raw stream it is a real choice, and the same hardware supports three answers.

   sensor node          companion computer            DomeCommand
   ───────────          ──────────────────            ───────────
A  detect ───────────────────────────────────────────▶ observation
B  raw ─────────────▶   detect ──────────────────────▶ observation
C  raw ──────────────────────────────────────────────▶ detect, then observation

A: detection on the sensor. Do not.

Attractive, because one box and a small wire. Wrong for a reason that has nothing to do with whether the chip is fast enough.

The model changes and the sensor does not. Detection models are calibrated per site and do not transfer well between them, so the model is retrained when the site changes. A model living on a rooftop node is a model behind a firmware update, and a firmware update has to be built, staged, rolled back and audited before anyone will retrain anything.

The second reason: a detection thrown at the server discards the window it came from. The first time someone asks why it fired at 03:12 there is no answer and no way to test a better model against the event.

B: detection on a companion. The default.

The sensor streams to a small computer on the same site. That computer runs the detector and publishes observations to DomeCommand.

Retraining	Log into the companion. No firmware release.
Bandwidth to the server	One observation per window. Small.
Bandwidth on site	Raw stream over the LAN, where it costs nothing.
Survives a server outage	Yes. It keeps sensing and buffers.
Cost	A second box per site.

One companion carries every modality on the site, so the second box is per site, not per sensor. That changes the economics considerably once a site has acoustic and RF and cameras.

C: detection on the server. For a bench or one site.

The sensor streams to the server and detection happens there. Retraining is a deployment and every site benefits at once. Everything is kept, so a new model can be evaluated against what actually happened.

The cost is bandwidth, and it is what rules this out at scale. It also means a sensor is blind while the link is down.

Use C while you are still choosing a model, because it is the only arrangement where you can run a new model over recorded history. Move to B for a real deployment.

The companion

For B, a small ARM board with an accelerator. An Orange Pi 5 Plus or a Jetson-class module both work; the choice is about what your vendor supports.

Workload	What to run
Vision detection	A small YOLO-class detector, exported for the accelerator. The small model is the right one: the larger variants lose most of their throughput for accuracy you cannot use at these ranges.
Acoustic and RF	The detector for that modality, with capture and detection kept separate so the detector is testable offline.
Local reasoning	A small open-weight model, if you want narrative assessment to survive a contested uplink.

The interceptor side

If you are flying interceptors, the on-device loop runs as a companion process beside a stock autopilot, over MAVLink. Nothing here requires modifying autopilot firmware, and you should not.

Two things that are not optional on that link: MAVLink 2 message signing, and a network that does not let arbitrary hosts reach the autopilot.

What a site needs beyond compute

• Power, with enough headroom for the sensors, not just the server.
• A LAN the sensors and the companion share. Raw streams stay on it.
• An uplink, which the design assumes will be poor. Nothing time-critical crosses it.
• Time sync. Fusion associates by time, so hosts that disagree about the clock produce tracks that disagree about position.

Where to go next

• Ingesting data for pushing observations from a companion.
• Platform & deployment for tenancy and access control.
• Integrations for what a sensor can speak.