This document describes how external systems (ground control, operations platform, simulators) interact with the delivery drone at the broker layer. Internal components use the same JSON envelope unless noted.

For full architecture, see SYSTEM.md.

{TOPIC_VERSION}.{SYSTEM_NAME}.{INSTANCE_ID}.{component}

Example defaults:

v1.deliverydron.Delivery001.mission_handler
v1.deliverydron.Delivery001.autopilot
v1.deliverydron.Delivery001.security_monitor

If you model ground systems with the same hierarchical topic style as on-board components, you might use:

This Go delivery stack does not currently implement ORVD / NUS / droneport dialogue in autopilot; those environment variables are reserved for prepare_system.py policy substitution and future extensions.

• Motor commands: default Kafka/MQTT topic sitl.commands unless SITL_COMMANDS_TOPIC is set (flat name, not under v1.… by default).

{
  "action": "ACTION_NAME",
  "sender": "logical_or_component_sender",
  "payload": { }
}

Responses (when using request/response) follow the shared response shape from src/sdk (success, payload, correlation_id, etc.).

External systems should not publish directly to internal component topics unless policies explicitly allow their sender and you accept the risk of bypassing the monitor.

Preferred pattern:

1. Publish to …security_monitor with action: proxy_request or proxy_publish.
2. Set sender to an id that appears in policies (e.g. platform).
3. Put the real target in payload:

{
  "action": "proxy_request",
  "sender": "platform",
  "payload": {
    "target": {
      "topic": "v1.deliverydron.Delivery001.mission_handler",
      "action": "LOAD_MISSION"
    },
    "data": { }
  }
}

The monitor checks (sender, target.topic, target.action) and, if allowed, forwards to target.topic with sender rewritten to security_monitor (component id).

Topic: …mission_handler

Example LOAD_MISSION payload (shape depends on handler implementation; often includes file content or structured steps):

{
  "mission_id": "m-001",
  "format": "wpl",
  "wpl_content": "QGC WPL 110\n..."
}

Policy: sender must be allowed for (topic=…mission_handler, action=LOAD_MISSION). The bundled example policies use platform as sender for LOAD_MISSION and VALIDATE_ONLY.

Topic: …autopilot

cmd / mission_load are intended to arrive from the security monitor (sender prefix security_monitor).

Binary: cmd/delivery_drone
Default topic: derived like other components → v1.deliverydron.Delivery001.delivery_drone when using default env.

Exposes HTTP health on HEALTH_PORT (default 8080) at /health.

Broker actions (non-exhaustive): ping, get_status, echo, deliver_package, get_delivery_status — see src/delivery.

Topic: …telemetry — action get_state returns aggregated motors/cargo snapshot (via internal proxy polling).

Topic: …navigation — action get_state returns last navigation state.

If POLICY_ADMIN_SENDER is set to your admin client’s sender string, that client may call:

• set_policy, remove_policy, clear_policies, list_policies on …security_monitor.

Older deployments used deliverydron.autopilot-style names. Set explicitly per service:

COMPONENT_TOPIC=deliverydron.autopilot

Or migrate policies and clients to v1.deliverydron.Delivery001.autopilot and remove overrides.