What it runs on.
Board profiles are in the agent today and the detection path is covered by CI gates. A board that is not in this list still runs the agent through the generic fallback, just without the profile-specific display, camera and radio bindings.
COMPANION BOARDS
Twenty profiles in the agent
The tier is a RAM class the agent reports and Mission Control displays. The accelerator note is what the profile declares, which is deliberately conservative: a board only advertises an NPU once there is a runtime in tree that can actually drive it.
Two entries deserve a footnote. The RDK X3 and the BeagleY-AI both carry real accelerators that only their vendor toolchains can drive, so their profiles declare zero and the agent runs CPU inference instead of pretending. The Jetsons and the Orange Pi 5 have silicon the profiles have not characterised yet, so they read as no accelerator until they do.
TIERS
What a tier means
The agent classifies a board by RAM and publishes the result on its status surface, so Mission Control can grey out what a small board cannot do instead of failing at run time.
- Tier 1, under 512 MB
- no compute
- Tier 2, 512 MB to 2 GB
- basic compute
- Tier 3, 2 GB to 4 GB
- full agent
- Tier 4, over 4 GB
- swarm capable
Perception is tiered separately. A board with a usable NPU, or one whose profile declares CPU ONNX, runs detection locally. A board with neither runs odometry only, with no detection or tracking. Streaming frames to a paired compute node is scoped but not wired on the drone side yet, so today a board reads as local or none.
RADIO
Two chipsets for the long-range link
The video and telemetry link injects raw 802.11 frames, which only a handful of USB WiFi chipsets do reliably. The compat table is generated once and consumed by both the Python and the Rust adapter selectors, so the two can never disagree about what is supported.
- Channel width
- 20 MHz
- Driver install
- DKMS, or prebuilt module
- Mesh carrier
- any 802.11s or IBSS adapter
- Onboard management WiFi
- excluded from injection
Eight USB vendor and product id pairs map onto those two families, including the common TP-Link rebadges. One id ships on both AU and EU hardware, so the agent disambiguates from the bound kernel driver rather than the id alone. Channel width is pinned at 20 MHz because the vendored driver has no narrowband symbol and 40 MHz has open upstream defects. A mesh relay needs a second dongle, and that one is not restricted to Realtek.
Five board families get a prebuilt kernel module so the install does not compile on the drone: the Pi v8 and 2712 kernels, the Radxa A733 and RK356x kernels, and the Armbian RK35xx kernel. Every other board builds the module on device. A new board profile cannot merge until it declares which of the two it is.
FLIGHT CONTROLLERS
Four firmware families, detected not configured
Betaflight and iNav are identified from the USB descriptor when the agent opens the port. ArduPilot and PX4 are identified from the autopilot field of a live heartbeat, so a stale guess cannot survive a disconnect.
Mission Control mirrors the same decision when it talks to a board directly over USB with no agent in the path: it tries a MAVLink heartbeat first, then an MSP handshake, and picks the adapter from the answer. Descriptor-based MSP identification on the agent is Linux-only; on any other host the agent reports no variant and Mission Control does the handshake itself.
PAYLOADS
Cameras, gimbals and pods come from extensions
Payload hardware is not compiled into the agent. It arrives as a signed extension that declares the capabilities it needs, and the host grants them one at a time.
- SIYI optical pods
- A2 mini, A8 mini, ZR10, ZR30, ZT6, ZT30
- MAVLink gimbals
- gimbal-manager component 154
- Downward nav camera
- USB UVC or CSI, via V4L2
- Optional rangefinder
- TF-Luna, LIDAR-Lite, VL53L1X
The SIYI extension fails closed on a pod it cannot identify rather than guessing a protocol. The gimbal extension speaks the MAVLink gimbal-manager protocol and nothing else, so it works with any autopilot that forwards those messages and with no serial-only gimbal. The downward camera path is optical flow with a scale ladder, not visual-inertial odometry.
NEW BOARD
Bringing up something not on the list
Two paths. Force an existing profile at run time, or add a profile and let CI hold you to it.
$# Force a known profile on an unrecognised box:
echo "rpi4b" | sudo tee /etc/ados/board_override
sudo reboot
# What the agent thinks it is running on:
ados hardware showA real profile is a YAML file in the agent's board directory, validated against a strict schema at load. Three CI gates then apply: the profile must declare whether its radio driver is prebuilt or compiled on device, no two profiles may match the same device-tree string, and every profile must carry a valid display section. That is deliberately more friction than a config file, because a board profile is what decides which GPIO the agent is allowed to drive.