The MAVLink command protocol allows guaranteed delivery of MAVLink commands.
The protocol provides reliable delivery by expecting a matching acknowledgement (
COMMAND_ACK) from commands to indicate command arrival, and result. If no acknowledgement is received the command must be automatically re-sent.
|COMMAND_INT||Message for encoding a command (MAV_CMD). The message encodes commands into up to 7 parameters: parameters 1-4, 7 are floats, and parameters 5,6 are scaled integers. The scaled integers are used for positional information (scaling depends on the actual command value). The coordinate frame of positional parameters is explicitly specified in a frame field. Commands that require float-only properties in parameters 5, 6 cannot be sent in this message (e.g. commands where NaN has an explicit meaning).|
|COMMAND_LONG||Message for encoding a command (MAV_CMD). The mesage encodes commands into up to 7 float parameters. The coordinate frame used for positional co-ordinates is implementation dependent. Any command may be packaged in this message, but there may be some loss of precision for positional co-ordinates (latitude, longitude).|
|COMMAND_ACK||Command acknowledgement. Includes result (success, failure, still in progress) and may include progress information and additional detail about failure reasons.|
|COMMAND_CANCEL||Cancel a long running command.|
|MAV_CMD||Commands to be executed/sent in the command messages.|
|MAV_FRAME||Coordinate frame. Used in |
|MAV_RESULT||Result of command, included in COMMAND_ACK.result.|
COMMAND_INT should be used when sending commands that contain positional or navigation information, if supported by the flight stack for the particular command. This is because it allows the co-ordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". In addition latitudes/longitudes can be sent with greater precision in a
COMMAND_INT as scaled integers in params 5 and 6 (than when sent in float values in
COMMAND_LONG must be used for sending
MAV_CMD commands that send float properties in parameters 5 and 6, as these values would be truncated to integers if sent in
Commands that are not positional or that specify integers in params 5 and 6 can be used in either message, if supported by the flight stack.
Flight stacks may support commands in either message
COMMAND_LONG or both, albeit with a loss of precision, rounding errors, and/or undefined frames of reference. However they are encouraged to only support positional commands in
COMMAND_INT, and commands that have float values in param 5 and 6 in
COMMAND_LONG. The flight stack can reject commands sent in the "wrong" message type using the COMMAND_ACK.result of
MAV_RESULT_COMMAND_INT_ONLY, as appropriate. Flight stacks that only support a particular command in a particular message type can more generally use these result values to indicate the correct message type for a command.
The request is sent by the ground station encoded within a COMMAND_INT. The drone processes the request and responds quickly with a COMMAND_ACK indicating the result. The result is that the command has been accepted (
COMMAND_ACK.result=MAV_RESULT_ACCEPTED), has been accepted and is in progress (MAV_RESULT_IN_PROGRESS) or it has been rejected with some reason code. Note that "accepted" means that the command is valid and the flight stack will attempt to act on it, not that the command has completed. Most commands just return "accepted" (they are not implemented as long running commands).
COMMAND_ACK.result_param2 may also include additional information about the reason for command rejection in a command-specific enum.
If no ACK is received the GCS will resend
COMMAND_INT for a flight-specific number of times before giving up.
If the command drops the sender should increase the confirmation field:
Some commands are long running, and cannot complete immediately. The drone reports its progress by sending
COMMMAND_ACK messages with COMMAND_ACK.result=MAV_RESULT_IN_PROGRESS and the progress as a percentage in
COMMMAND_ACK.progress ([0-100] percent complete, 255 if progress not supplied). When the operation completes, the drone must terminate with a
COMMMAND_ACK containing the final result of the operation:
Long running operations may be cancelled by sending the COMMAND_CANCEL message. The drone should cancel the operation and complete the sequence by sending
- If cancellation is not supported the drone can just continue to send progress updates until completion.
- If the sequence has already completed (or is idle) the cancel command should be ignored.
The rate at which progress messages are emitted is system-dependent. Generally though, the GCS should have a much increased timeout after receiving an ACK with
If a timeout is triggered when waiting for a progress or completion update, the GCS should terminate the sequence (return to the idle state) and notify the user if appropriate.
Only one instance of a particular long running command can execute at a time; to restart a long running operation (i.e. with new parameters) it must first be cancelled! If the same command is recieved while the operation is in progress the new command should be ACKed with
MAV_RESULT_TEMPORARILY_REJECTED (to indicate that the target is busy).
The protocol allows for different long running commands to run in parallel, if supported by the state machine of the recieving flight stack. If a flight stack does not support multiple commands running in parallel it should ACK new commands with
MAV_RESULT_TEMPORARILY_REJECTED (with the possible exception of the COMMAND_CANCEL, which might be used to cancel the first request).
Commands that contain a location or altitude should be sent in COMMAND_INT so that the frame can be specified in the
COMMAND_INT.frame field (as outlined above). If sent in COMMAND_LONG the frame is arbitrary, and cannot be predicted.
A flight stack that does not support the frame specified in a command (if required by command) should reject it with the MAV_RESULT of
MAV_RESULT_COMMAND_UNSUPPORTED_MAV_FRAME. This allows consumers to attempt the same command with other frames. Flight stacks that return
MAV_RESULT_COMMAND_UNSUPPORTED for this case should be updated to use
Note that it is an error to ignore the specified frame and use some other arbitrary frame.
Guidance for designing commands can be found in Defining XML Elements > Command values.
At high level:
- Commands that include location information should specify latitude in Param 5, Longitude in param 6, and Altitude in param 7. This allows them to be sent in COMMAND_INT with higher precision.
- Otherwise it is desirable to be able to send commands in either command message. Therefore use param 5 and 6 for integers rather than floats if possible. If reserving values, then consider choosing to reserve params 5 and 6, and reserve them with a default value of