Skip to main content
ADOS has three tiers: the Drone Agent on the aircraft, a Ground Agent on a nearby single-board computer, and optional cloud services for remote access. Each tier works on its own. You can fly with the first two and no internet at all. The Drone Agent and the Ground Agent are the same software. The installer’s --profile choice (drone or ground_station) decides which services run. See Node profiles.

The three tiers

On the ground station the HDMI kiosk opens the on-box cockpit at /cockpit/ on port 8080. The front panel shows link and node status on the attached OLED or LCD.

Deployment models

Field mode (tiers 1 and 2)

The drone and ground station talk directly over the WFB-ng radio. No internet and no cloud. This is the default for field operations and the shortest path ADOS has. The measured latency figures, and what they cover, are on Video stack.

Cloud mode (tiers 1 and 3)

The drone has its own internet uplink (for example a 4G modem) and reaches the cloud directly. A remote operator opens Mission Control in a browser and gets raw MAVLink over MQTT and video over WebRTC. The carrier network and the broker add to the path, so this is the slowest of the three. There is no WFB-ng link in this model.

Hybrid mode (tiers 1, 2 and 3)

The ground station receives WFB-ng for local flight and, when it has an uplink, relays the drone’s MAVLink and video signaling on to the cloud for remote viewers. The ground station’s ados-cloud service carries that relay; there is no separate relay unit.

Distributed receive (several tier 2 nodes)

When one ground station cannot see the whole flight area, two or three Ground Agents can work together. They form a small private mesh over batman-adv on a second USB Wi-Fi adapter. One node takes the receiver role; every other node is a relay that forwards the WFB-ng fragments it heard. The receiver combines the merged stream with WFB-ng’s FEC and serves the video through the same downstream path a single node uses. See Mesh overview.

Protocol stack

The MQTT topics are listed on Cloud infrastructure.

Repositories

Directory layouts for each repository are on Project structure.

Key design decisions

Multi-process over single-process. Each agent function runs as its own systemd unit with its own cgroup limits. A crashed video encoder does not take down the MAVLink router. See Agent services. Rust for the long-running services. The supervisor, MAVLink router, HTTP front, cloud relay, video pipeline, radio and ground receiver are native Rust binaries. Python remains for the residual API, setup, HAL board detection and AI sidecars. Web first for the operator. Mission Control runs in a browser: WebSerial and WebSocket for the flight controller, WebRTC for video, the Gamepad API for sticks. An Electron build adds native UDP and TCP links on the desktop. See State management. WFB-ng for the air link. The radio runs in monitor mode and broadcasts FEC-encoded packets. There is no association, no handshake and no retransmission, so nothing waits on a lost packet. See Video stack. Profile over fork. The ground station is the same agent with a different profile. One installer, one upgrade path and one test matrix.

Next steps

Agent services

The supervisor, the IPC sockets and the HTTP front.

MAVLink protocol

How Mission Control parses and sends MAVLink and MSP.

Video stack

Camera to browser, hop by hop, with the measured latency.

Cloud infrastructure

Convex status, MQTT relay and WebRTC signaling.
Last modified on October 11, 2026