You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ko/guide/mavlink_version.md
+24-7Lines changed: 24 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,9 +19,7 @@ Legacy code may be present in generator and test code.
19
19
A library's MAVLink support can be determined in a number of ways:
20
20
21
21
-[AUTOPILOT_VERSION](../messages/common.md#AUTOPILOT_VERSION)`.capabilities` can be checked against the [MAV_PROTOCOL_CAPABILITY_MAVLINK2](../messages/common.md#MAV_PROTOCOL_CAPABILITY_MAVLINK2) flag to verify MAVLink 2 support.
22
-
-[PROTOCOL_VERSION](../messages/common.md#PROTOCOL_VERSION).`version` contains the MAVLink version number multiplied by 100: v1.0 is 100, <!-- v2.0 is 200, --> v2.3 is 203 etc.
23
-
-[HEARTBEAT](../messages/common.md#HEARTBEAT)`.mavlink_version` field contains the minor version number.
24
-
This is the `<version>` field defined in the [Message Definitions](../messages/index.md) (`version` in [common.xml](../messages/common.md) for dialects that depend on the common message set).
22
+
25
23
- The major version can be determined from the packet start marker byte:
26
24
27
25
- MAVLink 1: `0xFE`
@@ -32,24 +30,42 @@ A library's MAVLink support can be determined in a number of ways:
32
30
so no messages will even be detected (see [Serialization](../guide/serialization.md)).
33
31
:::
34
32
33
+
-[HEARTBEAT](../messages/common.md#HEARTBEAT)`.mavlink_version` field contains the minor version number.
34
+
This is the `<version>` field defined in the [Message Definitions](../messages/index.md) (`version` in [common.xml](../messages/common.md) for dialects that depend on the common message set).
35
+
36
+
-[PROTOCOL_VERSION](../messages/common.md#PROTOCOL_VERSION).`version` contains the MAVLink version number multiplied by 100: v1.0 is 100, <!-- v2.0 is 200, --> v2.3 is 203 etc.
37
+
Note that the message allows for additional version information, but is not supported on all flight stacks.
38
+
35
39
:::tip
36
40
While messages do not contain version information, an extra CRC is used to ensure that a library will only process compatible messages (see [Serialization > CRC_EXTRA](../guide/serialization.md)).
37
41
:::
38
42
39
43
## Version Handshaking {#version_handshaking}
40
44
41
45
Support for _MAVLink 2_ is indicated in the [AUTOPILOT_VERSION](../messages/common.md#AUTOPILOT_VERSION) message by the [MAV_PROTOCOL_CAPABILITY_MAVLINK2](../messages/common.md#MAV_PROTOCOL_CAPABILITY_MAVLINK2) flag.
46
+
It can also be inferred from the packet start marker byte.
42
47
43
48
This is sufficient if the communication link between autopilot and GCS is completely transparent.
44
-
However, most communication links are not completely transparent as they either include routing or in case of fixed-length wireless implementations on packetization.
45
-
In order to also test the link, the _MAVLink 2_ handshake protocol sends a _MAVLink 2_ frame to test the complete communication chain.
49
+
However, some communication links are not completely transparent as they include:
50
+
51
+
- Routing, which can can change or reserialize MAVLink packets (for example, there might be an intermediate router that converts between versions).
52
+
- Wireless links that rely on fixed length packetization may distort or truncate variable-length MAVLink 2 frames.
46
53
47
-
To do so, the GCS sends a [COMMAND_LONG](../messages/common.md#COMMAND_LONG) or [COMMAND_INT](../messages/common.md#COMMAND_INT) message with the command ID [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE) and param1=300 (PROTOCOL_VERSION)
54
+
:::info
55
+
Some flight stacks assume MAVLink 2 support based on the protocol capability or packet start marker.
56
+
This is reasonable because the majority of systems and communication links now reliably support MAVLink 2.
57
+
:::
48
58
59
+
To be certain that a link supports _MAVLink 2_ transparently, a GCS or other component can use the _MAVLink 2_ handshake protocol to test the link.
60
+
This is done by sending the [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE) command with `param1=300` ([PROTOCOL_VERSION](../messages/common.md#PROTOCOL_VERSION)).
49
61
If the system supports _MAVLink 2_ and the handshake it will respond with [PROTOCOL_VERSION](../messages/common.md#PROTOCOL_VERSION)**encoded as MAVLink 2 packet**.
50
62
If it does not support _MAVLink 2_ it should `NACK` the command.
51
63
The GCS should fall back to a timeout in case the command interface is not implemented properly.
52
64
65
+
:::tip
66
+
If the target system does not support `PROTOCOL_VERSION` you can request any other message that it is able to emit.
67
+
:::
68
+
53
69
The diagram below illustrates the complete sequence.
Some popular legacy radios (e.g. the SiK radio series) operate in semi-transparent mode by injecting [RADIO_STATUS](../messages/common.md#RADIO_STATUS) messages into the MAVLink message stream. Per MAVLink spec these should actually emit a heartbeat with the same system ID and a different component ID than the autopilot to be discoverable.
86
+
Some popular legacy radios (e.g. the SiK radio series) operate in semi-transparent mode by injecting [RADIO_STATUS](../messages/common.md#RADIO_STATUS) messages into the MAVLink message stream.
87
+
Per MAVLink spec these should actually emit a heartbeat with the same system ID and a different component ID than the autopilot to be discoverable.
71
88
However, an additional heartbeat could be an issue for deployed systems.
72
89
Therefore these radios can alternatively confirm their _MAVLink 2_ compliance by emitting `RADIO_STATUS` in v2 message format after receiving the first MAVLink v2 frame.
| target_system | `uint8_t` | | System the GCS requests control for |
119
-
| control_request | `uint8_t` | | 0: request control of this MAV, 1: Release control of this MAV |
120
-
| version | `uint8_t` | rad | 0: key as plaintext, 1-255: future, different hashing/encryption variants. The GCS should in general use the safest mode possible initially and then gradually move down the encryption level if it gets a NACK message indicating an encryption mismatch. |
121
-
| passkey | `char[25]` | | Password / Key, depending on version plaintext or encrypted. 25 or less characters, NULL terminated. The characters may involve A-Z, a-z, 0-9, and "!?,.-" |
| target_system | `uint8_t` | System the GCS requests control for |
119
+
| control_request | `uint8_t` | 0: request control of this MAV, 1: Release control of this MAV |
120
+
| version | `uint8_t` | 0: key as plaintext, 1-255: future, different hashing/encryption variants. The GCS should in general use the safest mode possible initially and then gradually move down the encryption level if it gets a NACK message indicating an encryption mismatch. |
121
+
| passkey | `char[25]` | Password / Key, depending on version plaintext or encrypted. 25 or less characters, NULL terminated. The characters may involve A-Z, a-z, 0-9, and "!?,.-" |
<span class="warning">**WORK IN PROGRESS**: Do not use in stable production environments (it may change).</span>
2864
+
### PROTOCOL_VERSION (300) {#PROTOCOL_VERSION}
2867
2865
2868
2866
Version and capability of protocol version. This message can be requested with [MAV_CMD_REQUEST_MESSAGE](#MAV_CMD_REQUEST_MESSAGE) and is used as part of the handshaking to establish which MAVLink version should be used on the network. Every node should respond to a request for [PROTOCOL_VERSION](#PROTOCOL_VERSION) to enable the handshaking. Library implementers should consider adding this into the default decoding state machine to allow the protocol core to respond directly.
2869
2867
@@ -4435,7 +4433,7 @@ Result from a MAVLink command ([MAV_CMD](#mav_commands))
| <a id='MAV_RESULT_ACCEPTED'></a>0 | [MAV_RESULT_ACCEPTED](#MAV_RESULT_ACCEPTED) | Command is valid (is supported and has valid parameters), and was executed. |
4437
4435
| <a id='MAV_RESULT_TEMPORARILY_REJECTED'></a>1 | [MAV_RESULT_TEMPORARILY_REJECTED](#MAV_RESULT_TEMPORARILY_REJECTED) | Command is valid, but cannot be executed at this time. This is used to indicate a problem that should be fixed just by waiting (e.g. a state machine is busy, can't arm because have not got GPS lock, etc.). Retrying later should work. |
4438
-
| <a id='MAV_RESULT_DENIED'></a>2 | [MAV_RESULT_DENIED](#MAV_RESULT_DENIED) | Command is invalid (is supported but has invalid parameters). Retrying same command and parameters will not work. |
4436
+
| <a id='MAV_RESULT_DENIED'></a>2 | [MAV_RESULT_DENIED](#MAV_RESULT_DENIED) | Command is invalid; it is supported but one or more parameter values are invalid (i.e. parameter reserved, value allowed by spec but not supported by flight stack, and so on). Retrying the same command and parameters will not work. |
4439
4437
| <a id='MAV_RESULT_UNSUPPORTED'></a>3 | [MAV_RESULT_UNSUPPORTED](#MAV_RESULT_UNSUPPORTED) | Command is not supported (unknown). |
4440
4438
| <a id='MAV_RESULT_FAILED'></a>4 | [MAV_RESULT_FAILED](#MAV_RESULT_FAILED) | Command is valid, but execution has failed. This is used to indicate any non-temporary or unexpected problem, i.e. any problem that must be fixed before the command can succeed/be retried. For example, attempting to write a file when out of memory, attempting to arm when sensors are not calibrated, etc. |
4441
4439
| <a id='MAV_RESULT_IN_PROGRESS'></a>5 | [MAV_RESULT_IN_PROGRESS](#MAV_RESULT_IN_PROGRESS) | Command is valid and is being executed. This will be followed by further progress updates, i.e. the component may send further [COMMAND_ACK](#COMMAND_ACK) messages with result [MAV_RESULT_IN_PROGRESS](#MAV_RESULT_IN_PROGRESS) (at a rate decided by the implementation), and must terminate by sending a [COMMAND_ACK](#COMMAND_ACK) message with final result of the operation. The [COMMAND_ACK](#COMMAND_ACK).progress field can be used to indicate the progress of the operation. |
0 commit comments