Under active development. Breaking changes expected. APIs, installers, and UI may shift between releases.
Four ways to connect.
Usable today. Early access — some pieces run behind a feature flag and APIs may shift between releases.
CONCURRENCY
One node. Four surfaces at once.
Telemetry and video flow to every connected client. The node handles the WebRTC fanout so a pilot, a spotter, and a remote observer can all watch the same stream.
MODES
Every path in detail.
Mode 1 · HDMI kiosk
A monitor and a gamepad.
The node runs a full-screen browser on its HDMI output that renders the live WebRTC video, a minimal HUD, and a telemetry strip. Stick input comes from any HID gamepad, mapped to MANUAL_CONTROL frames sent at 50 Hz over the WFB-ng uplink.
- ✓An HDMI-capable node (Lite or Pro tier).
- ✓A monitor, an FPV goggle, or any HDMI display.
- ✓A USB or Bluetooth gamepad, no custom firmware.
Mode 2 · WiFi access point
Any laptop or phone, any browser.
On first boot the node brings up an access point with a passphrase printed on the case. Join it, open a browser at the local address, and Mission Control loads from the node itself. The full GCS, telemetry, planner, and video run locally with no cloud dependency.
- ✓Bench work on your own laptop, no cables.
- ✓A spotter on a phone while the pilot flies on HDMI.
- ✓A classroom or demo with many observers on one AP.
Mode 3 · USB-C tether
A hardwired link for Mac and Windows.
The node exposes itself as a USB Ethernet adapter over the Type-C data link. macOS and modern Linux see CDC-NCM, Windows negotiates RNDIS. DHCP hands the laptop an address and a browser loads Mission Control over the wire. No drivers, no WiFi congestion.
- ✓macOS and Linux: native CDC-NCM, no install.
- ✓Windows 11: native RNDIS fallback, no install.
- ✓The lowest-friction path to rule out WiFi during a debug session.
Mode 4 · Native Android
The ADOS app, built for a phone.
The Android app connects over the WiFi access point or a USB-C tether. A captive portal opens on first join for pairing, then the app takes over. It keeps the screen awake, controls the decoder pipeline, and survives rotation and backgrounding on field phones.
- ✓A spotter on a phone while a pilot flies on HDMI.
- ✓A solo pilot with a Bluetooth gamepad and a chest-mounted phone.
- ✓A rugged phone case for weather-sealed outdoor use.
PILOT IN COMMAND
Many viewers. One pilot.
All four modes can be live at once. Stick authority is arbitrated by a small state machine, so only one client holds the sticks at any time.
A node can serve the HDMI kiosk, a laptop on the WiFi access point, a Mac on the USB tether, and an Android phone at the same time. Telemetry and video flow to all of them, but MANUAL_CONTROL frames are single-master. A dedicated arbiter decides who has stick authority.
The Hardware tab in Mission Control shows the current pilot with a badge. Any other client can request control with a single button. The current pilot accepts the handoff or holds. A timeout releases the claim when a pilot disconnects. If no client claims the role, the node sits in observer mode and nothing flies.
LATENCY
Measured on the bench rig.
Glass to glass is the time from a shutter click on the air camera to a pixel on the ground screen. Stick to servo is the time from a gamepad axis change to a servo movement on the drone.
| Glass to glass | Stick to servo | Best for | |
|---|---|---|---|
| HDMI kiosk | <70 ms | <60 ms | Field pilot, no laptop |
| USB-C tether | <70 ms | <60 ms | Bench engineer, Mac or Windows |
| WiFi AP | <100 ms | <70 ms | Any browser, any device |
| Android app | <80 ms | <70 ms | Phone pilot or observer |
| Cloud observer | <300 ms | telemetry only | Read-only, remote operator |
HDMI kiosk
USB-C tether
WiFi AP
Android app
Cloud observer
Numbers come from bench tests on the reference rig. Field numbers depend on antenna placement and the RF environment.
One node. Many clients. One pilot at a time.
The public docs cover every mode with step-by-step pairing and troubleshooting.
Client docs