Ground control software handover checklist

1. Identify the release being handed over

Record the application build, operating system, vehicle firmware, payload versions and configuration files together. Include the supported hardware and any required network services. A version number shown in the interface should match the release notes and delivered package. Separate required dependencies from optional features so that an offline installation has a clear scope.

• Provide an installation guide and a configuration export.
• Identify licence obligations, source access and update ownership.
• List known limitations and the conditions under which the release was checked.

2. Walk through the operator's actual task

Ask a representative user to start the application, identify the correct platform, inspect its state and complete an agreed task. Record where they need help. Explain the difference between selecting a device, viewing its data and gaining command authority. Where several devices are visible, make the active target clear before any action is available.

• Check startup, device selection, preparation, operation and shutdown.
• Identify which controls require confirmation or a permitted system state.
• Record training needs and the quickest route to operating instructions.

3. Check state, feedback and data age

A connection indicator should not imply that every sensor is healthy or that displayed values are current. In MAVLink, a heartbeat advertises a component's presence and state. The receiving application still needs to present the information relevant to the task. Specify when a reading becomes stale and how the user can distinguish it from a valid zero.

• Check vehicle identity, control mode and the age of important readings.
• Make unknown, disconnected and fault states distinguishable.
• Confirm that alerts identify the affected component and a useful next action.

Reference: MAVLink Heartbeat/Connection Protocol

4. Distinguish a request from a completed action

Test the full command path from the user's input to the observed result. MAVLink's command documentation distinguishes an accepted command from a completed action. The interface should explain rejection, progress, completion and timeout where those states apply. Define retry behaviour so that a slow response does not encourage repeated button presses with uncertain consequences.

• Record expected feedback for accepted, rejected and unsupported requests.
• Check that cancelling an operation gives an accurate result.
• Confirm that reconnecting does not silently resend an old user action.

Reference: MAVLink Command Protocol

5. Agree loss-of-connection and recovery checks

Separate application behaviour from vehicle behaviour. A ground station closing does not itself establish what the platform will do. ArduPilot Rover's GCS failsafe depends on heartbeat monitoring and configured parameters. For the selected system, review the intended response and verify it in a controlled setup before relying on it during a moving trial.

• Check an application restart and an interrupted connection.
• Define recovery authority and the information required before resuming.
• Record configuration-dependent exceptions and the evidence for each response.

Reference: ArduPilot Rover: Failsafes

6. Make support and evidence usable

Give the receiving team a repeatable way to capture a problem. A useful report identifies the release, device, time, expected result and observed result, with relevant logs. Record who can access logs, how long they are kept and how sensitive material is handled. Do not place credentials or private network details in a general handover guide.

• Verify log export and the ability to match a record to a session.
• Provide a known working configuration and a documented recovery route.
• Name the support contact and the process for reviewing a new release.

7. Record acceptance and remaining limits

Use observed results to close the handover checklist. Keep a failed or unperformed check visible, with an owner and an agreed next step. Distinguish acceptance for a development trial from acceptance for a wider operating environment. RCDEN is developing mission software around defined operator workflows; the appropriate handover evidence depends on that agreed scope.

• Identify the receiving person and the configuration reviewed.
• Record each result and link the supporting evidence.
• List operating limits, outstanding actions and any conditions on use.

Further reading

• MAVLink Heartbeat/Connection Protocol
• MAVLink Command Protocol
• ArduPilot Rover: Failsafes