Skip to content
ARGUS User Manual

Multi-dock relay missions

Multi-dock relay dispatches a single logical mission across multiple DJI docks in sequence. Dock A launches, covers segment 1, lands at A; dock B launches, covers segment 2; and so on. The operator plans one path; ARGUS handles segment split, per-dock KMZ generation, atomic hand-offs, and failure recovery.

When to use it

A typical DJI Dock 3 aircraft covers ~10 km radius round-trip. For a 40-km linear corridor or a very large SAR area, one aircraft can’t reach the far end. Relay splits the path across 2, 3, 4+ docks positioned along the route.

Planning

  1. Create a drone mission plan spanning the full route.
  2. In the plan’s Coordination section, pick Multi-dock relay.
  3. Choose the docks that’ll participate (in order — dock A first, B next, etc.).
  4. ARGUS computes a per-dock handoff waypoint index — the waypoint where the currently-flying dock’s aircraft lands and the next dock’s takes over.
  5. Save.

Dispatch — the pre-upload trick

Traditional multi-dock relay requires the webapp to generate segment KMZs at each hand-off. That’s fragile — if the operator’s browser dies mid-mission, the chain breaks.

ARGUS instead pre-uploads every segment’s KMZ upfront so argus-dji can hand off autonomously without any webapp round-trip:

  1. When you click Dispatch, ARGUS:
    • Converts each segment to its own WPML KMZ.
    • Uploads every KMZ to S3 via presigned PUT.
    • Persists relaySegments[] on the parent mission doc: [{dockSn, startIndex, endIndex, s3Key, djiWaylineId, sizeBytes}].
    • Also writes allWaypoints: mission.waypoints so the UI can render the full planned path.
  2. Segment 0 is dispatched via the normal single-dock flow.
  3. argus-dji’s relay service listens for mission-complete events on each dock; on completion, it picks up the next segment’s entry from relaySegments[] and re-dispatches autonomously.

This means operators can close their browser, crash, go offline, whatever — the relay chain keeps running as long as argus-dji is up.

The hand-off flow

  1. Dock A’s aircraft flies segment 0 → lands at A.
  2. argus-dji multi-dock-relay-service observes the flight-complete event for segment 0.
  3. It reads relaySegments[1] from the parent mission doc.
  4. Uses a Firestore transaction to atomically claim the next dock (field relayCurrentSegment). This prevents double-dispatch if multiple dock events fire simultaneously.
  5. Creates a new dji_flight_tasks/{id} doc pointing at the pre- uploaded wayline for segment 1.
  6. Calls prepareTask on dock B → dock B takes over.

Monitoring

Operators see:

  • Map — the full planned path rendered with a colour gradient per segment. Active aircraft’s trail sits on the current segment; completed segments fade.
  • Fleet tile — one logical mission with the currently-flying dock highlighted. As handoffs happen, the fleet tile smoothly transitions to the next dock.
  • Flight log — segment-boundary events logged for after-action.

Failure handling

The system is designed to degrade gracefully:

  • KMZ missing from S3 — unlikely (presigned PUT is idempotent), but if it happens, argus-dji emits a relay.segment_failed event and pauses the chain. Operator can manually dispatch the missing segment.
  • Dock goes offline approaching a handoff — chain pauses with a master-caution alert. Operator picks: wait for dock to come back, skip the segment, or abort the chain.
  • Aircraft misses the handoff waypoint (e.g. deviated due to wind) — the delivered wayline is recoverable via recover_in_flight_wayline. argus-dji re-dispatches the segment from the last break-point.

Limitations

  • All docks in the same org. Cross-org relay isn’t supported.
  • Single drone type per chain is preferred. Mixing Dock 2 + Dock 3 works but capability chips vary per segment.
  • Minimum battery SOC required on each participating dock (org- configurable, typical 60 % for participation).
  • No live re-plan — you can’t change the route mid-chain. Abort and re-plan + re-dispatch if you need to.
  • Segment count — practical limit is ~8 docks; longer chains increase handoff-failure probability.