Skip to main content
Every box running the ADOS agent is a node, and every node has a profile. The profile is not a separate build: one installer, one upgrade path, one binary set. It decides which services start and which surfaces the agent serves. The profile is chosen at install time and saved to /etc/ados/profile.conf. The agent does not detect it from the hardware.

​
The four profiles

Reconstruction and perception offload are not core services on any profile. They come with the World Engine extension, which the installer turns on by default for workstation and compute and leaves off for the other two. The installer accepts ground-station and ground_station as the same value and saves the underscore form. Use ground_station in commands and config.

​
What each profile starts

The supervisor keeps one service registry with a profile gate on each entry. A service with no gate runs on every profile; a gated one runs only on the profiles it names.
  • Every profile runs the core shell: the native HTTP front on port 8080, the cloud relay, the plugin host and the extensions installed on it. The Black Box log store is available everywhere but ships off.
  • drone and ground_station add the MAVLink router, the swarm state bus, and the optional CRSF control lane and config-over-radio service when they are enabled. workstation and compute have no flight controller, so they never install or start the MAVLink router.
  • drone adds the camera encode pipeline, the WFB-ng transmitter and the onboard vision services.
  • ground_station adds WFB-ng receive and video serving, the OLED and display, the Wi-Fi access point, the HDMI kiosk and input stack with the pilot-in-command arbiter, the uplink router and, by role, the mesh services.
  • workstation and compute run only the core shell. With the World Engine extension installed, its node service runs here and never on a drone or ground station.
For the unit names, their gates and what each unit does, see Systemd services.

​
How the profile is chosen

The agent resolves the profile in this order:
  1. agent.profile in /etc/ados/config.yaml, when it holds an explicit value.
  2. /etc/ados/profile.conf, when the config field is auto, empty or absent. The installer always writes this file, and ados profile set changes it.
  3. drone as the final fallback.
The installer itself uses --profile when you pass it, then an existing /etc/ados/profile.conf (so an upgrade keeps the profile), then drone. In the interactive installer, the What is this device? screen sets it; pick This receives on the ground (Ground station) for a ground station. A non-interactive install with no --profile on a fresh box installs a drone. Pin the profile at install time:
The board is detected automatically; there is no --board flag. For every installer flag, see Install the Drone Agent.

​
macOS installs a workstation

On macOS the install script builds the installer from source and passes --profile workstation unless you pinned a profile yourself. It needs the Rust toolchain (install it with rustup) and the Xcode Command Line Tools (xcode-select --install), and the first install compiles from source. It refuses to run under sudo: a Mac node installs per-user LaunchAgents under $HOME/.ados, not into /opt and /etc.

​
Inspect and change the profile

ados profile set accepts drone and ground_station (and the ground-station spelling). It writes both /etc/ados/profile.conf and agent.profile in /etc/ados/config.yaml, then restarts ados-wfb, ados-wfb-rx and ados-supervisor so the new gates take effect. Pass --no-restart to skip that and restart yourself:
workstation and compute are install-time values. ados profile set does not set them; run the installer again with --profile to move a node onto one of those two.

​
What a workstation node does not have

A macOS workstation node is rootless and runs only the native services. Its HTTP front serves the native routes (such as /api/status and /api/pairing/*) but not the routes served by the Python service, which does not run there. The ados CLI reads the native routes on macOS for that reason. So a workstation node has no setup wizard, no captive portal, no Wi-Fi access point, no radio and no flight controller link. It has the pairing surface, the status surface, the logs and the plugin host, which runs extensions such as the World Engine as per-user LaunchAgents. A compute node is the same shell with no UI.

​
Profiles on the wire and in Mission Control

The agent reports its profile in the hyphenated form: ground_station is reported as ground-station, workstation and compute pass through, and anything unrecognised reports drone. Mission Control has built-in node surfaces for drone, ground-station and workstation. A compute node shows the workstation surfaces. An installed extension can add surfaces for the profiles it names; the World Engine’s compute and jobs tabs on a workstation or compute node come from there. The ground-station role (direct, relay or receiver) is read from /etc/ados/mesh/role and defaults to direct. Other profiles report no role.

​
Profiles in an extension manifest

An extension declares which node profiles it installs on:
The list needs at least one entry and defaults to ["drone"]. The agent refuses to install an extension whose list excludes the node’s own profile. See the manifest reference.

​
Next steps

Choose what to install

Match the software to your hardware.

Install the Drone Agent

Every installer flag and the install flow.

Install the Ground Agent

Set up a ground station.

Systemd services

Every unit and the profile that starts it.
Last modified on October 11, 2026