Under active development. Breaking changes expected. APIs, installers, and UI may shift between releases.
Ground station for any drone.
A small Linux box receives long-range WFB-ng video and telemetry from the drone and serves it to any laptop, phone, HDMI monitor, or cloud observer. Deploy a second node and they self-organize into a mesh that combines fragments and heals around drops.
The Other Half of the Radio Pair
The ground side of ADOS.
The Drone Agent flies. The Ground Agent receives. Same codebase, different profile, picked at boot by hardware fingerprint.
A ground station is more than a video receiver. It is the bridge between a flying drone on a closed RF link and the people who need to see, control, archive, or relay what it sees. Pilots in the field want a screen and a stick, not a laptop. Engineers at the bench want a USB cable and a browser tab. Fleet operators want telemetry in the cloud. The Ground Agent does all of that from one Linux box, with one binary, and one update path.
The hardware is small. A Raspberry Pi 4B at the bench, a Radxa CM3 in the Lite production tier, a CM4 with diversity receive in the Pro tier. The radio card is the same RTL8812EU chip the drone uses on the air side. WFB-ng handles the long link. MediaMTX serves WebRTC to browsers. systemd holds the services together. The same install script that turns a fresh SBC into a flying drone turns a fresh SBC into a ground station, because the fingerprint check at boot picks the right profile.
- ▶Four ways to connect: HDMI kiosk, WiFi AP, USB-C tether, Android.
- ▶Five uplinks with priority failover and 4G data-cap throttle.
- ▶Distributed receive on two or three nodes, self-healing mesh.
- ▶OLED and four buttons on every node. Field tap-to-pair, no laptop.
- ▶Three hardware tiers, one binary, hardware fingerprint at boot.
- ▶One install command, captive portal first boot, GCS Hardware tab for day two.
Clients
Four ways to connect.
Every node serves all four at once. Pilot-in-command arbitration decides who has the sticks.
HDMI Kiosk
Monitor and a gamepad. No laptop.
<70 ms glass to glass
- ✓Chromium kiosk on the ground node renders /hud directly.
- ✓USB or Bluetooth gamepad becomes the pilot input.
- ✓Field-native. Power on, plug HDMI, fly.
WiFi AP
Any laptop or phone, any browser.
<100 ms over WiFi
- ✓Node broadcasts ADOS-GS-XXXX with a printed passphrase.
- ✓Mission Control opens in the browser at the local IP.
- ✓Multiple observers can join the same access point.
USB-C Tether
Hardwired link for Mac and Windows.
<70 ms tethered
- ✓CDC-NCM on macOS and modern Linux. RNDIS fallback on Windows.
- ✓No drivers, no chipset matrix. OS sees a USB Ethernet adapter.
- ✓Lowest-friction path for a bench engineer.
Android
Native ADOS app. Mode A.
<80 ms over WiFi
- ✓Phone joins the WiFi AP or tethers over USB-C.
- ✓Captive portal opens on first connect for pairing.
- ✓Same telemetry surface as the browser GCS.
Distributed Receive
One drone. Multiple ground nodes. One stream.
One node covers a clean line of sight. Two nodes cover a ridge. Three nodes cover a corridor. The mesh handles the rest.
Plant a relay node on a ridge or behind an obstruction. It picks up the drone on its own RTL8812EU and forwards raw fragments to the receiver hub over a self-healing batman-adv mesh. The receiver runs WFB-ng FEC on the combined stream and serves a clean video feed to every client. Pull the relay off power mid-flight and the mesh routes around the drop within seconds. No operator action.
Single Codebase
Same binary as the drone.
Air-side and ground-side are profiles of the same agent. One install script, one version number, one release cadence.
- ✓Hardware fingerprint at boot picks the air or ground profile.
- ✓Same install.sh on every SBC. No separate installer to maintain.
- ✓Same OTA update path for the drone and the ground station.
- ✓Same Convex cloud relay, same MQTT topics, same pairing protocol.
- ✓Same REST surface, same WebSocket telemetry, same log format.
- ✓Bug fixed once, both halves get it on the next release.
Hardware Tiers
Three flavors. One agent.
Start at the bench with a Pi 4B. Move to the Lite SBC for production. Pick the Pro tier when you need diversity receive.
Bench
Raspberry Pi 4B 4GB
Engineers, contributors, first build.
1x RTL8812EU, OLED, buttons, optional 4G.
Lite
Radxa CM3 (RK3566, 2GB)
Field pilots and single-site operators.
1x RTL8812EU, OLED, buttons, HDMI out.
Pro
Radxa CM4 (RK3588S2, 4GB)
Long-range work, distributed receive hubs.
2x RTL8812EU diversity, internal 4G slot.
The Ground Agent ships in the same GPLv3 repository as the Drone Agent. Documentation is CC-BY-SA 4.0. Reference hardware designs are CERN-OHL-S. Self-host the cloud relay or use the Altnautica relay. No proprietary lock-in.
Where It Fits
The path from drone to operator.
Ship Status
What is shipped, what is on the bench.
Feature-complete across radio pair, physical UI, standalone kiosk, full uplink matrix, peripheral manager, and distributed receive. Bench validation in flight.
Code-complete on main
- ✓WFB-ng radio pair with USB-C tether for Mac and Windows laptops.
- ✓OLED, four buttons, captive-portal setup webapp, Hardware tab v1.
- ✓HDMI kiosk mode, gamepad input, pilot-in-command arbiter.
- ✓Full uplink matrix with WiFi client, Ethernet, and 4G LTE.
- ✓Peripheral Manager with share-uplink iptables persistence.
- ✓Distributed receive across three node roles with self-healing mesh.
In flight
- ▶Fifteen systemd services on the ground-station profile.
- ▶Eight Hardware tab sub-views in Mission Control.
- ▶Seventeen `ados gs` CLI subcommands for role, mesh, and pairing.
- ▶Seventeen REST endpoints under /api/v1/ground-station/*.
- ▶Two-node mesh bench validation in flight.
- ▶Public docs live at docs.altnautica.com/ground-agent.
Receive long-range video. Serve any client. Heal around drops.
One install script on a Linux SBC. Open source under GPLv3.
Read the Docs