Recommended infrastructure
One machine per site runs the server. A second box runs detection, close to the sensors that need it.
The server
One node per site, and the reference board is an Orange Pi 5 Pro. Specifications and sizing are on Deployment.
What matters for this page is what that node does and does not do. It runs fusion, planning and the decision loop, all of which are CPU work. It does not run vision, and that is the decision the rest of this page is about.
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
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 (recommended)
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
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 Pro has an NPU on the same SoC and can carry both jobs on one board at a small site; a Jetson-class module is the alternative. The choice is mostly about what your detector 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. |
Interceptor onboard compute
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.