The mission protocol is the primary way a GCS uploads a flight plan to an autopilot. It uses a stateful, acknowledged transaction so that both sides agree on every mission item before the vehicle flies it.
There are three main operations: upload (GCS → vehicle), download (vehicle → GCS), and clear. Each uses a handshake sequence with MISSION_COUNT, MISSION_ITEM_INT, MISSION_REQUEST_INT, and MISSION_ACK.
text
Upload sequence ─────────────────────────────────────────── GCS Autopilot │── MISSION_COUNT ────────→│ │ │ │←── MISSION_REQUEST_INT ──│ (seq 0) │── MISSION_ITEM_INT ─────→│ (seq 0) │ │ │←── MISSION_REQUEST_INT ──│ (seq 1) │── MISSION_ITEM_INT ─────→│ (seq 1) │ ... │ │←── MISSION_ACK ──────────│ (type=ACCEPTED)
Timeout and retransmission
If MISSION_REQUEST_INT is not received within ~1.5 s, the GCS retransmits the last MISSION_ITEM_INT. After 5 retries the transfer is aborted. Always use the _INT variants — they carry lat/lon as int32 for full precision.
To download the current mission, the GCS sends MISSION_REQUEST_LIST and the autopilot responds with MISSION_COUNT, then the GCS pulls each item with MISSION_REQUEST_INT. Clear is a single MISSION_CLEAR_ALL followed by MISSION_ACK.