Skip to main content
A plugin adds code, hardware support, UI panels and flight behaviors to ADOS without forking the core projects. One signed .adosplug archive installs on a drone or ground station node; from there each half runs in isolation with the capabilities the operator granted. Operators see installed plugins as Extensions.

​
Two halves, one plugin

A single manifest.yaml declares up to two halves. Either half is optional, so a plugin can ship agent-only, GCS-only, or both.
  • Agent half runs as its own systemd unit on the node, under a dedicated system user, inside the ados-plugins.slice cgroup with CPU, memory and process limits. It talks to the plugin host over a Unix domain socket using length-prefixed msgpack frames, gated by an HMAC capability token. Write it in Python (runtime: python) or Rust (runtime: rust); both speak the same wire to the same host.
  • GCS half runs in a sandboxed iframe inside Mission Control (sandbox="allow-scripts", no same-origin, no network egress). It talks to the host over postMessage, and the host checks every call against the granted capabilities. Write it in TypeScript.
The host gates every privileged call against the grants. A plugin that did not declare mavlink.write cannot write to the flight controller, and the operator approves each declared permission at install time.

​
Pick your SDK

All three SDKs speak the same capability-token contract to the same host, so the choice is the language you want to write in.

Python (agent)

ados.sdk: the plugin context, driver base classes, vision client and test harness for a Python agent half.

Rust (agent)

The ados-sdk crate: the same agent surface, compiled to a native binary that runs directly under systemd.

TypeScript (GCS)

@altnautica/plugin-sdk: the browser-side SDK for a GCS half that mounts panels in Mission Control.

​
The four primitives

Every plugin is described by four things: a manifest (what it is and what it asks for), a signature (who built it, verified before install), a sandbox (the isolation it runs inside), and a set of capability tokens (the only privileges it gets at runtime). Read Concepts for how they fit together.

​
How plugins reach a node

Plugin authors ship signed .adosplug archives. A node installs one from:
  • A local file. Choose Install from file on the node’s Extensions tab in Mission Control, or run ados plugin install <file>.adosplug on the node.
  • A URL. Install from a hosted archive, for example a GitHub Releases asset. See Install from a URL.
  • The first-party catalog. First-party extensions and the built-in plugins install by id (ados plugin install <id>, or from the list on the Extensions tab).
Signing and key enrolment are covered in Signing keys.

​
License

Plugins are independent works. GPL-3.0-or-later matches the host, but any OSI-approved license works. Closed-source plugins are allowed; they cannot link against ADOS GPL code at the source level.

​
Next steps

Your first plugin

Scaffold, test, sign and install a GCS-only tab that reads battery telemetry.

Concepts

Manifest, signature, sandbox and capability tokens.

Manifest

Every field the host reads.

Permissions

The capability catalog and its risk levels.
Last modified on October 11, 2026