ADOS Drone Agent

Open-source onboard agent for software-defined drones. Long-range data link. HD video. Full remote control.

Install · Docs · Issues

ados-film.webm

ADOS Drone Agent on a companion computer

ADOS Drone Agent turns the companion computer next to your flight controller into the drone's onboard brain. It reads MAVLink off the FC and routes it to every ground station at once, streams HD video over a long-range radio link or the internet, runs onboard vision when you turn it on, and hosts the extensions that add sensors, behaviors and navigation. The same software runs on the ground as the ADOS Ground Agent, the receiving end of the radio link.

It is the onboard half of ADOS, an open-source platform for software-defined drones, and it is built to be extended: through signed extensions, a Rust plugin SDK and published Rust crates. The flight-critical paths are native Rust. AI, vision inference and Python plugins run in Python.

Quick Start

Deploy to a companion computer (Raspberry Pi, Radxa, Jetson, and similar ARM64 Linux boards):

curl -sSL https://raw.githubusercontent.com/altnautica/ADOSDroneAgent/main/scripts/install.sh | sudo bash

Root is required. The one-line bootstrap fetches and verifies a prebuilt Rust installer, which places the native Rust service binaries, provisions a Python virtualenv for the feature services, configures the systemd units, and starts the setup webapp on the device.

After install, SSH into the node and run:

ados

The terminal status page shows the local setup URL, LAN or hotspot URLs, MAVLink state, video state, services, and remote-access state.

System Requirements

Requirement	Minimum	Recommended
OS	Linux with systemd (ARM64 or x86_64)	Raspberry Pi OS, Debian, Ubuntu, Armbian
RAM	1 GB	2 GB+
Storage	500 MB	2 GB+
Python	3.11+	3.12
FC connection	Serial (UART or USB)	UART at 921600 baud

Also runs on macOS for local development (the installer points you to cargo there). Boards with less than 1 GB of RAM are not supported by the standard profile.

Features

The agent's own dashboard

_{Home: services, link state and system resources. Docs}	_{Live flight controller telemetry. Docs}
_{HD video pipeline status and preview. Docs}	_{The same agent in its ground-station profile. Docs}

Parameter editor
_{Search, edit and save flight controller parameters. Writes are blocked while the vehicle is armed.}

Video link settings
_{Video link: encoder, radio state and link tuning (preset, error correction, rate). Docs}

The same agent in Mission Control

_{The fleet view: every node, how it is reached (LAN, cloud relay or radio relay) and its live state. Docs}

_{Node overview: resources, services, live logs and parameters. Docs}

_{Every paired agent in the fleet. Docs}

Extensions

Plugin catalog
_{Install signed plugins from the catalog. Docs}

On the ground and in the air

_{A ground node running the Ground Agent profile. Docs}

_{Long-range WFB-ng video and telemetry link. Docs}

_{Two or three ground nodes form a receive mesh. Docs}

Terminal console

Run ados on the device, or ados-tui --host <host> from another machine, and you get a full console for the agent in the terminal. Nine tabs cover the vehicle, the radio and LoRa link, video, flight controller parameters (stage, write, import and export), extensions with their permissions, live logs, services and peripherals, and every setting from Wi-Fi to MCP tokens. A command palette (Ctrl+K) jumps to any page or setting, and the console ships with four colour themes.

_{Vehicle: attitude, GPS, trends and per-cell battery.}	_{Link: radio state, signal, loss and bitrate, plus the LoRa lane and its beacons.}
_{Params: browse by group, stage edits against metadata, then write.}	_{Extensions: install, enable, grant permissions and edit config.}
_{Logs: live, filtered by level and service.}	_{System: services, peripherals, hardware check and agent update.}
_{The command palette jumps straight to a page or setting.}	_{Ground profile: GNSS and RTK base survey, gamepads, Bluetooth and the display.}
_{The light theme.}	_{The night-vision theme.}

Ground station front panel

In its ground-station profile the agent drives a small front-panel screen and buttons, so you can check and set up a ground node in the field without a laptop. The pages cover the drone, the ground stations attached to the node, the radio link, the network and the system, with a full dashboard on larger panels and mesh pages for neighbours, picking the node's role and joining a mesh.

_{The drone: mode, battery, satellites.}	_{Ground stations attached to the node.}	_{Radio link: signal, rate, error correction.}
_{Network: access point and uplink.}	_{System: CPU, memory, uptime.}	_{The full dashboard on a larger panel.}
_{Mesh neighbours and link quality.}	_{Role picker: direct, relay or receiver.}	_{Join scan: find a mesh and join it.}

What it lets you do

Turn a companion computer into a connected drone with one command. A single installer flashes nothing, builds nothing on the device, and leaves a paired, video-streaming, telemetry-flowing aircraft.
Pair over your own network, no cloud account. The agent auto-pairs with Mission Control over the LAN. Cloud relay is there when you want to reach the drone from anywhere, and off by default.
Fly the FC from a browser. Arm, change modes, fly guided, and upload missions. The agent routes MAVLink to WebSocket, TCP, and UDP at the same time, so several ground stations can connect at once.
Watch HD video over radio or the internet. The video pipeline drives RTSP, WebRTC (WHEP), and a long-range WFB-ng radio link, and plays back in the browser.
Reach the drone from anywhere. Optional cloud relay carries telemetry and commands over the internet with no port forwarding.
Sign your MAVLink. Transparent pass-through for MAVLink v2 signing, with one-shot flight-controller enrollment. Key material stays in the ground station, never on the agent.
Run the same agent on the ground. A ground-station profile (no flight controller, an OLED and buttons, a WFB-ng adapter) turns a small board into the receiving end of the radio link.
Build distributed receive. Two or three ground nodes form a self-healing mesh so you keep the link in obstructed areas.
Extend it without forking it. Install signed plugins that add drivers, behaviors, AI models, and ground-station hardware support.

Set up from Mission Control

Pair the agent with ADOS Mission Control and the drone opens there as one node: the flight controller and the companion computer side by side. From that one panel you set up the FC and edit every parameter (the agent carries the MAVLink, also through a ground station's radio relay), and you configure the agent itself: services and their health, peripherals, battery, the radio link, Wi-Fi, cellular and MAVLink routing and signing, cameras and perception, swarm, cloud relay, security, and the extensions installed on the drone. Extensions add their own pages to the same panel.

Smart and autonomous features

Onboard vision. The vision engine shares each camera through a frame bus, runs detection through pluggable inference backends (including NPU sidecars on boards that have one) and tracks a subject you designate.
Follow-Me (extension). Click a subject in the live video and the agent keeps a fixed standoff from it with guided setpoints. A lock-state safety gate stops commanding the moment the track goes uncertain, and it never re-locks onto a different subject on its own.
Vision Navigation (extension). GPS-denied navigation from downward optical flow: a Rust estimator pairs frames with IMU samples and sends flow messages that the flight controller fuses into its own estimator.
World Engine (beta, extension). The drone captures keyframes tagged with a pose from the flight controller, stereo visual-inertial odometry, LiDAR odometry or planar LiDAR SLAM, and streams them to a paired compute node over the LAN or the cloud, with pose and status also carried over the radio link through a ground station. The node reconstructs a Gaussian splat, point cloud, mesh and occupancy grid that you view in Mission Control.
Perception offload. The agent decides whether perception runs onboard, on a compute node or split between them, so a board without an NPU can still use detection. A freshness gate marks stale or link-lost results so a control loop holds instead of acting on them.
Swarm. Agents share a small beacon at 2 Hz, and an onboard swarm layer turns it into separation, flocking and formation setpoints at 10 Hz. Each drone broadcasts which layer is in control (hard separation, operator, formation, flocking or hold).
AI clients. ADOS MCP lets an AI client read, administer and, when you allow it, fly the drone through the agent, under scopes and a safety gate.

These features are under active development and grow with every release; build on them through extensions and the SDK.

_{Onboard vision: detection and tracking on the drone.}	_{Swarm: separation, flocking and formations from a shared beacon.}
_{World Engine (beta): a 3D world model built from posed keyframes.}	_{A compute node reconstructs world models and serves perception offload.}

What you can build on it

ADOS is a base, not a finished product for one job. These are directions it is built toward, with the pieces that exist for them today:

Smart agriculture. RTK corrections injected into the flight controller from a base station, survey missions from Mission Control, onboard detection, and payload drivers (sprayers, droppers) through the plugin SDK.
Indoor operations. Optical-flow navigation with Vision Navigation, and visual-inertial or LiDAR SLAM poses with indoor world models from World Engine (beta).
Logistics in GPS-denied warehouses. The same positioning sources, a warehouse reconstruction preset in World Engine, and perception offload to a nearby compute node.

The parts are open, so you can take them where you need them.

A survey pattern over a field
_{A survey pattern over a field, the starting point for agricultural work.}

Build on it

The agent is meant to be extended, not forked. An extension's agent half runs as a supervised Python or Rust process with the permissions it declared, and its Mission Control half adds panels on the ground. Start from ADOS Extensions and the developer docs. Rust plugins use the ados-sdk crate, Python driver plugins import ados.sdk, and the reusable libraries are published as Rust crates you can use in your own projects. Pull requests are welcome; see Contributing.

Where it fits

The Drone Agent is the onboard part of the ADOS ecosystem, and with its ground-station profile it is also the Ground Agent on the far end of the radio link. Mission Control and Android GCS reach it over the LAN or the cloud relay, Extensions run on it, and ADOS MCP gives AI clients scoped access to it.

How ADOS fits together

flowchart LR
  subgraph air["On the drone"]
    FC["Flight controller<br/>ArduPilot · PX4 · Betaflight · iNav"]
    DA["ADOS Drone Agent"]
  end
  subgraph ground["On the ground"]
    GA["ADOS Ground Agent"]
    MC["ADOS Mission Control<br/>browser · desktop"]
    AG["ADOS Android GCS"]
    MCP["ADOS MCP<br/>AI clients"]
  end
  EXT["ADOS Extensions"]
  FC <-- MAVLink --> DA
  DA <-- "long-range radio link" --> GA
  MC <-- "LAN or cloud relay" --> DA
  MC <-- LAN --> GA
  AG <-- "LAN or cloud" --> DA
  MCP <-- "LAN or cloud" --> DA
  EXT -. "agent plugins" .-> DA
  EXT -. "GCS panels" .-> MC

ADOS Ground Agent is the Drone Agent running its ground-station profile.

Repo	Runs on	What it does	Link
ADOS Mission Control	Browser, desktop (Electron)	Ground control station: FC setup, mission planning, flight, 3D simulation, fleet	ADOSMissionControl
ADOS Drone Agent	Companion computer on the drone, or a ground node	Onboard agent: MAVLink routing, HD video, long-range radio link, plugins, remote control	ADOSDroneAgent
ADOS Android GCS	Android phones and tablets	Native ground control app for agents on the LAN, direct flight controllers and the cloud	ADOSAndroidGCS
ADOS Extensions	Drone Agent and Mission Control	First-party signed plugins, each with an agent half and a GCS half	ADOSExtensions
ADOS MCP	Your machine	Model Context Protocol server that lets AI clients operate ADOS drones under scopes and a safety gate	ADOS-MCP
Documentation	docs.altnautica.com	Public docs for every ADOS product	Documentation

Why Rust

The flight-critical paths are native Rust: the process supervisor that drives systemd, the MAVLink router, the video pipeline, the WFB-ng radio control, the on-device vision host, and the HTTP control surface on :8080. That choice buys three things you can feel:

Predictable, low-overhead control and telemetry. No garbage-collector pauses on the path between the flight controller and the ground.
A small memory and CPU footprint. The native services idle in tens of megabytes, which leaves headroom for video encode and vision on modest boards.
A path to a zero-Python headless profile. On the smallest boards the agent can run the Rust core alone (MAVLink, camera, radio, control), which drops the Python interpreter and most of the memory floor with it.

Python stays where it earns its place: AI and vision inference, the Python plugin runner, hardware bring-up, and the setup webapp. A few mature C programs are supervised rather than rewritten (the RTL8812EU driver, wfb_tx and wfb_rx, ffmpeg, and mediamtx). systemd remains the process manager; the Rust supervisor orchestrates the units, it does not replace systemd.

Architecture at a glance

The agent sits between the flight controller and every ground client; the diagram in How ADOS fits together shows where it lives in the system. On the device itself:

ados-control, a native Rust HTTP front, owns port :8080. It serves the control, telemetry, pairing, parameter, fleet, plugin, video and ground-station routes natively, and reverse-proxies a small Python feature service on an internal socket for AI and vision inference, the setup webapp and peripherals.
Rust core services (systemd units): supervisor, MAVLink router, video, cloud relay, WFB-ng radio, vision host, plugin host, and ground-station receive and uplink.
Supervised C programs: the RTL8812EU driver, wfb_tx and wfb_rx, ffmpeg and mediamtx.
Python feature service: AI and vision inference, the Python plugin runner, HAL bootstrap and the setup webapp.

On a device the agent installs as a set of systemd services plus a Python virtualenv, both placed by the prebuilt Rust installer. Routes read FC status, telemetry, video, radio, and parameter state through named accessors, so the control surface stays independent of service internals.

Supported hardware

The agent auto-detects the board on boot and scales features to the resources it finds. 22 board profiles ship in src/ados/hal/boards/; any ARM64 or x86_64 Linux board with a serial port and systemd should work through a generic profile.

A companion computer stack
_{The companion computer: the agent's home on the drone.}

Board	SoC	Profile file
BeagleBoard.org BeagleY-AI	TI AM67A (J722S)	`beagley-ai.yaml`
Raspberry Pi Compute Module 3	BCM2837	`cm3.yaml`
Raspberry Pi CM4	BCM2711	`cm4.yaml`
Raspberry Pi CM5	BCM2712	`cm5.yaml`
Radxa Cubie A7S	Allwinner A733	`cubie-a7s.yaml`
Radxa Cubie A7Z	Allwinner A733	`cubie-a7z.yaml`
generic-arm64	Any	`generic-arm64.yaml`
generic-x86_64	Any	`generic-x86_64.yaml`
NVIDIA Jetson Nano	Tegra X1	`jetson-nano.yaml`
NVIDIA Jetson Orin Nano	Tegra Orin	`jetson-orin-nano.yaml`
Orange Pi 5	RK3588S	`orange-pi-5.yaml`
D-Robotics RDK X3	Horizon Sunrise X3	`rdk-x3.yaml`
Radxa CM3 (RK3566)	RK3566	`rk3566.yaml`
Rockchip RK3576 (Reference)	RK3576	`rk3576.yaml`
Radxa CM4 (RK3588S2)	RK3588S2	`rk3588s2.yaml`
Radxa ROCK 5B+ (RK3588)	RK3588	`rock-5b-plus.yaml`
Radxa ROCK 5C Lite (RK3582)	RK3582	`rock-5c-lite.yaml`
Raspberry Pi 3	BCM2837	`rpi3.yaml`
Raspberry Pi 4B	BCM2711	`rpi4b.yaml`
Raspberry Pi 5	BCM2712	`rpi5.yaml`
Rockchip RV1126B	RV1126B	`rv1126b.yaml`
Raspberry Pi Zero 2 W	BCM2710A1	`zero2w.yaml`

The same codebase also runs the ground-station profile (no flight controller, an OLED or SPI LCD with buttons, and a WFB-ng adapter); a hardware fingerprint at boot picks the profile.

Mesh role hardware. A single ground node (direct role) needs one RTL8812EU USB WiFi adapter for WFB-ng. Relay and receiver nodes add a second USB WiFi dongle that carries the batman-adv mesh traffic between nodes. Any adapter with a Linux driver that supports 802.11s or IBSS mode works for the mesh carrier.

Rust crates

The reusable libraries under crates/ are published on crates.io under MIT OR Apache-2.0 (ados-sensorhub is MIT). The full index, with versioning rules, is crates/README.md.

Platform (versioned with the ADOS Drone Agent)

Crate	What it does	Docs
`ados-protocol`	Wire contracts of the ADOS Drone Agent: IPC framing, plugin RPC envelope, capability tokens and the vision frame bus.	docs.rs
`ados-sdk`	Write Rust plugins for the ADOS Drone Agent: IPC client, plugin context, driver traits and lifecycle runner.	docs.rs
`ados-vision`	Single-object visual tracker: Kalman motion model, appearance re-identification and YOLOv8 head decoding.	docs.rs
`ados-gpio`	Drive status buzzers and LEDs on Linux GPIO lines, with bounded software-PWM beep patterns.	docs.rs
`ados-hal-probe`	Find out what a board's hardware can really do by probing it, plus bundled board profiles.	docs.rs

Standalone

Crate	What it does	Docs
`ados-sensorhub`	Sensor hub wire protocol: COBS framing, CRC-16 and fixed-layout IMU, baro, mag and GNSS packets. no_std.	docs.rs
`ados-offload`	Choose where perception runs (onboard, offloaded or hybrid) and hold the vehicle when results go stale.	docs.rs
`ados-macpin`	Stable MAC addresses for Linux network adapters that randomize theirs every boot.	docs.rs
`ados-lora`	LoRa transmit governor with cited regional band plans, duty cycle, dwell time and airtime accounting.	docs.rs
`ados-crsf-codec`	no_std CRSF / ExpressLRS codec for RC channels, telemetry and parameter frames.	docs.rs
`ados-positioning`	Split mixed UBX, NMEA and RTCM3 GNSS streams, configure u-blox receivers and run an RTK base survey-in.	docs.rs
`ados-rtcm`	RTCM3 framing, CRC-24Q and MAVLink GPS_RTCM_DATA fragmentation for RTK corrections.	docs.rs
`ados-clock`	Map remote clocks onto the host clock: least-squares and envelope fits, TIMESYNC and a chrony sink.	docs.rs
`ados-swarm`	Swarm control laws: separation, flocking, formations, CBBA task allocation and a point-mass simulator.	docs.rs
`ados-mavlink-tunnel`	Send large messages over MAVLink TUNNEL frames with chunking and bounded reassembly.	docs.rs
`ados-display-driver`	Small-display output on Linux: SSD1306/SH1106 OLED over I2C, pixel packers and a framebuffer writer.	docs.rs
`ados-hmi`	Front-panel input: touchscreen calibration and gestures, button presses and rotary encoders.	docs.rs

CLI Reference

The public everyday CLI is intentionally small. Run ados --help for the current command list.

Command	Description
`ados`	Open the terminal console, or plain status when not attached to a TTY
`ados status`	Print setup, MAVLink, video, network, remote-access, and service status
`ados status --json`	Print the full setup facade payload for scripts
`ados update`	Update the agent to the latest version (re-runs the installer upgrade)
`ados update --check-only`	Report the current and latest version without installing
`ados uninstall`	Remove the agent from the system
`ados uninstall --purge --yes`	Remove services, package files, and config without prompts

Grouped subcommands cover the deeper surfaces: ados plugin (install and manage plugins), ados logs (query the on-device black-box log store), ados network, ados radio, and ados profile. Use the setup webapp or the Mission Control node panel for configuration, ground-station pairing, video, network, and remote access.

REST API

Served by the native Rust front (ados-control) on :8080. Control, telemetry, plugin and WHEP video routes are native; AI/vision, setup, and peripheral routes are proxied to the Python feature service. Full reference at docs.altnautica.com.

Endpoint	Method	Description
`/api/v1/setup/status`	GET	Universal setup, access URL, MAVLink, video, network, and remote-access status
`/api/v1/setup/remote-access/cloudflare`	POST	Install a Cloudflare Tunnel token or install command
`/api/status`	GET	Agent status, uptime, FC state
`/api/telemetry`	GET	Attitude, GPS, battery snapshot
`/api/params`	GET	Read cached FC parameters
`/api/command`	POST	Send a MAVLink command to the FC
`/api/commands`	GET	List supported command names
`/api/config`	GET / PUT	Read or update agent config
`/api/services`	GET	Running services and status
`/api/video`	GET / POST	Video pipeline status and control
`/api/plugins`	GET / POST / DELETE	Plugin install, list, enable, disable, remove, info
`/api/fleet/*`	GET	Fleet enrollment and peer status
`/api/peripherals`	GET	Connected sensors and hardware
`/api/pairing/*`	GET / POST	GCS pairing management
`/api/mavlink/signing/*`	GET / POST	Signing capability detection and one-shot FC enrollment
`/api/system`	GET / POST	System info, reboot, shutdown
`/api/v1/ground-station/*`	GET / PUT / POST / DELETE	Ground-station profile only. Role, mesh, pairing, WFB-ng relay/receiver, uplinks, physical UI

# Get current telemetry
curl http://localhost:8080/api/telemetry

# Arm the drone
curl -X POST http://localhost:8080/api/command \
  -H "Content-Type: application/json" \
  -d '{"command": "arm"}'

Connectivity

ADOS is local-first. The primary path between Mission Control and the agent is your own network.

Local pairing (default). Mission Control reaches the agent over the LAN by hostname or IP. The apiKey is stored in the browser, with no cloud round-trip. An agent with cloud relay disabled is in its normal, correct state.

Long-range radio link. The drone-to-ground data link is WFB-ng on 5.8 GHz, with forward error correction, for video and telemetry without any internet. It auto-binds to the ground station on first boot.

LoRa beacon lane. A low-duty LoRa lane carries position beacons, short status reports and text, never video or control. Every frame passes a regional governor (band plan, duty cycle, dwell time and power) before it reaches the radio.

_{LoRa beacons between the drone and ground nodes.}

_{The drone's link relayed through a ground node to the operator.}

Cloud relay (optional). For remote access across networks, the agent connects to Mission Control over a relay:

Convex HTTP (baseline). Every 5 seconds the agent posts full status to the cloud, and the ground station reads it through reactive queries. Commands go the other way. No extra infrastructure.
MQTT telemetry (real-time). When server.mode is cloud or self_hosted, the agent publishes to ados/{deviceId}/status and ados/{deviceId}/telemetry over a Mosquitto WebSocket. The browser subscribes directly. 2 Hz and faster.
RTSP video. The video pipeline pushes to a cloud relay that converts it to fMP4 over WebSocket for browser playback at 0.5 to 1.5 s latency.

Config field	Default	Description
`server.mode`	`disabled`	`disabled`, `cloud`, or `self_hosted`
`server.mqtt_transport`	`tcp`	`tcp` or `websockets`
`server.mqtt_username`	-	MQTT broker username
`video.cloud_relay_url`	-	RTSP relay server URL

Directory Structure

Path	Contents
`crates/`	Native Rust services (one crate per service) plus the shared protocol and SDK crates
`src/ados/`	Python runtime: feature service, HAL detection, plugins, SDK, ground-station managers
`data/`	systemd units, udev rules, overlays, and other deploy-time assets
`scripts/`	Installer bootstrap and helper scripts
`dashboard/`	Local web dashboard assets
`docs/`	Deployment, ground-station, and OEM documentation
`tests/`	Test suite

What's Working

Feature	Status
Native Rust HTTP front (`ados-control` on `:8080`)	Working
Rust process supervisor (systemd orchestration)	Working
MAVLink router (serial to WS/TCP/UDP)	Working
Prebuilt Rust installer (fetch, verify, provision, configure)	Working
Minimal public CLI	Working
Demo mode (simulated telemetry)	Working
Hardware auto-detection (board profiles)	Working
Config system (Pydantic + YAML)	Working
Health monitoring (CPU, RAM, disk, temp)	Working
On-device black-box log store (`ados logs`)	Working
Cloud relay (Convex HTTP + MQTT)	Working
GCS pairing (local-first over LAN, cloud relay optional)	Working
MAVLink v2 signing pass-through	Working
Agent updates (`ados update`)	Working
Video pipeline (RTSP, WebRTC/WHEP, WFB-ng)	Working
WFB-ng long-range link (5.8 GHz, FEC, auto-bind)	Working
On-device vision host (frame bus, detectors)	Working
Plugin system (Python and Rust plugins)	Working
Ground-station distributed receive and local mesh	Working
Onboard swarm layer (beacon, separation, flocking, formations)	Working
World Engine extension (world models, perception offload)	Beta

Development

The Python runtime:

git clone https://github.com/altnautica/ADOSDroneAgent.git
cd ADOSDroneAgent
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

pytest          # run tests
ruff check src/ # lint
ados --help     # inspect the public CLI

The native services live under crates/ (a Cargo workspace):

cargo build     # build the Rust service crates
cargo test

On a device the installer fetches prebuilt Rust binaries, so deploying needs no Rust toolchain. You only need one to build the services from source.

See AGENTS.md for architecture notes and CONTRIBUTING.md for code style and PR guidelines.

Community

Discord - Ask questions, share builds
LinkedIn - Follow company updates
Email - team@altnautica.com
Issues - Bug reports and discussions
Website - Company and product info

Contributing

See CONTRIBUTING.md for code style and PR guidelines, and AGENTS.md for architecture notes.

License

GPL-3.0-or-later. Copyright 2026 Altnautica. Free to use, modify, and distribute; modified versions you distribute must also be GPL-3.0-or-later. Library crates under crates/ listed in crates/README.md are MIT OR Apache-2.0.

Name		Name	Last commit message	Last commit date
.github		.github
cockpit		cockpit
crates		crates
dashboard		dashboard
data		data
docs		docs
etc/tmpfiles.d		etc/tmpfiles.d
schemas		schemas
scripts		scripts
src/ados		src/ados
tests		tests
tools		tools
vendor		vendor
web-shared		web-shared
.git-blame-ignore-revs		.git-blame-ignore-revs
.gitattributes		.gitattributes
.gitignore		.gitignore
.gitmodules		.gitmodules
AGENTS.md		AGENTS.md
CHANGELOG.md		CHANGELOG.md
CONTRIBUTING.md		CONTRIBUTING.md
LICENSE		LICENSE
README.md		README.md
RELEASE.md		RELEASE.md
pyproject.toml		pyproject.toml

Navigation Menu

Repository navigation

About

Repository files navigation

ADOS Drone Agent

Quick Start

System Requirements

Features

The agent's own dashboard

The same agent in Mission Control

Extensions

On the ground and in the air

Terminal console

Ground station front panel

What it lets you do

Set up from Mission Control

Smart and autonomous features

What you can build on it

Build on it

Where it fits

How ADOS fits together

Why Rust

Architecture at a glance

Supported hardware

Rust crates

CLI Reference

REST API

Connectivity

Directory Structure

What's Working

Development

Community

Contributing

License

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

ADOS Drone Agent

Quick Start

System Requirements

Features

The agent's own dashboard

The same agent in Mission Control

Extensions

On the ground and in the air

Terminal console

Ground station front panel

What it lets you do

Set up from Mission Control

Smart and autonomous features

What you can build on it

Build on it

Where it fits

How ADOS fits together

Why Rust

Architecture at a glance

Supported hardware

Rust crates

CLI Reference

REST API

Connectivity

Directory Structure

What's Working

Development

Community

Contributing

License

About

Topics

Resources

Contributing

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages