Skip to main content
This walkthrough builds one hybrid plugin that exercises four contribution kinds at once: a node-detail tab, a flight skill, a set of parameters (including a model switch), and a vision model registration. By the end you have a manifest the host parses, a GCS half that mounts, and an agent half that runs the behavior. The example follows the shape of the Follow-Me reference extension, trimmed to the parts that matter for these contribution kinds.

Prerequisites

  • Node.js 20+ and pnpm 9+.
  • A working Mission Control install for testing the GCS half.
  • A working ADOS Drone Agent if you want to run the agent half on a companion. The GCS half can be developed without one.

1. Clone and scaffold

The SDK and create-ados-plugin scaffolder live in the altnautica/ADOSExtensions monorepo. Develop your plugin alongside it as a pnpm workspace member.
The hybrid template lays out both halves:

2. Declare the manifest

Open manifest.yaml and replace the skeleton contributes block with the four contributions. Each visual surface needs its matching ui.slot.* permission.
What each block does:
1

skills → the Skill Bar

ui.slot.flight-skill lets the entry appear in the /fly cockpit Skill Bar, bound to the f hotkey. Toggling it flips the per-drone config key active; the bar reads the behavior’s live state from the follow.state event topic.
2

tabs → the node-detail tab

ui.slot.node-detail-tab mounts a tab on the drone’s detail panel. The parameters render inside it.
3

parameters → the native form

No extra slot is needed; the parameters render inside the tab. The detector parameter binds to engine.detector, so picking a model switches the drone’s active vision detector.
4

models → the vision catalog

The agent selects the variant whose board_match fits the running board, downloads it from source, and verifies it against sha256. The detector parameter’s model picker then offers it.

3. The GCS half

The tab body renders the declared parameters with the host’s native parameter panel. The definePlugin entry mounts the iframe and wires the click-to-designate overlay to the agent.
The parameters you declared are rendered and validated by the host, so the GCS half does not parse the schema or write config itself. A plugin.config commit is written to the agent over the LAN (local-first); the detector model pick switches the engine-wide detector directly.

4. The agent half

The agent half watches its per-drone config (active, standoff_*), subscribes to detections, and publishes the follow.state the Skill Bar reads back.
activation.via: config means the Skill toggle is just a config write the host already routes; the plugin reads it in on_config. The state.via: event topic (follow.state) is the channel the Skill Bar polls for the live state. See the Python SDK reference for the full context API.

5. Pack and install

pack.sh builds the GCS bundle, hashes every asset, and zips the result into extensions/track-follow/dist/com.example.track-follow-0.1.0.adosplug. Sign it with a publisher key for a release, or install the unsigned archive in developer mode for local testing:
Drag the archive into Mission Control → Settings → Plugins → Install plugin, approve the declared permissions, and the contributions mount: the Skill in the cockpit Skill Bar, the tab on the drone detail panel, the parameters inside it, and the model in the detector picker.

Verify each contribution

1

Skill Bar

Open /fly. The “Track Follow” skill is in the Skill Bar, bound to f. Press it; the per-drone config key active flips.
2

Node-detail tab

Select the drone, open its detail panel. The “Track Follow” tab is in the strip.
3

Parameters

Inside the tab, the “Follow” group shows the standoff sliders and the “Vision” group shows the detector picker. Edits clamp to the schema bounds.
4

Model

The detector picker lists coco-yolov8n (the variant matching the board). Picking it switches the drone’s active vision detector.

See also