Skip to main content
The agent runs as a set of systemd units, one per job: MAVLink, video, radio, cloud, logging and so on. The supervisor (ados-supervisor, a native Rust orchestrator) starts, watches and restarts the other units through systemd. Every long-running unit runs inside the ados.slice cgroup. The unit names are a stable interface: you type the same systemctl restart ados-<name> whichever language a unit runs. This page is the canonical unit list. For why the services are split this way, see Agent services.

Units by profile

Which units run is decided by the node profile (and, on a ground station, the mesh role), not by the board. See Node profiles.
Each installed extension also runs as its own ados-plugin-… unit, on every profile. The unit name carries the extension id and a short hash. See Extensions.

Every unit

The full table, with the API restart permission, whether a restart drops the vehicle link, and each unit’s memory cap (MemoryMax): Notes on specific units:
  • ados-control is the HTTP front on port 8080 on every profile. The residual Python API (ados-api) runs behind it on an internal socket.
  • ados-logd ships masked; see Black Box. The supervisor starts it only when logging.store.enabled is on.
  • ados-hostapd runs hostapd directly. The access point it serves is configured by ados-net, which runs under ados-uplink-router.
  • ados-pic is the pilot-in-command arbiter on a ground station. It also reads the front-panel buttons.
  • ados-mediamtx-gs is the ground-side MediaMTX relay that serves received video to browsers.
  • Boot helpers. The units with no category in the table (ados-power, ados-usb-otg-host, ados-camera-probe, ados-display-probe and ados-fbcon-detach) are one-shot boot helpers. systemd runs them at boot; they are not in the supervisor’s registry.

The headless keep set

A lean headless node boots only the Rust core. Enable it with agent.headless: true in /etc/ados/config.yaml. The supervisor’s headless gate then permits exactly six units and blocks everything else, including ados-api: ados-mavlink, ados-swarmbus, ados-logd, ados-video, ados-wfb, ados-control. ados-control is in the set because it is the node’s only HTTP surface. ados-logd is in it because a lean flight node is the node an operator cannot reach, so it most needs its own flight recorder (it still runs only when the store is enabled).

Start order

The supervisor starts units by category: Core (for example mavlink, swarmbus, api, cloud, logd) → Hardware (video, wfb, vision, ground station units) → OnDemand (for example control). Hardware units start when their hardware is present; ados-video, for example, starts when a camera or a network video source is configured. Unit files add these orderings:
  • ados-video, ados-wfb, ados-cloud, ados-control and ados-plugin-host are After=ados-mavlink.service.
  • ados-control and ados-plugin-host are owned by systemd: the installer enables them and they start with the supervisor. The supervisor watches them but does not start them itself.
  • Units that can have nothing to do on a node (for example ados-swarmbus with no fleet slot, or ados-logd with the store off) exit 0 and stay idle instead of restarting.

Restart and crash loops

Units restart on their own:
Most units also set StartLimitIntervalSec=0, so systemd never stops retrying them. Units that have nothing to do on this node exit 0 and stay parked instead of restarting (RestartPreventExitStatus=0). After 5 failures within 60 s the supervisor labels the unit crash_looping (visible in GET /api/services) and keeps retrying it on a fixed parked cadence, so it recovers when the cause clears.
See REST API for authentication.

Resource limits

Each unit runs with cgroup limits so one service cannot starve the rest. For example, ados-mavlink.service:
The memory cap for every unit is in the Every unit table.

Dependencies on a ground station

The ground station units with explicit ordering:

Manage services

Check status

Restart a service

View logs

The journal is the log of record.

Stop and start everything

Stopping the supervisor stops the units it manages.

Unit files

The unit files are installed at:
To read one:
Do not edit the unit files directly. Upgrades overwrite them. To customize a unit (for example to add an environment variable or change a limit), use a drop-in override, which persists across upgrades:

Next steps

HAL and tiers

Board detection and the default tier.

Black Box

Turn on the durable logging store.

Drone Agent diagnostics

Check service health and the link.
Last modified on October 11, 2026