Skip to main content

​
System Overview

ADOS is a three-tier system: a drone agent on the aircraft, a ground agent on a nearby SBC, and optional cloud services for remote access. Each tier is independent. You can fly with just the first two and no internet at all.

​
The three tiers

​
Deployment models

ADOS supports three deployment models depending on what you need.

​
Field mode (Tier 1 + Tier 2)

The drone and ground station communicate directly over WFB-ng radio. No internet. No cloud. Latency is 50-100 ms glass-to-glass. This is the default for field operations.

​
Cloud mode (Tier 1 + Tier 3)

The drone has its own 4G modem and pushes telemetry and video to the cloud. A remote operator uses Mission Control at command.altnautica.com to monitor or control. Latency is 200-500 ms. No ground station needed, but you lose the low-latency WFB-ng path.

​
Hybrid mode (Tier 1 + Tier 2 + Tier 3)

The ground station receives WFB-ng for local low-latency flight, and simultaneously bridges telemetry to the cloud for remote observers. This is the best-of-both-worlds setup for commercial operations.

​
Distributed Receive (multiple Tier 2 nodes)

When one ground station cannot see the whole flight area (terrain, obstructions, long corridor), two or three Ground Agents can be deployed together. They form a small private mesh over batman-adv on a second USB WiFi dongle. One node takes the receiver role and serves as the hub; every other node is a relay that forwards WFB-ng fragments it heard. The receiver runs WFB-ng’s native FEC combine across the merged stream and republishes the clean video on the same downstream pipeline a single-node setup uses. Read the Mesh & Distributed Receive overview for when to deploy mesh and how it works.

​
Protocol stack

Each connection between components uses a specific protocol:

​
Two repos, one system

The entire ADOS stack lives in two public repositories: Both are GPLv3. The agent runs on the drone and the ground station (same code, different profile). Mission Control runs in a browser and talks to both. The agent is Rust-first. The long-running and safety-critical services (MAVLink router, cloud relay, video pipeline, radio, supervisor, logging, the HTTP front) are native Rust binaries; Python stays for AI and vision, the plugin runtime, setup, HAL detection, and some ground-station hardware glue. See Agent Services for the full breakdown.

​
Key architectural decisions

Multi-process over single-process. The drone agent runs each service (MAVLink, video, cloud, health) as a separate systemd unit with its own cgroup resource limits. A crashed video encoder does not take down the MAVLink proxy. See Agent Services. Web over native. Mission Control is a browser app, not a desktop application. WebSerial for FC communication, WebRTC for video, Web Gamepad API for flight controls. Electron wraps it for desktop distribution with full Chromium capabilities. See State Management. WFB-ng over WiFi. The radio link uses WFB-ng (WiFi Broadcast next generation), which puts the radio in monitor mode and broadcasts FEC-encoded packets. This is not standard WiFi. There is no association, no handshake, no retransmission. The result is consistent low latency at ranges up to 50 km. See Video Stack. Profile over fork. The ground station is not a separate codebase. It is the same ADOS Drone Agent with a different profile selected at boot. This means one install script, one upgrade path, and one test matrix. See Agent Services.

​
Latency budget

End-to-end latency from camera sensor to browser pixel:

​
What is next