mirror/mavlink-devguide
1
0
Fork 0
mirror of https://github.com/mavlink/mavlink-devguide.git synced 2026-06-19 07:36:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

New Crowdin updates (#677)

Browse Source 
* New translations index.md (Korean)

* New translations payload.md (Korean)

* New translations traffic_management.md (Korean)

* New translations define_xml_element.md (Korean)

* New translations mavlink_version.md (Korean)

* New translations index.md (Korean)

* New translations faq.md (Korean)

* New translations contributing.md (Korean)

* New translations generate_libraries.md (Korean)

* New translations installation.md (Korean)

* New translations mavlink_2.md (Korean)

* New translations message_signing.md (Korean)

* New translations packet_loss.md (Korean)

* New translations serialization.md (Korean)

* New translations wireshark.md (Korean)

* New translations xml_schema.md (Korean)

* New translations crc.md (Korean)

* New translations index.md (Korean)

* New translations howto_requestmessages.md (Korean)

* New translations mission.md (Korean)

* New translations offboard_control.md (Korean)

* New translations parameter.md (Korean)

* New translations timesync.md (Korean)

* New translations arm_authorization.md (Korean)

* New translations battery.md (Korean)

* New translations camera_v1.md (Korean)

* New translations command.md (Korean)

* New translations events.md (Korean)

* New translations gimbal_v2.md (Korean)

* New translations component_metadata.md (Korean)

* New translations index.md (Chinese Simplified)

* New translations payload.md (Chinese Simplified)

* New translations traffic_management.md (Chinese Simplified)

* New translations define_xml_element.md (Chinese Simplified)

* New translations mavlink_version.md (Chinese Simplified)

* New translations index.md (Chinese Simplified)

* New translations faq.md (Chinese Simplified)

* New translations contributing.md (Chinese Simplified)

* New translations generate_libraries.md (Chinese Simplified)

* New translations installation.md (Chinese Simplified)

* New translations mavlink_2.md (Chinese Simplified)

* New translations message_signing.md (Chinese Simplified)

* New translations packet_loss.md (Chinese Simplified)

* New translations serialization.md (Chinese Simplified)

* New translations wireshark.md (Chinese Simplified)

* New translations xml_schema.md (Chinese Simplified)

* New translations crc.md (Chinese Simplified)

* New translations index.md (Chinese Simplified)

* New translations howto_requestmessages.md (Chinese Simplified)

* New translations mission.md (Chinese Simplified)

* New translations offboard_control.md (Chinese Simplified)

* New translations parameter.md (Chinese Simplified)

* New translations timesync.md (Chinese Simplified)

* New translations arm_authorization.md (Chinese Simplified)

* New translations battery.md (Chinese Simplified)

* New translations camera_v1.md (Chinese Simplified)

* New translations command.md (Chinese Simplified)

* New translations events.md (Chinese Simplified)

* New translations gimbal_v2.md (Chinese Simplified)

* New translations component_metadata.md (Chinese Simplified)

* New translations common.md (Korean)

* New translations common.md (Chinese Simplified)
This commit is contained in:
PX4 Build Bot
2026-03-10 12:15:23 +11:00
committed by GitHub
parent d9404dbc01
commit aa19069c30
62 changed files with 262 additions and 248 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ko/about/faq.md
+1 -1
View File
@@ -69,6 +69,6 @@
<dt>How can I further reduce the generated C library size?</dt>
<dd>On extremely resource-constrained systems you may be able to reduce the size of the generated library by setting <code>MAVLINK_COMM_NUM_BUFFERS=1</code> and <code>MAVLINK_MAX_PAYLOAD_LEN</code>="size of your largest buffer" (assuming only one comm link and that your payload is less than the maximum supported by MAVLink).
You should also make sure that any buffers you use to pass into MAVLink are also as small as possible (e.g. the one passed into <code>mavlink_msg_to_send_buffer()</code>).
<br><br>Another alternative is to use one of the other generators. For example <a href="https://github.com/olliw42/fastmavlink">fastMavlink</a> asserts that it is smaller and more efficient than the libraries generated by mavgen (this has not been valided by the MAVLink project).</dd>
<br><br>Another alternative is to use one of the other generators. For example <a href="https://github.com/olliw42/fastmavlink">fastMavlink</a> asserts that it is smaller and more efficient than the libraries generated by mavgen (this has not been validated by the MAVLink project).</dd>
</dl>
ko/contributing/contributing.md
+3 -3
View File
@@ -28,7 +28,7 @@ The sections below explain how to contribute to each category and how to raise a
Changes to the [mavgen](../getting_started/generate_libraries.md#mavgen) generator must be added as pull requests through the [ArduPilot/pymavlink](https://github.com/ArduPilot/pymavlink) project.
Changes to existing generator code (e.g. bug fixes) are automatically tested by continuous integration (github actions).
Once you have made against your PR pass, the changes will be reviewed by a project team member.
Once you have made your PR pass, the changes will be reviewed by a project team member.
More significant changes to the generator, such as the addition of a new programming language, will require:
@@ -47,14 +47,14 @@ Ideally:
## How to Contribute Stand Alone Generators
We would prefer that new languages are supported via [mavgen](../getting_started/generate_libraries.md#mavgen) rather than "standalone generators", as this provides a consistent inteface for end users, and ensures that source files are parsed and handled consistently.
We would prefer that new languages are supported via [mavgen](../getting_started/generate_libraries.md#mavgen) rather than "standalone generators", as this provides a consistent interface for end users, and ensures that source files are parsed and handled consistently.
That said will consider moving stand-alone generators into the MAVLink project under the same conditions as for new mavgen generator code (see section above).
Primarily this means that the team developing the generator must provide sufficient validation that the generator works and commitment to support it.
## How to Open a Pull Request
1. First [fork and clone](https://help.github.com/articles/fork-a-repo) the project project.
1. First [fork and clone](https://help.github.com/articles/fork-a-repo) the project.
2. Create a feature branch off master
ko/file_formats/index.md
+1 -1
View File
@@ -16,7 +16,7 @@ _QGroundControl_ and many other GCS support an older plain-text format for missi
This is not officially part of MAVLink and does not allow rally point or geofence information to be provided.
The format is shown below.
The first line contains the file format and version information, while subsequent the line(s) are mission items.
The first line contains the file format and version information, while subsequent line(s) are mission items.
```
QGC WPL <VERSION>
ko/getting_started/generate_libraries.md
+2 -2
View File
@@ -20,7 +20,7 @@ For more information see [Supported Languages](../index.md#supported_languages).
## Pre-requisites
1. You must already have [Installed the MAVLink toolchain](../getting_started/installation.md), which includes the mavgenerate and mavgen tools used below as well as the [XML Message Definitions](../messages/index.md).
2. If you are generating messages for a [custom dialect](../messages/index.md#dialects), copy the dialect [XML definition file(s)](../messages/index.md#xml-definition-files--dialects) into the directory [message_definitions/v1.0/](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0).
2. If you are generating messages for a [custom dialect](../messages/dialects.md), copy the dialect [XML definition file(s)](../messages/index.md#xml-definition-files--dialects) into the directory [message_definitions/v1.0/](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0).
::: info
_mavgen_ can handle dialects that have relative paths for included XML files (e.g typically [common.xml](../messages/common.md)), but other generators may not.
@@ -90,7 +90,7 @@ python3 -m pymavlink.tools.mavgen --lang=C --wire-protocol=2.0 --output=generate
```
:::info
The syntax for for generating Python modules is the same, except that the `--output` specifies a _filename_ rather than a directory.
The syntax for generating Python modules is the same, except that the `--output` specifies a _filename_ rather than a directory.
:::
<!-- https://github.com/ArduPilot/pymavlink/issues/203 -->
ko/getting_started/installation.md
+4 -4
View File
@@ -1,6 +1,6 @@
# Installing MAVLink Toolchain
This topic explains how to install the [MAVLink toolchain](https://github.com/mavlink/mavlink). The toolchain includes the [XML message definitions](../messages/index.md) as well as the the GUI/command line tools that use the definitions to [Generate MAVLink Source Files](../getting_started/generate_libraries.md).
This topic explains how to install the [MAVLink toolchain](https://github.com/mavlink/mavlink). The toolchain includes the [XML message definitions](../messages/index.md) as well as the GUI/command line tools that use the definitions to [Generate MAVLink Source Files](../getting_started/generate_libraries.md).
:::tip
You do not need to install or generate the source files if you are using the C programming language and a standard [dialect](../messages/index.md#dialects).
@@ -25,9 +25,9 @@ To install the MAVLink toolchain:
- **Windows:** Download from [Python for Windows](https://www.python.org/downloads/)
- **Ubuntu Linux** Make sure Python and Pip are both installed:
```
sudo apt install python3-tk
```
```
sudo apt install python3-tk
```
2. Clone the official [mavlink repo](https://github.com/mavlink/mavlink) or your fork with your custom dialect:
ko/guide/crc.md
+1 -1
View File
@@ -4,7 +4,7 @@ MAVLink services that need to use a Cyclic Redundancy Check (CRC) should choose
:::info
Using the same CRC implementation for all cases means that only one implementation is required.
Do not introduce another unless there without a compelling technical reason.
Do not introduce another unless there is a compelling technical reason.
:::
:::info
ko/guide/define_xml_element.md
+33 -33
View File
@@ -93,48 +93,48 @@ To create a new dialect file:
3. Copy the following text into the new file.
```xml
<?xml version="1.0"?>
<mavlink>
```xml
<?xml version="1.0"?>
<mavlink>
<include>common.xml</include>
<!-- <version>9</version> -->
<dialect>8</dialect>
<include>common.xml</include>
<!-- <version>9</version> -->
<dialect>8</dialect>
<enums>
<!-- Enums are defined here (optional) -->
</enums>
<enums>
<!-- Enums are defined here (optional) -->
</enums>
<messages>
<!-- Messages are defined here (optional) -->
</messages>
<messages>
<!-- Messages are defined here (optional) -->
</messages>
</mavlink>
```
</mavlink>
```
The template assumes that your dialect:
The template assumes that your dialect:
- imports **common.xml** (`<include>common.xml</include>`)
- takes its version from **common.xml** (which is why the `version` tags are commented out).
- imports **common.xml** (`<include>common.xml</include>`)
- takes its version from **common.xml** (which is why the `version` tags are commented out).
4. Update the `include`(s):
- if the dialect is not based on **common.xml** remove the existing `include` line
- Add additional `<include> </include>` elements to import additional files/dialects.
- if the dialect is not based on **common.xml** remove the existing `include` line
- Add additional `<include> </include>` elements to import additional files/dialects.
::: info
Includes in nested files are ignored.
:::
::: info
Includes in nested files are ignored.
:::
5. Update the `version`:
- Most dialects should leave the version commented out (i.e. all dialects that include **common.xml**).
- Dialects that are _not_ based on **common.xml** can uncomment the `<version>6</version>` line and use whatever version is desired.
- Most dialects should leave the version commented out (i.e. all dialects that include **common.xml**).
- Dialects that are _not_ based on **common.xml** can uncomment the `<version>6</version>` line and use whatever version is desired.
::: info
The `version` specified in the top level file is used by default, if present.
If it is not present in the file, then a `version` from an included file is used.
:::
::: info
The `version` specified in the top level file is used by default, if present.
If it is not present in the file, then a `version` from an included file is used.
:::
6. Update the `<dialect>8</dialect>` line to replace `8` with the next-largest unused dialect number (based on the other files in the folder).
@@ -176,7 +176,7 @@ Messages must be declared between the `<messages></messages>` tags in either **c
Each message is defined using `<message id="" name="LIBRARY_UNIQUE_NAME"> ... </message>` tags (with unique `id` and `name` attributes).
:::tip
The only only difference between messages defined in **common.xml** or _dialect_ files is they they must use different `id` ranges in order to ensure that the `ids` are unique. See [Message Id Ranges](#message_id_ranges) for more information.
The only difference between messages defined in **common.xml** or _dialect_ files is they they must use different `id` ranges in order to ensure that the `ids` are unique. See [Message Id Ranges](#message_id_ranges) for more information.
:::
The main rules for messages are:
@@ -255,7 +255,7 @@ For a message in **common.xml** either change requires the agreement of major st
- Create a PR and discuss in the MAVLink developer meeting.
::: tip
Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
Before proposing changes to **common.xml** check the codebase of major stakeholders to confirm impact.
:::
It is possible to change the message and field descriptions without breaking binary compatibility.
@@ -413,7 +413,7 @@ If an enum needs to be changed then there are several options:
For either case, all users of the enum will need to be updated with new generated libraries.
:::tip
Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
Before proposing changes to **common.xml** check the codebase of major stakeholders to confirm impact.
:::
For an enum in **common.xml** either change requires the agreement of major stakeholders
@@ -480,7 +480,7 @@ If you are creating a new public dialect, [create an issue](https://github.com/m
:::
There are a number of common and ArduPilot commands that are outside the ranges (e.g. 16, 200, etc.).
Generally you would only use these these ranges in order to give a new command an id that is close to related to that of related commands.
Generally you would only use these ranges in order to give a new command an id that is close to related to that of related commands.
This can be done provided that the command id value is not used by any other XML file in the _mavlink/mavlink_ repo.
### Entry Names {#command_names}
@@ -531,7 +531,7 @@ If the param is reused the original default value must still mean "no action", s
:::info
Unfortunately this means that a reserved `param` must have its default value decided when the command is declared!
The default value cannot later be changed from `NaN` to `0` (or visa versa) without potential compatibility issues.
The default value cannot later be changed from `NaN` to `0` (or vice versa) without potential compatibility issues.
:::
To declare a `param` as `reserved` with `default` value of `NaN` you should use the following syntax.
ko/guide/mavlink_2.md
+1 -1
View File
@@ -13,7 +13,7 @@ The key new features of _MAVLink 2_ are:
- [Packet signing](../guide/message_signing.md) - Authenticate that messages were sent by trusted systems.
- [Message extensions](../guide/define_xml_element.md#message_extensions) - Add new fields to existing MAVLink message definitions without breaking binary compatibility for receivers that have not updated.
- [Empty-byte payload truncation](../guide/serialization.md#payload_truncation) - Empty (zero-filled) bytes at the end of the serialized payload must be removed before sending (All bytes were sent in _MAVLink 1_, regardless of content).
- [Compatibility Flags](../guide/serialization.md#compat_flags)/[Incompatibility Flags](../guide/serialization.md#incompat_flags) - Allow for backwards compatible evolution of the protocol by indicating frames that must be handled in a special/non-standard way (packets with compatibility flags can still be handled in the standard way, while packets with incompatibility flags must be dropped if the flage is not supported).
- [Compatibility Flags](../guide/serialization.md#compat_flags)/[Incompatibility Flags](../guide/serialization.md#incompat_flags) - Allow for backwards compatible evolution of the protocol by indicating frames that must be handled in a special/non-standard way (packets with compatibility flags can still be handled in the standard way, while packets with incompatibility flags must be dropped if the flag is not supported).
:::tip
The _MAVLink 2_ [design document](https://docs.google.com/document/d/1XtbD0ORNkhZ8eKrsbSIZNLyg9sFRXMXbsR2mp37KbIg/edit?usp=sharing) provides additional background information about the changes.
ko/guide/mavlink_version.md
+2 -2
View File
@@ -10,7 +10,7 @@ The _MAVLink 2.0_ C/C++ and Python libraries are backwards compatible with MAVLi
:::info
_MAVLink v0.9_ is a pre-release version that is no longer supported.
The associated message set deleted in August 2018.
The associated message set was deleted in August 2018.
Legacy code may be present in generator and test code.
:::
@@ -51,7 +51,7 @@ This is reasonable because the majority of systems and communication links now r
Most flight stacks assume communication links are transparent.
Possible causes of links not being transparent are:
- Routing, which can can change or reserialize MAVLink packets (for example, there might be an intermediate router that converts between versions).
- Routing, which can change or reserialize MAVLink packets (for example, there might be an intermediate router that converts between versions).
- Wireless links that rely on fixed length packetization may distort or truncate variable-length MAVLink 2 frames.
For example, older SiK Radios may consume MAVLink 2 messages.
ko/guide/message_signing.md
+10 -10
View File
@@ -14,24 +14,24 @@ More detailed information for developers using existing MAVLink libraries can be
## Frame Format
For a signed packet the **0x01** bit of the [incompatibility flag field](../guide/mavlink_2.md#incompat_flags) is set true and an additional 13 bytes of "signature" data appended to the packet.
For a signed packet the **0x01** bit of the [incompatibility flag field](../guide/serialization.md#incompat_flags) is set true and an additional 13 bytes of "signature" data appended to the packet.
The signed packet format is shown below.
![MAVLink 2 Signed](../../assets/packets/packet_mavlink_v2_signing.png)
:::info
The [incompatibility flags](../guide/mavlink_2.md#incompat_flags) in the packet header are used to indicate that the MAVLink library must reject the packet if it does not understand or cannot handle the flag.
The [incompatibility flags](../guide/serialization.md#incompat_flags) in the packet header are used to indicate that the MAVLink library must reject the packet if it does not understand or cannot handle the flag.
In other words, a MAVLink library that does not support signing must drop signed packets.
The C library uses [MAVLINK_IFLAG_SIGNED](../guide/mavlink_2.md#MAVLINK_IFLAG_SIGNED) to represent the "supports message signing" bit.
The C library uses [MAVLINK_IFLAG_SIGNED](../guide/serialization.md#MAVLINK_IFLAG_SIGNED) to represent the "supports message signing" bit.
:::
The 13 bytes of the signature are:
| Data | Description |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [linkID](#link_ids) (8&amp;nbsp;bits) | ID of link on which packet is sent. Normally this is the same as the _channel_. |
| [timestamp](#timestamps) (48 bits) | Timestamp in 10 microsecond units since 1st January 2015 GMT time. This _must_ monotonically increase for every message on a particular [link](#link_ids). Note that means the timestamp may get ahead of the actual time if the packet rate averages more than 100,000 packets per second. |
| [signature](#signature) (48 bits) | A 48 bit signature for the packet, based on the complete packet, timestamp, and secret key. |
| Data | Description |
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [linkID](#link_ids) (8&nbsp;bits) | ID of link on which packet is sent. Normally this is the same as the _channel_. |
| [timestamp](#timestamp) (48 bits) | Timestamp in 10 microsecond units since 1st January 2015 GMT time. This _must_ monotonically increase for every message on a particular [link](#link_ids). Note that means the timestamp may get ahead of the actual time if the packet rate averages more than 100,000 packets per second. |
| [signature](#signature) (48 bits) | A 48 bit signature for the packet, based on the complete packet, timestamp, and secret key. |
See below for more information about the fields.
@@ -160,7 +160,7 @@ The secret key may be shared to other devices using the [SETUP_SIGNING](../messa
The message should only ever be sent over a secure link (e.g. USB or wired Ethernet) as a direct message to each connected `system_id`/`component_id`.
The receiving system must be set up to process the message and store the received secret key to the appropriate permanent storage.
The same secure method can be used to both _set_ and _reset_ a system's key (reseting a key does not have to be "more secure" than setting it in the first place).
The same secure method can be used to both _set_ and _reset_ a system's key (resetting a key does not have to be "more secure" than setting it in the first place).
The `SETUP_SIGNING` message should never be broadcast, and received `SETUP_SIGNING` messages must never be automatically forwarded to other active MAVLink devices/streams/channels.
This is to avoid the case where a key received over a secure link (e.g. USB) is automatically forwarded to another system over an insecure link (e.g. Wifi).
@@ -176,7 +176,7 @@ The receiving system may be configured to ignore message signatures on the secur
In order to avoid leaking the secret key used for signing, systems should omit [SETUP_SIGNING](../messages/common.md#SETUP_SIGNING) messages from logs (or replace the secret with 32 0xFF bytes in the logged message).
Similarly, signed packets should have the signature [incompatibility bit](../guide/mavlink_2.md#incompat_flags) cleared and the signature block removed before being put into telemetry log files.
Similarly, signed packets should have the signature [incompatibility bit](../guide/serialization.md#incompat_flags) cleared and the signature block removed before being put into telemetry log files.
This makes it harder for potential attacker to collect large amounts of signature data with which to attack the system.
## Further Information
ko/guide/packet_loss.md
+1 -1
View File
@@ -1,7 +1,7 @@
# Packet Loss Calculation
MAVLink packet loss is calculated from the packet sequence number, an 8 bit field that is incremented each time a message is emitted on a channel.
The recipient of the message can track the last recieved/next expected sequence number, and if a packet sequence number is bigger than expected, any intermediate packets between the sequence numbers are assumed to have been lost.
The recipient of the message can track the last received/next expected sequence number, and if a packet sequence number is bigger than expected, any intermediate packets between the sequence numbers are assumed to have been lost.
The sequence number will wrap around at 255, and the recipient is expected to compensate for this.
This approach works if all messages sent on a channel are routed to the system calculating packet loss, and if messages from only one channel are received by the system calculating packet loss.
ko/guide/serialization.md
+11 -11
View File
@@ -1,6 +1,6 @@
# Packet Serialization
This topic provides detailed information about about MAVLink packet serialization, including the over-the-wire formats for MAVLink v1 and v2 packets, the ordering of fields in the message payload, and the `CRC_EXTRA` used for ensuring that the sender and reciever share a compatible message definition.
This topic provides detailed information about MAVLink packet serialization, including the over-the-wire formats for MAVLink v1 and v2 packets, the ordering of fields in the message payload, and the `CRC_EXTRA` used for ensuring that the sender and receiver share a compatible message definition.
It is primarily intended for developers who are creating/maintaining a MAVLink generator
@@ -43,16 +43,16 @@ Below is the over-the-wire format for a MAVLink 1 packet (the in-memory represen
![MAVLink v1 packet](../../assets/packets/packet_mavlink_v1.jpg)
| Byte Index | C version | Content | Value | Explanation |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | `uint8_t magic` | Packet start marker | 0xFE | Protocol-specific start-of-text (STX) marker used to indicate the beginning of a new packet. Any system that does not understand protocol version will skip the packet. |
| 1 | `uint8_t len` | Payload length | 0&amp;nbsp;-&amp;nbsp;255 | Indicates length of the following `payload` section (fixed for a particular message). |
| 2 | `uint8_t seq` | Packet sequence number | 0 - 255 | Used to detect packet loss. Components increment value for each message sent. |
| 3 | `uint8_t sysid` | System ID | 1 - 255 | ID of _system_ (vehicle) sending the message. Used to differentiate systems on network. Note that the broadcast address 0 may not be used in this field as it is an invalid _source_ address. |
| 4 | `uint8_t compid` | Component ID | 1 - 255 | ID of _component_ sending the message. Used to differentiate components in a _system_ (e.g. autopilot and a camera). Use appropriate values in [MAV_COMPONENT](../messages/common.md#MAV_COMPONENT). Note that the broadcast address `MAV_COMP_ID_ALL` may not be used in this field as it is an invalid _source_ address. |
| <a id="v1_msgid"></a>5 | `uint8_t msgid` | Message ID | 0 - 255 | ID of _message type_ in payload. Used to decode data back into message object. |
| <a id="v1_payload"></a>For _n_-byte payload:<br>`n=0`: NA, `n=1`: 6, `n>=2`: 6 to (5+n) | `uint8_t payload[max 255]` | Payload data | | Message data. Content depends on message type (i.e. Message ID). |
| (n+6) to (n+7) | `uint16_t checksum` | [Checksum](#checksum) (low byte, high byte) | | CRC-16/MCRF4XX for message (excluding `magic` byte). Includes [CRC_EXTRA](#crc_extra) byte. |
| Byte Index | C version | Content | Value | Explanation |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | -------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | `uint8_t magic` | Packet start marker | 0xFE | Protocol-specific start-of-text (STX) marker used to indicate the beginning of a new packet. Any system that does not understand protocol version will skip the packet. |
| 1 | `uint8_t len` | Payload length | 0&nbsp;-&nbsp;255 | Indicates length of the following `payload` section (fixed for a particular message). |
| 2 | `uint8_t seq` | Packet sequence number | 0 - 255 | Used to detect packet loss. Components increment value for each message sent. |
| 3 | `uint8_t sysid` | System ID | 1 - 255 | ID of _system_ (vehicle) sending the message. Used to differentiate systems on network. Note that the broadcast address 0 may not be used in this field as it is an invalid _source_ address. |
| 4 | `uint8_t compid` | Component ID | 1 - 255 | ID of _component_ sending the message. Used to differentiate components in a _system_ (e.g. autopilot and a camera). Use appropriate values in [MAV_COMPONENT](../messages/common.md#MAV_COMPONENT). Note that the broadcast address `MAV_COMP_ID_ALL` may not be used in this field as it is an invalid _source_ address. |
| <a id="v1_msgid"></a>5 | `uint8_t msgid` | Message ID | 0 - 255 | ID of _message type_ in payload. Used to decode data back into message object. |
| <a id="v1_payload"></a>For _n_-byte payload:<br>`n=0`: NA, `n=1`: 6, `n>=2`: 6 to (5+n) | `uint8_t payload[max 255]` | Payload data | | Message data. Content depends on message type (i.e. Message ID). |
| (n+6) to (n+7) | `uint16_t checksum` | [Checksum](#checksum) (low byte, high byte) | | CRC-16/MCRF4XX for message (excluding `magic` byte). Includes [CRC_EXTRA](#crc_extra) byte. |
- The minimum packet length is 8 bytes for acknowledgment packets without payload.
- The maximum packet length is 263 bytes for full payload.
ko/guide/wireshark.md
+3 -3
View File
@@ -7,7 +7,7 @@ The benefits of using _Wireshark_ over other alternatives are:
- it can view _all_ traffic on a network interface (GCS tools like [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/analyze_view/mavlink_inspector.html) often only analyse incoming traffic).
- you can use it to analyse traffic logged on a companion computer (this allows analysis of traffic between the companion computer and flight controller, which might otherwise not be visible to _Wireshark_).
- it is easy to update for new custom messages and dialects.
Rebuilding _QGroundControl_ so you can use it analyse custom messages is much harder!
Rebuilding _QGroundControl_ so you can use it to analyse custom messages is much harder!
This topic shows how to generate a Wireshark plugin for a particular dialect file and install it on Wireshark, and how to perform basic filtering.
It also provides an overview of how you can use _tcpdump_ for collecting traffic on a linux computer (for later analysis).
@@ -24,7 +24,7 @@ The MAVLink generator (**mavgen**) can build this plugin for a dialect in the sa
The steps are:
1. [Install MAVLink](../getting_started/installation.md) (if you have not already done so).
2. Build libraries for your target dialect, specifing `WLua` as the target language.
2. Build libraries for your target dialect, specifying `WLua` as the target language.
This process is described in the topic [Generate MAVLink Libraries](../getting_started/generate_libraries.md).
For example, to build the MAVLink 2 Wireshark plugin for [common.xml](../messages/common.md) you might use the following command:
@@ -57,7 +57,7 @@ This might be necessary, for example, in order to monitor traffic recorded on th
To import the plugin into _Wireshark_:
1. Copy the plugin file into the wireshare plugins directory.
1. Copy the plugin file into the wireshark plugins directory.
- On Linux systems this might be: `~/.local/lib/wireshark/plugins` (or `~/.wireshark/plugins` for older versions of Wireshark).
Note that users will need to be added to the `wireshark` group to use the tool.)
- On Windows this might be: `Program Files/Wireshark/plugins`.
ko/guide/xml_schema.md
+15 -9
View File
@@ -103,7 +103,7 @@ The values are defined in nested [`<entry>`](#entry) elements.
Attributes:
- `name` (required): The name of the enum. This is a string of capitalized, underscore-separated words.
- `bitmask` (optional): Set to `true` for enums that defines entries with values that increase by a power of 2, such as flags.
- `bitmask` (optional): Set to `true` for enums that define entries with values that increase by a power of 2, such as flags.
Nested elements:
@@ -292,7 +292,13 @@ Nested elements:
The field value is its name/text string used in GUI documentation (but not sent over the wire).
Every message must have at least one field.
- `<extensions />` (optional): This self-closing tag is used to indicate that subsequent fields apply to MAVLink 2 only.
- The tag should be used for MAVLink 1 messages only (id < 256) that have been extended in MAVLink 2.
### `<extensions />` element {#extensions}
A self-closing tag that indicates that subsequent fields apply to MAVLink 2 only.
This should only be used if a message needs new fields after it is already published.
New messages are preferred as extensions are not part of the CRC check, and can hence lead to undetectable incompatibilities.
### `<field>` element {#field}
@@ -303,7 +309,7 @@ The field inner content text string is used in GUI documentation (but not sent o
Attributes:
- `type`: Similar to a field in a C `struct` - the size of the data required to store/represent the data type.
- Fields can be signed/unsigned integers of size 8, 16, 23, 64 bits (`{u)int8_t`, `(u)int16_t`, `(u)int32_t`, `(u)int64_t`), single/double precision IEEE754 floating point numbers.
- Fields can be signed/unsigned integers of size 8, 16, 32, 64 bits (`{u)int8_t`, `(u)int16_t`, `(u)int32_t`, `(u)int64_t`), single/double precision IEEE754 floating point numbers.
They can also be arrays of the other types - e.g. `uint16_t[10]`.
- `name`: Name of the field (used in code).
@@ -331,13 +337,13 @@ Attributes:
- `instance`: If `true`, this indicates that the message contains the information for a particular sensor or battery (e.g. Battery 1, Battery 2, etc.) and that this field indicates which sensor. Default is `false`.
::: info
This field allows a recipient automatically associate messages for a particular sensor and plot them in the same series.
This field allows a recipient to automatically associate messages for a particular sensor and plot them in the same series.
:::
- `invalid`: Specifies a value that can be set on a field to indicate that the data is _invalid_: the recipient should ignore the field if it has this value.
For example, `BATTERY_STATUS.current_battery` specifies `invalid="-1"`, so a battery that does not measure supplied _current_ should set `BATTERY_STATUS.current_battery` to `-1`.
Where possible the value that indicates the field is invalid should be selected to outside the expected/valid range of the eld (`0` is preferred if it is not an acceptable value for the field).
Where possible the value that indicates the field is invalid should be selected to outside the expected/valid range of the field (`0` is preferred if it is not an acceptable value for the field).
For integers we usually select the largest possible value (i.e. `UINT16_MAX`, `INT16_MAX`, `UINT8_MAX`, `UINT8_MAX`).
For floats we usually select `invalid="NaN"`.
@@ -371,7 +377,7 @@ They should not be included in release builds.
The generator toolchain can be configured to conditionally build messages omitting the `<wip>` entries.
Generally new elements should be defined in `development.xml`, and any definitions in that file are considered WIP by default.
The `wip` element is intended primiarly for indicating WIP additions to `common.xml` that for whatever reason could not be added to `development.xml`.
The `wip` element is intended primarily for indicating WIP additions to `common.xml` that for whatever reason could not be added to `development.xml`.
Once the associated definition has been tested, it may be accepted into `common.xml` and the `<wip>` tag removed.
@@ -386,7 +392,7 @@ Attributes:
- `since` (optional): A datestamp indicating when the corresponding element was proposed.
This should be formatted as such as `YYYYMM`
This hints to the maintainter team when WIP elements should be reviewed for addition or removal.
This hints to the maintainer team when WIP elements should be reviewed for addition or removal.
Nested elements
@@ -409,7 +415,7 @@ Attributes:
- `since` (required): A datestamp indicating when the new element was accepted into files managed by the MAVLink team.
This should be formatted as such as `YYYY-MM`.
- `replaced_by` (required): The name of the definition that supersedes this elements.
- `replaced_by` (required): The name of the definition that supersedes this element.
Nested elements
@@ -418,7 +424,7 @@ Nested elements
### `<deprecated>` element {#deprecated}
The `<deprecated>` element is used to indicate when an element should not be used because it is on the path for removal from the standard.
Often by the time and element is deprecated it has already been removed from current releases of the main flight stacks.
Often by the time an element is deprecated it has already been removed from current releases of the main flight stacks.
The attributes indicates the time of deprecation and the replacement element, and may also include the intended date of removal.
The content of the element may (optionally) contain a string with additional information about the planned removal and alternative definitions.
ko/index.md
+1 -1
View File
@@ -24,7 +24,7 @@ MAVLink는 2009년 초반 Lorenz Meier가 처음으로 출시했으며, 현재
## Language/Generator List {#supported_languages}
The sections below lists MAVLink generators and their associated programming languages.
The sections below list MAVLink generators and their associated programming languages.
### MAVLink Project Generators/Languages
ko/mavgen_c/index.md
+1 -1
View File
@@ -85,7 +85,7 @@ mavlink/common/../mavlink_helpers.h:86:24: warning: taking address of packed mem
```
The warning indicates the potential for hard faults caused by unaligned access to packed data.
This does not happen on most of the common architectures on which MAVLink is run, and generally the warning can be supressed.
This does not happen on most of the common architectures on which MAVLink is run, and generally the warning can be suppressed.
You can suppress the warnings using `-Wno-address-of-packed-member`.
ko/mavgen_python/howto_requestmessages.md
+1 -1
View File
@@ -7,7 +7,7 @@ A system can request that additional messages are sent as a stream, or change th
A single instance of a message can be requested by sending [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE).
The example below shows how you can request the [BATTERY_STATUS](../messages/common.md#BATTERY_STATUS) message is streamed at the rate of 1Hz, by sending `MAV_CMD_SET_MESSAGE_INTERVAL` in a [COMMAND_LONG](../messages/common.md#COMMAND_LONG).
Because this is a command, we then wait for a `COMMAND_ACK` to be recieved with the matching command id, and then display the result.
Because this is a command, we then wait for a `COMMAND_ACK` to be received with the matching command id, and then display the result.
Note that you could equally well send the command in a [COMMAND_INT](../messages/common.md#COMMAND_INT), if supported by the flight stack.
```python
ko/messages/common.md
+8 -7
View File
@@ -3875,6 +3875,7 @@ Predefined OR-combined [MAV_MODE_FLAG](#MAV_MODE_FLAG) values. These can simplif
| Value | Name | Description |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| <a id='MAV_SYS_STATUS_RECOVERY_SYSTEM'></a>1 | [MAV_SYS_STATUS_RECOVERY_SYSTEM](#MAV_SYS_STATUS_RECOVERY_SYSTEM) | 0x01 Recovery system (parachute, balloon, retracts etc) |
| <a id='MAV_SYS_STATUS_SENSOR_LEAK'></a>2 | [MAV_SYS_STATUS_SENSOR_LEAK](#MAV_SYS_STATUS_SENSOR_LEAK) | 0x02 Leak detection |
### MAV_FRAME {#MAV_FRAME}
@@ -4323,13 +4324,13 @@ Note that at least one flag must be set in [MAV_CMD_DO_AUTOTUNE_ENABLE](#MAV_CMD
Actions for reading/writing parameters between persistent and volatile storage when using [MAV_CMD_PREFLIGHT_STORAGE](#MAV_CMD_PREFLIGHT_STORAGE).
(Commonly parameters are loaded from persistent storage (flash/EEPROM) into volatile storage (RAM) on startup and written back when they are changed.)
| Value | Name | Description |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id='PARAM_READ_PERSISTENT'></a>0 | [PARAM_READ_PERSISTENT](#PARAM_READ_PERSISTENT) | Read all parameters from persistent storage. Replaces values in volatile storage. |
| <a id='PARAM_WRITE_PERSISTENT'></a>1 | [PARAM_WRITE_PERSISTENT](#PARAM_WRITE_PERSISTENT) | Write all parameter values to persistent storage (flash/EEPROM) |
| <a id='PARAM_RESET_CONFIG_DEFAULT'></a>2 | [PARAM_RESET_CONFIG_DEFAULT](#PARAM_RESET_CONFIG_DEFAULT) | Reset all user configurable parameters to their default value (including airframe selection, sensor calibration data, safety settings, and so on). Does not reset values that contain operation counters and vehicle computed statistics. |
| <a id='PARAM_RESET_SENSOR_DEFAULT'></a>3 | [PARAM_RESET_SENSOR_DEFAULT](#PARAM_RESET_SENSOR_DEFAULT) | Reset only sensor calibration parameters to factory defaults (or firmware default if not available) |
| <a id='PARAM_RESET_ALL_DEFAULT'></a>4 | [PARAM_RESET_ALL_DEFAULT](#PARAM_RESET_ALL_DEFAULT) | Reset all parameters, including operation counters, to default values |
| Value | Name | Description |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id='PARAM_READ_PERSISTENT'></a>0 | [PARAM_READ_PERSISTENT](#PARAM_READ_PERSISTENT) | Read all parameters from persistent storage. Replaces values in volatile storage. |
| <a id='PARAM_WRITE_PERSISTENT'></a>1 | [PARAM_WRITE_PERSISTENT](#PARAM_WRITE_PERSISTENT) | Write all parameter values to persistent storage (flash/EEPROM) |
| <a id='PARAM_RESET_FACTORY_DEFAULT'></a>2 | [PARAM_RESET_FACTORY_DEFAULT](#PARAM_RESET_FACTORY_DEFAULT) | Reset parameters to default values (such as sensor calibration, safety settings, and so on). Note that a flight stack may choose not to reset some parameters at their own discretion (such as those that are locked or expected to persist for the vehicle lifetime). |
| <a id='PARAM_RESET_SENSOR_DEFAULT'></a>3 | [PARAM_RESET_SENSOR_DEFAULT](#PARAM_RESET_SENSOR_DEFAULT) | Reset only sensor calibration parameters to factory defaults (or firmware default if not available) |
| <a id='PARAM_RESET_ALL_DEFAULT'></a>4 | [PARAM_RESET_ALL_DEFAULT](#PARAM_RESET_ALL_DEFAULT) | Reset all parameters to default values. |
### PREFLIGHT_STORAGE_MISSION_ACTION {#PREFLIGHT_STORAGE_MISSION_ACTION}
ko/services/arm_authorization.md
+2 -2
View File
@@ -1,6 +1,6 @@
# Arm Authorization
When enabled by setting a parameter on flight stack, the drone will only arm the motors if authorized by a external entity.
When enabled by setting a parameter on the flight stack, the drone will only arm the motors if authorized by a external entity.
This external entity is responsible for requesting any information that it needs from the drone and from other sources (example: weather) and whether (or not) to authorize the arming procedure.
This is required to comply with [NASA UTM](https://utm.arc.nasa.gov/), but may also be useful for private companies.
@@ -25,7 +25,7 @@ sequenceDiagram;
Drone->>Remote control/QCS: QCS COMMAND_ACK command=MAV_CMD_COMPONENT_ARM_DISARM result=ACCEPTED, TEMPORARILY_REJECTED or DENIED
-->
In case the authorizer need a lot of time to get and process the information is better have another authorization flow to avoid arm the drone at unexpected time.
In case the authorizer needs a lot of time to get and process the information is better have another authorization flow to avoid arm the drone at unexpected time.
[![Mermaid Sequence: Arm authorisation 2](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMVxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgcmVzdWx0PVRFTVBPUkFSSUxZX1JFSkVDVEVEXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBTVEFUVVNURVhUIHRleHQ9QXJtIGF1dGhvcml6YXRpb24gd2FzIGFwcHJvdmVkIG9yIGRlbmllZFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMlxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgY29tbWFuZD1NQVZfQ01EX0NPTVBPTkVOVF9BUk1fRElTQVJNIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEIiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMVxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgcmVzdWx0PVRFTVBPUkFSSUxZX1JFSkVDVEVEXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBTVEFUVVNURVhUIHRleHQ9QXJtIGF1dGhvcml6YXRpb24gd2FzIGFwcHJvdmVkIG9yIGRlbmllZFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMlxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgY29tbWFuZD1NQVZfQ01EX0NPTVBPTkVOVF9BUk1fRElTQVJNIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEIiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)
ko/services/battery.md
+1 -1
View File
@@ -8,7 +8,7 @@ MAVLink provides a number of messages for providing battery information:
- Some batteries may provide [fault](#MAV_BATTERY_FAULT) and [mode](#MAV_BATTERY_MODE) information in this message.
::: info
`BATTERY_STATUS` is expected to be superseded by [BATTERY_STATUS_V2](../messages/development.html#BATTERY_STATUS_V2).
`BATTERY_STATUS` is expected to be superseded by [BATTERY_STATUS_V2](../messages/development.md#BATTERY_STATUS_V2).
For more information see [RFC 0018 - Improved Battery Status Reporting](https://github.com/mavlink/rfcs/pull/19).
:::
ko/services/camera_v1.md
+2 -2
View File
@@ -12,7 +12,7 @@ The protocol can be used to control cameras attached to autopilot outputs or sta
## Standalone MAVLink cameras
A standalone MAVLink camera that needs to interact with a ground station must be able to send and recieve MAVLink messages from the ground station.
A standalone MAVLink camera that needs to interact with a ground station must be able to send and receive MAVLink messages from the ground station.
If the GCS and Camera are connected to the flight stack on different MAVLink channels then the flight stack will need to forward messages between them.
If the MAVLink camera does not emit the [CAMERA_TRIGGER](#CAMERA_TRIGGER) message on image capture then the flight stack may need to do this on its behalf.
@@ -31,7 +31,7 @@ A GCS should address the commands to the autopilot component, which will need to
The flight stack will also need to trigger the camera when the commands are found in a mission.
Note that a flight stack implementation can generally trigger attached cameras and emit a MAVLink command in missions.
If a connected camera and MAVLink camera are connected, both with be triggered.
If a connected camera and MAVLink camera are connected, both will be triggered.
## Message/Command Summary
ko/services/command.md
+5 -5
View File
@@ -13,7 +13,7 @@ If no acknowledgement is received the command must be automatically re-sent.
| Message | Description |
| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="COMMAND_INT"></a>[COMMAND_INT](../messages/common.md#COMMAND_INT) | Message for encoding a command ([MAV_CMD](#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). |
| <a id="COMMAND_LONG"></a>[COMMAND_LONG](../messages/common.md#COMMAND_LONG) | Message for encoding a command ([MAV_CMD](#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). |
| <a id="COMMAND_LONG"></a>[COMMAND_LONG](../messages/common.md#COMMAND_LONG) | Message for encoding a command ([MAV_CMD](#MAV_CMD)). The message 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). |
| <a id="COMMAND_ACK"></a>[COMMAND_ACK](../messages/common.md#COMMAND_ACK) | Command acknowledgement. Includes result (success, failure, still in progress) and may include progress information and additional detail about failure reasons. |
| <a id="COMMAND_CANCEL"></a>[COMMAND_CANCEL](../messages/common.md#COMMAND_CANCEL) | Cancel a long running command. |
@@ -85,8 +85,8 @@ sequenceDiagram;
### Long Running Commands {#long_running_commands}
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](../messages/common.md#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](#MAV_RESULT) of the operation: `MAV_RESULT_ACCEPTED`, `MAV_RESULT_FAILED`, `MAV_RESULT_CANCELLED`).
The drone reports its progress by sending `COMMAND_ACK` messages with [COMMAND_ACK.result=MAV_RESULT_IN_PROGRESS](../messages/common.md#MAV_RESULT_IN_PROGRESS) and the progress as a percentage in `COMMAND_ACK.progress` ([0-100] percent complete, 255 if progress not supplied).
When the operation completes, the drone must terminate with a `COMMAND_ACK` containing the final [result](#MAV_RESULT) of the operation: `MAV_RESULT_ACCEPTED`, `MAV_RESULT_FAILED`, `MAV_RESULT_CANCELLED`).
[![Mermaid Sequence: MAV_RESULT_IN_PROGRESS](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6IENPTU1BTkRfTE9ORygpXG4gICAgR0NTLT4-R0NTOiBTdGFydCB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgTm90ZSByaWdodCBvZiBHQ1M6IC4uLlxuICAgIERyb25lLT4-R0NTOiBDT01NQU5EX0FDSyhyZXN1bHQ9TUFWX1JFU1VMVF9BQ0NFUFRFRCkiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6IENPTU1BTkRfTE9ORygpXG4gICAgR0NTLT4-R0NTOiBTdGFydCB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgTm90ZSByaWdodCBvZiBHQ1M6IC4uLlxuICAgIERyb25lLT4-R0NTOiBDT01NQU5EX0FDSyhyZXN1bHQ9TUFWX1JFU1VMVF9BQ0NFUFRFRCkiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)
@@ -116,9 +116,9 @@ Generally though, the GCS should have a much increased timeout after receiving a
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).
If the same command is received 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.
The protocol allows for _different_ long running commands to run in parallel, if supported by the state machine of the receiving 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](#COMMAND_CANCEL), which might be used to cancel the first request).
## Location Commands and Frame Types
ko/services/component_metadata.md
+3 -3
View File
@@ -30,7 +30,7 @@ There is no mechanism, for example, to provide an update if the set of supported
| <a id="COMP_METADATA_TYPE"></a>[COMP_METADATA_TYPE](../messages/common.md#COMP_METADATA_TYPE) | Types of component metadata supported by the protocol - e.g. general information, parameter metadata, supported commands, events, peripherals, etc. The type identifiers are used in the "general" metadata file to identify the sections that provide information about each supported type of metadata. |
:::info
[COMPONENT_INFORMATION](../messages/common.md#COMPONENT_INFORMATION) is not used by thie service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)).
[COMPONENT_INFORMATION](../messages/common.md#COMPONENT_INFORMATION) is not used by this service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)).
:::
## Component Information File Format (Schema) {#schema_files}
@@ -42,7 +42,7 @@ The component information file types and schema are (at time of writing):
| ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="COMP_METADATA_TYPE_GENERAL"></a>General metadata | [COMP_METADATA_TYPE_GENERAL](../messages/common.md#COMP_METADATA_TYPE_GENERAL) | [general.schema.json](https://github.com/mavlink/mavlink/blob/master/component_metadata/general.schema.json) | General information about the component including hardware/firmware vendor version. This metadata includes information about all the other metadata types are supported by the component and where their metadata files are located. This metadata type must be supported if this protocol is supported and the file must be present on vehicle and delivered by MAVLink FTP. Note however that you never actually need to specify this type! |
| <a id="COMP_METADATA_TYPE_PARAMETER"></a>Parameter metadata | [COMP_METADATA_TYPE_PARAMETER](../messages/common.md#COMP_METADATA_TYPE_PARAMETER) | [parameter.schema.json](https://github.com/mavlink/mavlink/blob/master/component_metadata/parameter.schema.json) | Information about parameters supported by the vehicle (on boot). |
| <a id="COMP_METADATA_TYPE_COMMANDS"></a> Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command paramters are supported in via the command protocol. |
| <a id="COMP_METADATA_TYPE_COMMANDS"></a> Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command parameters are supported via the command protocol. |
| <a id="COMP_METADATA_TYPE_PERIPHERALS"></a> Peripheral metadata | [COMP_METADATA_TYPE_PERIPHERALS](../messages/common.md#COMP_METADATA_TYPE_PERIPHERALS) | [peripherals.schema.json](https://github.com/mavlink/mavlink/blob/master/component_metadata/peripherals.schema.json) | Information about non-MAVLink peripherals connected to vehicle (on boot). |
| <a id="COMP_METADATA_TYPE_EVENTS"></a> Event metadata | [COMP_METADATA_TYPE_EVENTS](../messages/common.md#COMP_METADATA_TYPE_EVENTS) | TBD | Information about events interface support by the vehicle. |
| <a id="COMP_METADATA_TYPE_ACTUATORS"></a> Event metadata | [COMP_METADATA_TYPE_ACTUATORS](../messages/common.md#COMP_METADATA_TYPE_ACTUATORS) | [actuators.schema.json ](https://github.com/mavlink/mavlink/blob/master/component_metadata/actuators.schema.json) | Metadata for actuator configuration (motors, servos and vehicle geometry) and testing. |
@@ -262,7 +262,7 @@ The example repository is https://github.com/PX4/PX4-Metadata-Translations:
Schema _management_ has not yet been signed off.
### Guaranteed Availablility of Component Information
### Guaranteed Availability of Component Information
There is a concern that vehicles reliant on internet-hosted component information files may stop working if the hosting ceases.
ko/services/events.md
+1 -1
View File
@@ -50,7 +50,7 @@ The following key features are provided by the interface:
| Enum | Description |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="MAV_EVENT_CURRENT_SEQUENCE_FLAGS"></a>[MAV_EVENT_CURRENT_SEQUENCE_FLAGS](../messages/common.md#CURRENT_EVENT_SEQUENCE) | Flags for [CURRENT_EVENT_SEQUENCE](#CURRENT_EVENT_SEQUENCE). For exmaple, to indicate when the sequence has reset. |
| <a id="MAV_EVENT_CURRENT_SEQUENCE_FLAGS"></a>[MAV_EVENT_CURRENT_SEQUENCE_FLAGS](../messages/common.md#CURRENT_EVENT_SEQUENCE) | Flags for [CURRENT_EVENT_SEQUENCE](#CURRENT_EVENT_SEQUENCE). For example, to indicate when the sequence has reset. |
| <a id="MAV_EVENT_ERROR_REASON"></a>[MAV_EVENT_ERROR_REASON](../messages/common.md#MAV_EVENT_ERROR_REASON) | Reasons for an error, as provided in [RESPONSE_EVENT_ERROR](#RESPONSE_EVENT_ERROR). For example, common error would be that the event is not available (i.e. it has been discarded). |
## 구현
ko/services/gimbal_v2.md
+6 -6
View File
@@ -178,7 +178,7 @@ It is possible for multiple components to want to control a gimbal at the same t
In order to start controlling a gimbal, a component first needs to send the [MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE](#MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE) command.
This allows setting which MAVLink component (set by system ID and component ID) is in primary control and which one is in secondary control.
The gimbal manager is to ignore any gimbal controls which come from MAVLink components that are not explicity set to "in control".
The gimbal manager is to ignore any gimbal controls which come from MAVLink components that are not explicitly set to "in control".
This should prevent conflicts between various inputs as long as all components are fair/co-operative when using the configure command.
To be co-operative entails the following rules:
@@ -203,7 +203,7 @@ A ground station can manually control a gimbal by sending [GIMBAL_MANAGER_SET_MA
This allows controlling the gimbal with either angles, or angular rates, using a normalized unit (-1..1).
The gimbal device is responsible for translating the input based on angle, speed, and "smoothness" settings.
This input can additionally be scaled by the gimbal manager depending on its state. For example, if the gimbal manager is on a camera and knows the current zoom level / focal length of the camera, it can scale the angular rate down to support smooth paning and tilting.
This input can additionally be scaled by the gimbal manager depending on its state. For example, if the gimbal manager is on a camera and knows the current zoom level / focal length of the camera, it can scale the angular rate down to support smooth panning and tilting.
#### Controlling Gimbal Angle and/or Angular Rate using MAVLink
@@ -232,7 +232,7 @@ This data is required by the _Gimbal Device_ attitude estimator (horizon compens
The gimbal device should send out its attitude and status in [GIMBAL_DEVICE_ATTITUDE_STATUS](#GIMBAL_DEVICE_ATTITUDE_STATUS) at a regular rate, e.g. 10 Hz.
This message is a meant as broadcast, so it's set to the GCS, _Gimbal Manager_, and all parties on the network (not just _Gimbal Manager_, like all other messages).
This message is a meant as broadcast, so it's sent to the GCS, _Gimbal Manager_, and all parties on the network (not just _Gimbal Manager_, like all other messages).
### Custom Gimbal Device Settings
@@ -278,7 +278,7 @@ The recommendation is to make it configurable using (for instance) a parameter.
A non-MAVLink gimbal needs to be connected to a gimbal manager, which then takes care of sending the gimbal device messages.
Since a non-MAVLink gimbal can't be addressed with a MAVLink component ID, the `gimbal_device_id` needs to be set to one of the magic values (1 to 6).
This signals that the gimbal manager also is also acting as the gimbal device.
This signals that the gimbal manager is also acting as the gimbal device.
Also see [how to address non-MAVLink gimbal devices](#non_mavlink_gimbal_device_addressing).
@@ -350,7 +350,7 @@ This is the set of messages/enums for communication between gimbal manager and g
## Sequences
Depicted below are message sequences for some common scenarious.
Depicted below are message sequences for some common scenarios.
### Discovery
@@ -408,7 +408,7 @@ sequenceDiagram
[![](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgcGFydGljaXBhbnQgR3JvdW5kIFN0YXRpb25cbiAgICBwYXJ0aWNpcGFudCBHaW1iYWwgTWFuYWdlclxuICAgIHBhcnRpY2lwYW50IEdpbWJhbCBEZXZpY2VcbiAgICBHcm91bmQgU3RhdGlvbi0-PkdpbWJhbCBNYW5hZ2VyOiBNQVZfQ01EX0RPX1NFVF9ST0lfTE9DQVRJT05cbiAgICBHaW1iYWwgTWFuYWdlci0-Pkdyb3VuZCBTdGF0aW9uOiBDT01NQU5EX0FDS1xuICAgIEdpbWJhbCBNYW5hZ2VyLT4-R2ltYmFsIERldmljZTogR0lNQkFMX0RFVklDRV9TRVRfQVRUSVRVREUgKHN0cmVhbSlcbiAgICBHaW1iYWwgRGV2aWNlLT4-R2ltYmFsIE1hbmFnZXI6IEdJTUJBTF9ERVZJQ0VfQVRUSVRVREVfU1RBVFVTIChzdHJlYW0pXG4gICAgR2ltYmFsIERldmljZS0-Pkdyb3VuZCBTdGF0aW9uOiBHSU1CQUxfREVWSUNFX0FUVElUVURFX1NUQVRVUyAoc3RyZWFtKVxuICAgIEdyb3VuZCBTdGF0aW9uLT4-R2ltYmFsIE1hbmFnZXI6IE1BVl9DTURfRE9fU0VUX1JPSV9OT05FXG4gICAgR2ltYmFsIE1hbmFnZXItPj5Hcm91bmQgU3RhdGlvbjogQ09NTUFORF9BQ0siLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgcGFydGljaXBhbnQgR3JvdW5kIFN0YXRpb25cbiAgICBwYXJ0aWNpcGFudCBHaW1iYWwgTWFuYWdlclxuICAgIHBhcnRpY2lwYW50IEdpbWJhbCBEZXZpY2VcbiAgICBHcm91bmQgU3RhdGlvbi0-PkdpbWJhbCBNYW5hZ2VyOiBNQVZfQ01EX0RPX1NFVF9ST0lfTE9DQVRJT05cbiAgICBHaW1iYWwgTWFuYWdlci0-Pkdyb3VuZCBTdGF0aW9uOiBDT01NQU5EX0FDS1xuICAgIEdpbWJhbCBNYW5hZ2VyLT4-R2ltYmFsIERldmljZTogR0lNQkFMX0RFVklDRV9TRVRfQVRUSVRVREUgKHN0cmVhbSlcbiAgICBHaW1iYWwgRGV2aWNlLT4-R2ltYmFsIE1hbmFnZXI6IEdJTUJBTF9ERVZJQ0VfQVRUSVRVREVfU1RBVFVTIChzdHJlYW0pXG4gICAgR2ltYmFsIERldmljZS0-Pkdyb3VuZCBTdGF0aW9uOiBHSU1CQUxfREVWSUNFX0FUVElUVURFX1NUQVRVUyAoc3RyZWFtKVxuICAgIEdyb3VuZCBTdGF0aW9uLT4-R2ltYmFsIE1hbmFnZXI6IE1BVl9DTURfRE9fU0VUX1JPSV9OT05FXG4gICAgR2ltYmFsIE1hbmFnZXItPj5Hcm91bmQgU3RhdGlvbjogQ09NTUFORF9BQ0siLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)
ROI can be started using a command and should also be stopped again with a command. The ROI command is translated to a gimbal attitude in the the gimbal manager.
ROI can be started using a command and should also be stopped again with a command. The ROI command is translated to a gimbal attitude in the gimbal manager.
### Attitude Set During Mission
ko/services/mission.md
+5 -5
View File
@@ -107,7 +107,7 @@ The following messages and enums are used by the service.
The legacy version of the protocol also supported [MISSION_REQUEST](../messages/common.md#MISSION_REQUEST) for requesting that a mission be sent as a sequence of [MISSION_ITEM](../messages/common.md#MISSION_ITEM) messages.
Both `MISSION_REQUEST` and `MISSION_ITEM` messages are now deprecated, and should no longer be sent.
If `MISSION_REQUEST` is recieved the system should instead respond with [MISSION_ITEM_INT](#MISSION_ITEM_INT) items (as though it received [MISSION_REQUEST_INT](#MISSION_REQUEST_INT)).
If `MISSION_REQUEST` is received the system should instead respond with [MISSION_ITEM_INT](#MISSION_ITEM_INT) items (as though it received [MISSION_REQUEST_INT](#MISSION_REQUEST_INT)).
## Frames & Positional Information
@@ -176,7 +176,7 @@ The only expectation is that the scheme used makes it unlikely that the GCS will
On upload, the generated ID is sent to the GCS in the final part of the upload sequence in the [MISSION_ACK.opaque_id](#MISSION_ACK) field.
On download, the stored ID is sent to the GCS in the [MISSION_COUNT.opaque_id](#MISSION_COUNT) field.
The GCS should store the value of the ID from the flight stack as the "current id" for whatever part of the plan was uploaded/download.
The GCS should store the value of the ID from the flight stack as the "current id" for whatever part of the plan was uploaded/downloaded.
It can then monitor `MISSION_CURRENT`, and check its cached values against the current plan ids to determine whether it has a matching mission, or needs to download the mission from the vehicle.
### Upload a Mission to the Vehicle {#uploading_mission}
@@ -340,7 +340,7 @@ In more detail, the sequence of operations is:
1. GCS/API sends [MISSION_CLEAR_ALL](../messages/common.md#MISSION_CLEAR_ALL)
- A [timeout](#timeout) is started for the GCS to wait on `MISSION_ACK` from Drone.
2. Drone receives the message, and clears the mission from storage.
3. Drone responds with [MISSION_ACK](../messages/common.md#MISSION_ACK) with result `type` of [MAV_MISSION_ACCEPTED](../messages/common.md#MAV_MISSION_ACCEPTED)[MAV_MISSION_RESULT](../messages/common.md#MAV_MISSION_RESULT).
3. Drone responds with [MISSION_ACK](../messages/common.md#MISSION_ACK) with result `type` of [MAV_MISSION_ACCEPTED](../messages/common.md#MAV_MISSION_ACCEPTED) indicating success.
4. GCS receives `MISSION_ACK` and clears its own stored information about the mission.
The operation is now complete.
@@ -382,7 +382,7 @@ An operation may also complete with an error - `MISSION_ACK.type` set to [MAV_MI
This can occur in response to any message/anywhere in the sequence.
Errors are considered unrecoverable.
In an error is sent, both ends of the system should reset themselves to the idle state and the current state of the mission on the vehicle should be unaltered.
If an error is sent, both ends of the system should reset themselves to the idle state and the current state of the mission on the vehicle should be unaltered.
Note:
@@ -427,7 +427,7 @@ The direction of loiter for `MAV_CMD_NAV_LOITER_UNLIM` can be set using `param4`
The remaining parameters (xtrack and heading) apply only to forward flying aircraft (not multicopters!)
:::
Xtrack and heading define the location at which a forward flying (fixed wing) vehicle will _exit the loiter circle, and its path to the next waypoint_ (these apply only to apply to only `MAV_CMD_NAV_LOITER_TIME` and `MAV_CMD_NAV_LOITER_TURNS`).
Xtrack and heading define the location at which a forward flying (fixed wing) vehicle will _exit the loiter circle, and its path to the next waypoint_ (these apply only to `MAV_CMD_NAV_LOITER_TIME` and `MAV_CMD_NAV_LOITER_TURNS`).
| Param (:Label) | Description | Units |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
ko/services/offboard_control.md
+1 -1
View File
@@ -13,7 +13,7 @@ The particular types of setpoints that are supported, if any, depend on the vehi
| Message | Description |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| <a id="SET_POSITION_TARGET_LOCAL_NED"></a>[SET_POSITION_TARGET_LOCAL_NED](../messages/common.md#SET_POSITION_TARGET_LOCAL_NED) | Sets a desired vehicle position, velocity, and/or accelaration setpoint in a local north-east-down coordinate frame. |
| <a id="SET_POSITION_TARGET_LOCAL_NED"></a>[SET_POSITION_TARGET_LOCAL_NED](../messages/common.md#SET_POSITION_TARGET_LOCAL_NED) | Sets a desired vehicle position, velocity, and/or acceleration setpoint in a local north-east-down coordinate frame. |
| <a id="SET_POSITION_TARGET_GLOBAL_INT"></a>[SET_POSITION_TARGET_GLOBAL_INT](../messages/common.md#SET_POSITION_TARGET_GLOBAL_INT) | Sets a desired vehicle position, velocity, and/or acceleration in a global coordinate system (WGS84) |
| <a id="SET_ATTITUDE_TARGET"></a>[SET_ATTITUDE_TARGET](../messages/common.md#SET_ATTITUDE_TARGET) | Sets a desired vehicle attitude. |
| <a id="POSITION_TARGET_LOCAL_NED"></a>[POSITION_TARGET_LOCAL_NED](../messages/common.md#POSITION_TARGET_LOCAL_NED) | Publishes current local NED target (set by `SET_POSITION_TARGET_LOCAL_NED`). |
ko/services/parameter.md
+2 -2
View File
@@ -48,7 +48,7 @@ Parameters names/ids are set in the `param_id` field of messages where they are
The `param_id` string can store up to 16 characters.
The string is terminated with a NULL (`\0`) character if there are less than 16 human-readable chars, and without a null termination byte if the length is exactly 16 chars.
## Parameter Encoding
## Parameter Encoding {#parameter_encoding}
Parameter values are encoded in the `param_value` field, an IEE754 single-precision, 4 byte, floating point value (see [PARAM_SET](#PARAM_SET) and [PARAM_VALUE](#PARAM_VALUE)).
The `param_type` ([MAV_PARAM_TYPE](../messages/common.md#MAV_PARAM_TYPE)) is used to indicate the actual type of the data, so that it can be decoded by the recipient.
@@ -58,7 +58,7 @@ Two encoding approaches are supported:
- **Byte-wise encoding:** The parameter's bytes are copied directly into the bytes used for the field.
A 32-bit integer is sent as 32 bits of data.
- **C-style cast:** The parameter value is converted to a `float`. This may result in some loss of precision as a `float` can represent an integer with up to 24 bits of pecision.
- **C-style cast:** The parameter value is converted to a `float`. This may result in some loss of precision as a `float` can represent an integer with up to 24 bits of precision.
Byte wise encoding is recommended as it allows very large integers to be exchanged (e.g. 1E7 scaled integers can be useful for encoding some types of data, but lose precision if cast directly to floats).
ko/services/payload.md
+1 -1
View File
@@ -39,7 +39,7 @@ MAVLink has a number of commands for setting actuator outputs. These can be used
## Payload Deployment Commands
These commands can be used to deploy a payload at a specfic location, controlling the approach and land behaviour.
These commands can be used to deploy a payload at a specific location, controlling the approach and land behaviour.
| Message | Description |
| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
ko/services/timesync.md
+1 -1
View File
@@ -61,7 +61,7 @@ This allows filtering of the response to a particular system (but not component)
:::
:::info
Version 2 makes adds the target address, so a syncing system can filter on just the responses to its requests.
Version 2 adds the target address, so a syncing system can filter on just the responses to its requests.
:::
## 구현
ko/services/traffic_management.md
+2 -2
View File
@@ -1,4 +1,4 @@
# Traffic Managment and Avoidance (UTM/ADSB)
# Traffic Management and Avoidance (UTM/ADSB)
Air traffic management and avoidance systems enable vehicles to share their position and planned path or trajectory with other vehicles (and ground stations), allowing them to take appropriate action to avoid collisions.
@@ -15,7 +15,7 @@ There are two main traffic management systems supported by MAVLink:
FLARM is a transponder-based system that integrates with MAVLink using the ADS-B messages.
:::
The two systems share significant overlap and have very similar messages. Both have a single message that encapsulates the vehicle position and trajectory: [UTM_GLOBAL_POSITION](#UTM_GLOBAL_POSITION) and [ADSB_VEHICLE](#ADSB_VEHICLE). A flight controller will typically recieve these messages from the appropriate transponder or service, and may also publish them to a transponder or service.
The two systems share significant overlap and have very similar messages. Both have a single message that encapsulates the vehicle position and trajectory: [UTM_GLOBAL_POSITION](#UTM_GLOBAL_POSITION) and [ADSB_VEHICLE](#ADSB_VEHICLE). A flight controller will typically receive these messages from the appropriate transponder or service, and may also publish them to a transponder or service.
::: info The [Open Drone ID](https://mavlink.io/en/services/opendroneid.html) service provides additional information about vehicle identity. This is still a "work in progress", and there are no known MAVLink implementations, :::
zh/about/faq.md
+1 -1
View File
@@ -69,6 +69,6 @@
<dt>如何进一步减少生成的 C 库大小？</dt>
<dd>在资源极受限制的系统中，您可以通过设置 <code>MAVLINK_COMM_NUM_BUFFERS=1</code> 和 <code>MAVLINK_MAX_PAYLOAD_LEN</code>="可提供最大缓冲区大小" (假设仅有一个普通链路并且你的有效载荷小于MAVLink支持的最大值)。
您还应确保您用来传递到 MAVLink 的任何缓冲区也尽可能小(例如：传递到 <code>mavlink_msg_to_send_buffer()</code>的缓冲区)。
<br /><br />Another alternative is to use one of the other generators. 例如， <a href="https://github.com/olliw42/fastmavlink">fastMavlink</a> 生成它比mavgen可以生成更小和更有效率的库(这尚未被 MAVLink 项目验证)。</dd>
<br /><br />Another alternative is to use one of the other generators. For example <a href="https://github.com/olliw42/fastmavlink">fastMavlink</a> asserts that it is smaller and more efficient than the libraries generated by mavgen (this has not been validated by the MAVLink project).</dd>
</dl>
zh/contributing/contributing.md
+3 -3
View File
@@ -28,7 +28,7 @@ The sections below explain how to contribute to each category and how to raise a
Changes to the [mavgen](../getting_started/generate_libraries.md#mavgen) generator must be added as pull requests through the [ArduPilot/pymavlink](https://github.com/ArduPilot/pymavlink) project.
Changes to existing generator code (e.g. bug fixes) are automatically tested by continuous integration (github actions).
Once you have made against your PR pass, the changes will be reviewed by a project team member.
Once you have made your PR pass, the changes will be reviewed by a project team member.
More significant changes to the generator, such as the addition of a new programming language, will require:
@@ -47,14 +47,14 @@ Ideally:
## How to Contribute Stand Alone Generators
We would prefer that new languages are supported via [mavgen](../getting_started/generate_libraries.md#mavgen) rather than "standalone generators", as this provides a consistent inteface for end users, and ensures that source files are parsed and handled consistently.
We would prefer that new languages are supported via [mavgen](../getting_started/generate_libraries.md#mavgen) rather than "standalone generators", as this provides a consistent interface for end users, and ensures that source files are parsed and handled consistently.
That said will consider moving stand-alone generators into the MAVLink project under the same conditions as for new mavgen generator code (see section above).
Primarily this means that the team developing the generator must provide sufficient validation that the generator works and commitment to support it.
## How to Open a Pull Request
1. First [fork and clone](https://help.github.com/articles/fork-a-repo) the project project.
1. First [fork and clone](https://help.github.com/articles/fork-a-repo) the project.
2. 在主服务器上创建要素分支
zh/file_formats/index.md
+1 -1
View File
@@ -16,7 +16,7 @@ _QGroundControl_ and many other GCS support an older plain-text format for missi
这不是MAVLink的正式组成部分，也不允许提供集会点或地理围栏信息。
格式如下。
第一行包含文件格式和版本信息，后面行为任务项目。
The first line contains the file format and version information, while subsequent line(s) are mission items.
```
QGC WPL <VERSION>
zh/getting_started/generate_libraries.md
+2 -2
View File
@@ -20,7 +20,7 @@ For more information see [Supported Languages](../index.md#supported_languages).
## 先决条件
1. You must already have [Installed the MAVLink toolchain](../getting_started/installation.md), which includes the mavgenerate and mavgen tools used below as well as the [XML Message Definitions](../messages/index.md).
2. If you are generating messages for a [custom dialect](../messages/index.md#dialects), copy the dialect [XML definition file(s)](../messages/index.md#xml-definition-files--dialects) into the directory [message_definitions/v1.0/](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0).
2. If you are generating messages for a [custom dialect](../messages/dialects.md), copy the dialect [XML definition file(s)](../messages/index.md#xml-definition-files--dialects) into the directory [message_definitions/v1.0/](https://github.com/mavlink/mavlink/tree/master/message_definitions/v1.0).
::: info
_mavgen_ can handle dialects that have relative paths for included XML files (e.g typically [common.xml](../messages/common.md)), but other generators may not.
@@ -90,7 +90,7 @@ python3 -m pymavlink.tools.mavgen --lang=C --wire-protocol=2.0 --output=generate
```
:::info
The syntax for for generating Python modules is the same, except that the `--output` specifies a _filename_ rather than a directory.
The syntax for generating Python modules is the same, except that the `--output` specifies a _filename_ rather than a directory.
:::
<!-- https://github.com/ArduPilot/pymavlink/issues/203 -->
zh/getting_started/installation.md
+4 -4
View File
@@ -1,6 +1,6 @@
# 安装MAVLink工具链
This topic explains how to install the [MAVLink toolchain](https://github.com/mavlink/mavlink). The toolchain includes the [XML message definitions](../messages/index.md) as well as the the GUI/command line tools that use the definitions to [Generate MAVLink Source Files](../getting_started/generate_libraries.md).
This topic explains how to install the [MAVLink toolchain](https://github.com/mavlink/mavlink). The toolchain includes the [XML message definitions](../messages/index.md) as well as the GUI/command line tools that use the definitions to [Generate MAVLink Source Files](../getting_started/generate_libraries.md).
:::tip
You do not need to install or generate the source files if you are using the C programming language and a standard [dialect](../messages/index.md#dialects).
@@ -25,9 +25,9 @@ The requirements for using the _MAVLink generator_ are:
- **Windows:** Download from [Python for Windows](https://www.python.org/downloads/)
- **Ubuntu Linux** Make sure Python and Pip are both installed:
```
sudo apt install python3-tk
```
```
sudo apt install python3-tk
```
2. Clone the official [mavlink repo](https://github.com/mavlink/mavlink) or your fork with your custom dialect:
zh/guide/crc.md
+1 -1
View File
@@ -4,7 +4,7 @@ MAVLink services that need to use a Cyclic Redundancy Check (CRC) should choose
:::info
Using the same CRC implementation for all cases means that only one implementation is required.
Do not introduce another unless there without a compelling technical reason.
Do not introduce another unless there is a compelling technical reason.
:::
:::info
zh/guide/define_xml_element.md
+33 -33
View File
@@ -93,48 +93,48 @@ To create a new dialect file:
3. Copy the following text into the new file.
```xml
<?xml version="1.0"?>
<mavlink>
```xml
<?xml version="1.0"?>
<mavlink>
<include>common.xml</include>
<!-- <version>9</version> -->
<dialect>8</dialect>
<include>common.xml</include>
<!-- <version>9</version> -->
<dialect>8</dialect>
<enums>
<!-- Enums are defined here (optional) -->
</enums>
<enums>
<!-- Enums are defined here (optional) -->
</enums>
<messages>
<!-- Messages are defined here (optional) -->
</messages>
<messages>
<!-- Messages are defined here (optional) -->
</messages>
</mavlink>
```
</mavlink>
```
The template assumes that your dialect:
The template assumes that your dialect:
- imports **common.xml** (`<include>common.xml</include>`)
- takes its version from **common.xml** (which is why the `version` tags are commented out).
- imports **common.xml** (`<include>common.xml</include>`)
- takes its version from **common.xml** (which is why the `version` tags are commented out).
4. Update the `include`(s):
- if the dialect is not based on **common.xml** remove the existing `include` line
- Add additional `<include> </include>` elements to import additional files/dialects.
- if the dialect is not based on **common.xml** remove the existing `include` line
- Add additional `<include> </include>` elements to import additional files/dialects.
::: info
Includes in nested files are ignored.
:::
::: info
Includes in nested files are ignored.
:::
5. Update the `version`:
- Most dialects should leave the version commented out (i.e. all dialects that include **common.xml**).
- Dialects that are _not_ based on **common.xml** can uncomment the `<version>6</version>` line and use whatever version is desired.
- Most dialects should leave the version commented out (i.e. all dialects that include **common.xml**).
- Dialects that are _not_ based on **common.xml** can uncomment the `<version>6</version>` line and use whatever version is desired.
::: info
The `version` specified in the top level file is used by default, if present.
If it is not present in the file, then a `version` from an included file is used.
:::
::: info
The `version` specified in the top level file is used by default, if present.
If it is not present in the file, then a `version` from an included file is used.
:::
6. Update the `<dialect>8</dialect>` line to replace `8` with the next-largest unused dialect number (based on the other files in the folder).
@@ -176,7 +176,7 @@ Messages must be declared between the `<messages></messages>` tags in either **c
Each message is defined using `<message id="" name="LIBRARY_UNIQUE_NAME"> ... </message>` tags (with unique `id` and `name` attributes).
:::tip
The only only difference between messages defined in **common.xml** or _dialect_ files is they they must use different `id` ranges in order to ensure that the `ids` are unique. See [Message Id Ranges](#message_id_ranges) for more information.
The only difference between messages defined in **common.xml** or _dialect_ files is they they must use different `id` ranges in order to ensure that the `ids` are unique. See [Message Id Ranges](#message_id_ranges) for more information.
:::
The main rules for messages are:
@@ -255,7 +255,7 @@ For a message in **common.xml** either change requires the agreement of major st
- 在 MAVLink 开发者会议上创建 PR 和讨论。
::: tip
Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
Before proposing changes to **common.xml** check the codebase of major stakeholders to confirm impact.
:::
It is possible to change the message and field descriptions without breaking binary compatibility.
@@ -413,7 +413,7 @@ If an enum needs to be changed then there are several options:
For either case, all users of the enum will need to be updated with new generated libraries.
:::tip
Before proposing changes to **common.xml** check the codebase of major stakeholder to confirm impact.
Before proposing changes to **common.xml** check the codebase of major stakeholders to confirm impact.
:::
For an enum in **common.xml** either change requires the agreement of major stakeholders
@@ -480,7 +480,7 @@ If you are creating a new public dialect, [create an issue](https://github.com/m
:::
There are a number of common and ArduPilot commands that are outside the ranges (e.g. 16, 200, etc.).
Generally you would only use these these ranges in order to give a new command an id that is close to related to that of related commands.
Generally you would only use these ranges in order to give a new command an id that is close to related to that of related commands.
This can be done provided that the command id value is not used by any other XML file in the _mavlink/mavlink_ repo.
### Entry Names {#command_names}
@@ -531,7 +531,7 @@ If the param is reused the original default value must still mean "no action", s
:::info
Unfortunately this means that a reserved `param` must have its default value decided when the command is declared!
The default value cannot later be changed from `NaN` to `0` (or visa versa) without potential compatibility issues.
The default value cannot later be changed from `NaN` to `0` (or vice versa) without potential compatibility issues.
:::
To declare a `param` as `reserved` with `default` value of `NaN` you should use the following syntax.
zh/guide/mavlink_2.md
+1 -1
View File
@@ -13,7 +13,7 @@ The key new features of _MAVLink 2_ are:
- [Packet signing](../guide/message_signing.md) - Authenticate that messages were sent by trusted systems.
- [Message extensions](../guide/define_xml_element.md#message_extensions) - Add new fields to existing MAVLink message definitions without breaking binary compatibility for receivers that have not updated.
- [Empty-byte payload truncation](../guide/serialization.md#payload_truncation) - Empty (zero-filled) bytes at the end of the serialized payload must be removed before sending (All bytes were sent in _MAVLink 1_, regardless of content).
- [Compatibility Flags](../guide/serialization.md#compat_flags)/[Incompatibility Flags](../guide/serialization.md#incompat_flags) - Allow for backwards compatible evolution of the protocol by indicating frames that must be handled in a special/non-standard way (packets with compatibility flags can still be handled in the standard way, while packets with incompatibility flags must be dropped if the flage is not supported).
- [Compatibility Flags](../guide/serialization.md#compat_flags)/[Incompatibility Flags](../guide/serialization.md#incompat_flags) - Allow for backwards compatible evolution of the protocol by indicating frames that must be handled in a special/non-standard way (packets with compatibility flags can still be handled in the standard way, while packets with incompatibility flags must be dropped if the flag is not supported).
:::tip
The _MAVLink 2_ [design document](https://docs.google.com/document/d/1XtbD0ORNkhZ8eKrsbSIZNLyg9sFRXMXbsR2mp37KbIg/edit?usp=sharing) provides additional background information about the changes.
zh/guide/mavlink_version.md
+2 -2
View File
@@ -10,7 +10,7 @@ The _MAVLink 2.0_ C/C++ and Python libraries are backwards compatible with MAVLi
:::info
_MAVLink v0.9_ is a pre-release version that is no longer supported.
The associated message set deleted in August 2018.
The associated message set was deleted in August 2018.
Legacy code may be present in generator and test code.
:::
@@ -51,7 +51,7 @@ This is reasonable because the majority of systems and communication links now r
Most flight stacks assume communication links are transparent.
Possible causes of links not being transparent are:
- Routing, which can can change or reserialize MAVLink packets (for example, there might be an intermediate router that converts between versions).
- Routing, which can change or reserialize MAVLink packets (for example, there might be an intermediate router that converts between versions).
- Wireless links that rely on fixed length packetization may distort or truncate variable-length MAVLink 2 frames.
For example, older SiK Radios may consume MAVLink 2 messages.
zh/guide/message_signing.md
+10 -10
View File
@@ -14,24 +14,24 @@ It explains how a system can determine if a message is signed and whether the si
## 帧格式
For a signed packet the **0x01** bit of the [incompatibility flag field](../guide/mavlink_2.md#incompat_flags) is set true and an additional 13 bytes of "signature" data appended to the packet.
For a signed packet the **0x01** bit of the [incompatibility flag field](../guide/serialization.md#incompat_flags) is set true and an additional 13 bytes of "signature" data appended to the packet.
签名的数据包格式如下。
![MAVLink 2 Signed](../../assets/packets/packet_mavlink_v2_signing.png)
:::info
The [incompatibility flags](../guide/mavlink_2.md#incompat_flags) in the packet header are used to indicate that the MAVLink library must reject the packet if it does not understand or cannot handle the flag.
The [incompatibility flags](../guide/serialization.md#incompat_flags) in the packet header are used to indicate that the MAVLink library must reject the packet if it does not understand or cannot handle the flag.
In other words, a MAVLink library that does not support signing must drop signed packets.
The C library uses [MAVLINK_IFLAG_SIGNED](../guide/mavlink_2.md#MAVLINK_IFLAG_SIGNED) to represent the "supports message signing" bit.
The C library uses [MAVLINK_IFLAG_SIGNED](../guide/serialization.md#MAVLINK_IFLAG_SIGNED) to represent the "supports message signing" bit.
:::
签字的13字节为：
| 数据 | 描述 |
| ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [linkID](#link_ids) (8&amp;nbsp;bits) | 发送数据包的链接ID。 通常与<em>channel</em>相同。 Normally this is the same as the _channel_. |
| [timestamp](#timestamps) (48 bits) | 2015年1月1日GMT时间以来的10个微秒时间戳。 This _must_ monotonically increase for every message on a particular [link](#link_ids). 请注意，如果数据包平均每秒100,000多个数据包，那么时间戳可能早于实际时间。 |
| [signature](#signature) (48 bits) | 基于完整的数据包、时间戳和秘密密钥，数据包有48位签名。 |
| 数据 | 描述 |
| ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [linkID](#link_ids) (8&nbsp;bits) | 发送数据包的链接ID。 通常与<em>channel</em>相同。 Normally this is the same as the _channel_. |
| [timestamp](#timestamp) (48 bits) | 2015年1月1日GMT时间以来的10个微秒时间戳。 This _must_ monotonically increase for every message on a particular [link](#link_ids). 请注意，如果数据包平均每秒100,000多个数据包，那么时间戳可能早于实际时间。 |
| [signature](#signature) (48 bits) | 基于完整的数据包、时间戳和秘密密钥，数据包有48位签名。 |
见下文关于字段的更多信息。
@@ -160,7 +160,7 @@ The secret key may be shared to other devices using the [SETUP_SIGNING](../messa
The message should only ever be sent over a secure link (e.g. USB or wired Ethernet) as a direct message to each connected `system_id`/`component_id`.
必须设置接收系统来处理消息, 并将接收到的密钥存储到相应的永久存储中。
The same secure method can be used to both _set_ and _reset_ a system's key (reseting a key does not have to be "more secure" than setting it in the first place).
The same secure method can be used to both _set_ and _reset_ a system's key (resetting a key does not have to be "more secure" than setting it in the first place).
The `SETUP_SIGNING` message should never be broadcast, and received `SETUP_SIGNING` messages must never be automatically forwarded to other active MAVLink devices/streams/channels.
这是为了避免通过安全链接 (如 usb) 收到的密钥通过不安全的链接 (例如 wifi) 自动转发到另一个系统的情况。
@@ -176,7 +176,7 @@ The receiving system may be configured to ignore message signatures on the secur
In order to avoid leaking the secret key used for signing, systems should omit [SETUP_SIGNING](../messages/common.md#SETUP_SIGNING) messages from logs (or replace the secret with 32 0xFF bytes in the logged message).
Similarly, signed packets should have the signature [incompatibility bit](../guide/mavlink_2.md#incompat_flags) cleared and the signature block removed before being put into telemetry log files.
Similarly, signed packets should have the signature [incompatibility bit](../guide/serialization.md#incompat_flags) cleared and the signature block removed before being put into telemetry log files.
这使得潜在攻击者更难以收集大量签名数据来攻击系统。
## 更多信息
zh/guide/packet_loss.md
+1 -1
View File
@@ -1,7 +1,7 @@
# Packet Loss Calculation
MAVLink packet loss is calculated from the packet sequence number, an 8 bit field that is incremented each time a message is emitted on a channel.
The recipient of the message can track the last recieved/next expected sequence number, and if a packet sequence number is bigger than expected, any intermediate packets between the sequence numbers are assumed to have been lost.
The recipient of the message can track the last received/next expected sequence number, and if a packet sequence number is bigger than expected, any intermediate packets between the sequence numbers are assumed to have been lost.
The sequence number will wrap around at 255, and the recipient is expected to compensate for this.
This approach works if all messages sent on a channel are routed to the system calculating packet loss, and if messages from only one channel are received by the system calculating packet loss.
zh/guide/serialization.md
+11 -11
View File
@@ -1,6 +1,6 @@
# 包的序列化
This topic provides detailed information about about MAVLink packet serialization, including the over-the-wire formats for MAVLink v1 and v2 packets, the ordering of fields in the message payload, and the `CRC_EXTRA` used for ensuring that the sender and reciever share a compatible message definition.
This topic provides detailed information about MAVLink packet serialization, including the over-the-wire formats for MAVLink v1 and v2 packets, the ordering of fields in the message payload, and the `CRC_EXTRA` used for ensuring that the sender and receiver share a compatible message definition.
主要是为正在创建/维护 MAVLink 生成器的开发者
@@ -43,16 +43,16 @@ Below is the over-the-wire format for a MAVLink 1 packet (the in-memory represen
![MAVLink v1 packet](../../assets/packets/packet_mavlink_v1.jpg)
| 字节索引 | C 版本 | 内容 | 值 | 说明 |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | `uint8_t magic` | 数据包启动标记 | 0xFE | 特定于协议的文本启动 (stx) 标记, 用于指示新数据包的开始。 任何不识别协议版本的系统都将跳过数据包。 |
| 1 | `uint8_t len` | 载荷长度 | 0&amp;nbsp;-&amp;nbsp;255 | Indicates length of the following `payload` section (fixed for a particular message). |
| 2 | `uint8_t seq` | 数据包序列号 | 0 - 255 | 用于检测数据包丢失。 组件为发送的每封消息递增值。 |
| 3 | `uint8_t sysid` | System ID | 1 - 255 | ID of _system_ (vehicle) sending the message. 用于区分网络上的系统。 Note that the broadcast address 0 may not be used in this field as it is an invalid _source_ address. |
| 4 | `uint8_t compid` | Component ID | 1 - 255 | ID of _component_ sending the message. Used to differentiate components in a _system_ (e.g. autopilot and a camera). Use appropriate values in [MAV_COMPONENT](../messages/common.md#MAV_COMPONENT). Note that the broadcast address `MAV_COMP_ID_ALL` may not be used in this field as it is an invalid _source_ address. |
| <a id="v1_msgid"></a>5 | `uint8_t msgid` | 消息 ID | 0 - 255 | ID of _message type_ in payload. 用于将数据解码回消息对象。 |
| <a id="v1_payload"></a>For _n_-byte payload:<br>`n=0`: NA, `n=1`: 6, `n>=2`: 6 to (5+n) | `uint8_t payload[max 255]` | 有效负载数据 | | 消息数据。 Content depends on message type (i.e. Message ID). |
| (n+6) to (n+7) | `uint16_t checksum` | [Checksum](#checksum) (low byte, high byte) | | CRC-16/MCRF4XX for message (excluding `magic` byte). Includes [CRC_EXTRA](#crc_extra) byte. |
| 字节索引 | C 版本 | 内容 | 值 | 说明 |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | -------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 | `uint8_t magic` | 数据包启动标记 | 0xFE | 特定于协议的文本启动 (stx) 标记, 用于指示新数据包的开始。 任何不识别协议版本的系统都将跳过数据包。 |
| 1 | `uint8_t len` | 载荷长度 | 0&nbsp;-&nbsp;255 | Indicates length of the following `payload` section (fixed for a particular message). |
| 2 | `uint8_t seq` | 数据包序列号 | 0 - 255 | 用于检测数据包丢失。 组件为发送的每封消息递增值。 |
| 3 | `uint8_t sysid` | System ID | 1 - 255 | ID of _system_ (vehicle) sending the message. 用于区分网络上的系统。 Note that the broadcast address 0 may not be used in this field as it is an invalid _source_ address. |
| 4 | `uint8_t compid` | Component ID | 1 - 255 | ID of _component_ sending the message. Used to differentiate components in a _system_ (e.g. autopilot and a camera). Use appropriate values in [MAV_COMPONENT](../messages/common.md#MAV_COMPONENT). Note that the broadcast address `MAV_COMP_ID_ALL` may not be used in this field as it is an invalid _source_ address. |
| <a id="v1_msgid"></a>5 | `uint8_t msgid` | 消息 ID | 0 - 255 | ID of _message type_ in payload. 用于将数据解码回消息对象。 |
| <a id="v1_payload"></a>For _n_-byte payload:<br>`n=0`: NA, `n=1`: 6, `n>=2`: 6 to (5+n) | `uint8_t payload[max 255]` | 有效负载数据 | | 消息数据。 Content depends on message type (i.e. Message ID). |
| (n+6) to (n+7) | `uint16_t checksum` | [Checksum](#checksum) (low byte, high byte) | | CRC-16/MCRF4XX for message (excluding `magic` byte). Includes [CRC_EXTRA](#crc_extra) byte. |
- 最低数据包长度是8字节，用于没有有效载荷确认数据包。
- 最大的数据包长度是完整有效载荷263字节。
zh/guide/wireshark.md
+3 -3
View File
@@ -7,7 +7,7 @@ The benefits of using _Wireshark_ over other alternatives are:
- it can view _all_ traffic on a network interface (GCS tools like [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/analyze_view/mavlink_inspector.html) often only analyse incoming traffic).
- you can use it to analyse traffic logged on a companion computer (this allows analysis of traffic between the companion computer and flight controller, which might otherwise not be visible to _Wireshark_).
- it is easy to update for new custom messages and dialects.
Rebuilding _QGroundControl_ so you can use it analyse custom messages is much harder!
Rebuilding _QGroundControl_ so you can use it to analyse custom messages is much harder!
This topic shows how to generate a Wireshark plugin for a particular dialect file and install it on Wireshark, and how to perform basic filtering. It also provides an overview of how you can use <em x-id="3">tcpdump</em> for collecting traffic on a linux computer (for later analysis).
It also provides an overview of how you can use _tcpdump_ for collecting traffic on a linux computer (for later analysis).
@@ -24,7 +24,7 @@ The MAVLink generator (**mavgen**) can build this plugin for a dialect in the sa
The steps are:
1. [Install MAVLink](../getting_started/installation.md) (if you have not already done so).
2. Build libraries for your target dialect, specifing `WLua` as the target language.
2. Build libraries for your target dialect, specifying `WLua` as the target language.
This process is described in the topic [Generate MAVLink Libraries](../getting_started/generate_libraries.md).
For example, to build the MAVLink 2 Wireshark plugin for [common.xml](../messages/common.md) you might use the following command:
@@ -57,7 +57,7 @@ This might be necessary, for example, in order to monitor traffic recorded on th
To import the plugin into _Wireshark_:
1. Copy the plugin file into the wireshare plugins directory.
1. Copy the plugin file into the wireshark plugins directory.
- On Linux systems this might be: `~/.local/lib/wireshark/plugins` (or `~/.wireshark/plugins` for older versions of Wireshark).
Note that users will need to be added to the `wireshark` group to use the tool.)
- On Windows this might be: `Program Files/Wireshark/plugins`.
zh/guide/xml_schema.md
+15 -9
View File
@@ -103,7 +103,7 @@ The values are defined in nested [`<entry>`](#entry) elements.
Attributes:
- `name` (required): The name of the enum. 这是一系列大写的、以下划线分隔的词。
- `bitmask` (optional): Set to `true` for enums that defines entries with values that increase by a power of 2, such as flags.
- `bitmask` (optional): Set to `true` for enums that define entries with values that increase by a power of 2, such as flags.
Nested elements:
@@ -292,7 +292,13 @@ Nested elements:
The field value is its name/text string used in GUI documentation (but not sent over the wire).
Every message must have at least one field.
- `<extensions />` (optional): This self-closing tag is used to indicate that subsequent fields apply to MAVLink 2 only.
- 标记应该用于MAVLink 1 信息 (id < 256) 已扩展到MAVLink2。
### `<extensions />` element {#extensions}
A self-closing tag that indicates that subsequent fields apply to MAVLink 2 only.
This should only be used if a message needs new fields after it is already published.
New messages are preferred as extensions are not part of the CRC check, and can hence lead to undetectable incompatibilities.
### `<field>` element {#field}
@@ -303,7 +309,7 @@ The field inner content text string is used in GUI documentation (but not sent o
Attributes:
- `type`: Similar to a field in a C `struct` - the size of the data required to store/represent the data type.
- Fields can be signed/unsigned integers of size 8, 16, 23, 64 bits (`{u)int8_t`, `(u)int16_t`, `(u)int32_t`, `(u)int64_t`), single/double precision IEEE754 floating point numbers.
- Fields can be signed/unsigned integers of size 8, 16, 32, 64 bits (`{u)int8_t`, `(u)int16_t`, `(u)int32_t`, `(u)int64_t`), single/double precision IEEE754 floating point numbers.
They can also be arrays of the other types - e.g. `uint16_t[10]`.
- `name`: Name of the field (used in code).
@@ -331,13 +337,13 @@ Attributes:
- `instance`: If `true`, this indicates that the message contains the information for a particular sensor or battery (e.g. Battery 1, Battery 2, etc.) and that this field indicates which sensor. Default is `false`.
::: info
This field allows a recipient automatically associate messages for a particular sensor and plot them in the same series.
This field allows a recipient to automatically associate messages for a particular sensor and plot them in the same series.
:::
- `invalid`: Specifies a value that can be set on a field to indicate that the data is _invalid_: the recipient should ignore the field if it has this value.
For example, `BATTERY_STATUS.current_battery` specifies `invalid="-1"`, so a battery that does not measure supplied _current_ should set `BATTERY_STATUS.current_battery` to `-1`.
Where possible the value that indicates the field is invalid should be selected to outside the expected/valid range of the eld (`0` is preferred if it is not an acceptable value for the field).
Where possible the value that indicates the field is invalid should be selected to outside the expected/valid range of the field (`0` is preferred if it is not an acceptable value for the field).
For integers we usually select the largest possible value (i.e. `UINT16_MAX`, `INT16_MAX`, `UINT8_MAX`, `UINT8_MAX`).
For floats we usually select `invalid="NaN"`.
@@ -371,7 +377,7 @@ They should not be included in release builds.
The generator toolchain can be configured to conditionally build messages omitting the `<wip>` entries.
Generally new elements should be defined in `development.xml`, and any definitions in that file are considered WIP by default.
The `wip` element is intended primiarly for indicating WIP additions to `common.xml` that for whatever reason could not be added to `development.xml`.
The `wip` element is intended primarily for indicating WIP additions to `common.xml` that for whatever reason could not be added to `development.xml`.
Once the associated definition has been tested, it may be accepted into `common.xml` and the `<wip>` tag removed.
@@ -386,7 +392,7 @@ Attributes:
- `since` (optional): A datestamp indicating when the corresponding element was proposed.
This should be formatted as such as `YYYYMM`
This hints to the maintainter team when WIP elements should be reviewed for addition or removal.
This hints to the maintainer team when WIP elements should be reviewed for addition or removal.
Nested elements
@@ -409,7 +415,7 @@ Attributes:
- `since` (required): A datestamp indicating when the new element was accepted into files managed by the MAVLink team.
This should be formatted as such as `YYYY-MM`.
- `replaced_by` (required): The name of the definition that supersedes this elements.
- `replaced_by` (required): The name of the definition that supersedes this element.
Nested elements
@@ -418,7 +424,7 @@ Nested elements
### `<deprecated>` element {#deprecated}
The `<deprecated>` element is used to indicate when an element should not be used because it is on the path for removal from the standard.
Often by the time and element is deprecated it has already been removed from current releases of the main flight stacks.
Often by the time an element is deprecated it has already been removed from current releases of the main flight stacks.
The attributes indicates the time of deprecation and the replacement element, and may also include the intended date of removal.
The content of the element may (optionally) contain a string with additional information about the planned removal and alternative definitions.
zh/index.md
+1 -1
View File
@@ -24,7 +24,7 @@ MAVLink于2009年初由Lorenz Meier首次发布, 目前为止，已拥有[数量
## Language/Generator List {#supported_languages}
The sections below lists MAVLink generators and their associated programming languages.
The sections below list MAVLink generators and their associated programming languages.
### MAVLink Project Generators/Languages
zh/mavgen_c/index.md
+1 -1
View File
@@ -85,7 +85,7 @@ mavlink/common/../mavlink_helpers.h:86:24: warning: taking address of packed mem
```
The warning indicates the potential for hard faults caused by unaligned access to packed data.
This does not happen on most of the common architectures on which MAVLink is run, and generally the warning can be supressed.
This does not happen on most of the common architectures on which MAVLink is run, and generally the warning can be suppressed.
You can suppress the warnings using `-Wno-address-of-packed-member`.
zh/mavgen_python/howto_requestmessages.md
+1 -1
View File
@@ -7,7 +7,7 @@ A system can request that additional messages are sent as a stream, or change th
A single instance of a message can be requested by sending [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE).
The example below shows how you can request the [BATTERY_STATUS](../messages/common.md#BATTERY_STATUS) message is streamed at the rate of 1Hz, by sending `MAV_CMD_SET_MESSAGE_INTERVAL` in a [COMMAND_LONG](../messages/common.md#COMMAND_LONG).
Because this is a command, we then wait for a `COMMAND_ACK` to be recieved with the matching command id, and then display the result.
Because this is a command, we then wait for a `COMMAND_ACK` to be received with the matching command id, and then display the result.
Note that you could equally well send the command in a [COMMAND_INT](../messages/common.md#COMMAND_INT), if supported by the flight stack.
```python
zh/messages/common.md
+8 -7
View File
@@ -3875,6 +3875,7 @@ Predefined OR-combined [MAV_MODE_FLAG](#MAV_MODE_FLAG) values. These can simplif
| 值 | Name | 描述 |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| <a id='MAV_SYS_STATUS_RECOVERY_SYSTEM'></a>1 | [MAV_SYS_STATUS_RECOVERY_SYSTEM](#MAV_SYS_STATUS_RECOVERY_SYSTEM) | 0x01 Recovery system (parachute, balloon, retracts etc) |
| <a id='MAV_SYS_STATUS_SENSOR_LEAK'></a>2 | [MAV_SYS_STATUS_SENSOR_LEAK](#MAV_SYS_STATUS_SENSOR_LEAK) | 0x02 Leak detection |
### MAV_FRAME {#MAV_FRAME}
@@ -4323,13 +4324,13 @@ Note that at least one flag must be set in [MAV_CMD_DO_AUTOTUNE_ENABLE](#MAV_CMD
Actions for reading/writing parameters between persistent and volatile storage when using [MAV_CMD_PREFLIGHT_STORAGE](#MAV_CMD_PREFLIGHT_STORAGE).
(Commonly parameters are loaded from persistent storage (flash/EEPROM) into volatile storage (RAM) on startup and written back when they are changed.)
| 值 | Name | 描述 |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id='PARAM_READ_PERSISTENT'></a>0 | [PARAM_READ_PERSISTENT](#PARAM_READ_PERSISTENT) | Read all parameters from persistent storage. Replaces values in volatile storage. |
| <a id='PARAM_WRITE_PERSISTENT'></a>1 | [PARAM_WRITE_PERSISTENT](#PARAM_WRITE_PERSISTENT) | Write all parameter values to persistent storage (flash/EEPROM) |
| <a id='PARAM_RESET_CONFIG_DEFAULT'></a>2 | [PARAM_RESET_CONFIG_DEFAULT](#PARAM_RESET_CONFIG_DEFAULT) | Reset all user configurable parameters to their default value (including airframe selection, sensor calibration data, safety settings, and so on). Does not reset values that contain operation counters and vehicle computed statistics. |
| <a id='PARAM_RESET_SENSOR_DEFAULT'></a>3 | [PARAM_RESET_SENSOR_DEFAULT](#PARAM_RESET_SENSOR_DEFAULT) | Reset only sensor calibration parameters to factory defaults (or firmware default if not available) |
| <a id='PARAM_RESET_ALL_DEFAULT'></a>4 | [PARAM_RESET_ALL_DEFAULT](#PARAM_RESET_ALL_DEFAULT) | Reset all parameters, including operation counters, to default values |
| 值 | Name | 描述 |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id='PARAM_READ_PERSISTENT'></a>0 | [PARAM_READ_PERSISTENT](#PARAM_READ_PERSISTENT) | Read all parameters from persistent storage. Replaces values in volatile storage. |
| <a id='PARAM_WRITE_PERSISTENT'></a>1 | [PARAM_WRITE_PERSISTENT](#PARAM_WRITE_PERSISTENT) | Write all parameter values to persistent storage (flash/EEPROM) |
| <a id='PARAM_RESET_FACTORY_DEFAULT'></a>2 | [PARAM_RESET_FACTORY_DEFAULT](#PARAM_RESET_FACTORY_DEFAULT) | Reset parameters to default values (such as sensor calibration, safety settings, and so on). Note that a flight stack may choose not to reset some parameters at their own discretion (such as those that are locked or expected to persist for the vehicle lifetime). |
| <a id='PARAM_RESET_SENSOR_DEFAULT'></a>3 | [PARAM_RESET_SENSOR_DEFAULT](#PARAM_RESET_SENSOR_DEFAULT) | Reset only sensor calibration parameters to factory defaults (or firmware default if not available) |
| <a id='PARAM_RESET_ALL_DEFAULT'></a>4 | [PARAM_RESET_ALL_DEFAULT](#PARAM_RESET_ALL_DEFAULT) | Reset all parameters to default values. |
### PREFLIGHT_STORAGE_MISSION_ACTION {#PREFLIGHT_STORAGE_MISSION_ACTION}
zh/services/arm_authorization.md
+2 -2
View File
@@ -1,6 +1,6 @@
# Arm Authorization
When enabled by setting a parameter on flight stack, the drone will only arm the motors if authorized by a external entity.
When enabled by setting a parameter on the flight stack, the drone will only arm the motors if authorized by a external entity.
This external entity is responsible for requesting any information that it needs from the drone and from other sources (example: weather) and whether (or not) to authorize the arming procedure.
This is required to comply with [NASA UTM](https://utm.arc.nasa.gov/), but may also be useful for private companies.
@@ -25,7 +25,7 @@ sequenceDiagram;
Drone->>Remote control/QCS: QCS COMMAND_ACK command=MAV_CMD_COMPONENT_ARM_DISARM result=ACCEPTED, TEMPORARILY_REJECTED or DENIED
-->
In case the authorizer need a lot of time to get and process the information is better have another authorization flow to avoid arm the drone at unexpected time.
In case the authorizer needs a lot of time to get and process the information is better have another authorization flow to avoid arm the drone at unexpected time.
[![Mermaid Sequence: Arm authorisation 2](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMVxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgcmVzdWx0PVRFTVBPUkFSSUxZX1JFSkVDVEVEXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBTVEFUVVNURVhUIHRleHQ9QXJtIGF1dGhvcml6YXRpb24gd2FzIGFwcHJvdmVkIG9yIGRlbmllZFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMlxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgY29tbWFuZD1NQVZfQ01EX0NPTVBPTkVOVF9BUk1fRElTQVJNIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEIiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMVxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgcmVzdWx0PVRFTVBPUkFSSUxZX1JFSkVDVEVEXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBTVEFUVVNURVhUIHRleHQ9QXJtIGF1dGhvcml6YXRpb24gd2FzIGFwcHJvdmVkIG9yIGRlbmllZFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtMlxuICAgIERyb25lLT4-UmVtb3RlIGNvbnRyb2wvUUNTOiBRQ1MgQ09NTUFORF9BQ0sgY29tbWFuZD1NQVZfQ01EX0NPTVBPTkVOVF9BUk1fRElTQVJNIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEIiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)
zh/services/battery.md
+1 -1
View File
@@ -8,7 +8,7 @@ MAVLink provides a number of messages for providing battery information:
- Some batteries may provide [fault](#MAV_BATTERY_FAULT) and [mode](#MAV_BATTERY_MODE) information in this message.
::: info
`BATTERY_STATUS` is expected to be superseded by [BATTERY_STATUS_V2](../messages/development.html#BATTERY_STATUS_V2).
`BATTERY_STATUS` is expected to be superseded by [BATTERY_STATUS_V2](../messages/development.md#BATTERY_STATUS_V2).
For more information see [RFC 0018 - Improved Battery Status Reporting](https://github.com/mavlink/rfcs/pull/19).
:::
zh/services/camera_v1.md
+2 -2
View File
@@ -12,7 +12,7 @@ The protocol can be used to control cameras attached to autopilot outputs or sta
## Standalone MAVLink cameras
A standalone MAVLink camera that needs to interact with a ground station must be able to send and recieve MAVLink messages from the ground station.
A standalone MAVLink camera that needs to interact with a ground station must be able to send and receive MAVLink messages from the ground station.
If the GCS and Camera are connected to the flight stack on different MAVLink channels then the flight stack will need to forward messages between them.
If the MAVLink camera does not emit the [CAMERA_TRIGGER](#CAMERA_TRIGGER) message on image capture then the flight stack may need to do this on its behalf.
@@ -31,7 +31,7 @@ A GCS should address the commands to the autopilot component, which will need to
The flight stack will also need to trigger the camera when the commands are found in a mission.
Note that a flight stack implementation can generally trigger attached cameras and emit a MAVLink command in missions.
If a connected camera and MAVLink camera are connected, both with be triggered.
If a connected camera and MAVLink camera are connected, both will be triggered.
## Message/Command Summary
zh/services/command.md
+5 -5
View File
@@ -13,7 +13,7 @@ If no acknowledgement is received the command must be automatically re-sent.
| 消息 | 描述 |
| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="COMMAND_INT"></a>[COMMAND_INT](../messages/common.md#COMMAND_INT) | Message for encoding a command ([MAV_CMD](#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). |
| <a id="COMMAND_LONG"></a>[COMMAND_LONG](../messages/common.md#COMMAND_LONG) | Message for encoding a command ([MAV_CMD](#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). |
| <a id="COMMAND_LONG"></a>[COMMAND_LONG](../messages/common.md#COMMAND_LONG) | Message for encoding a command ([MAV_CMD](#MAV_CMD)). The message 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). |
| <a id="COMMAND_ACK"></a>[COMMAND_ACK](../messages/common.md#COMMAND_ACK) | Command acknowledgement. Includes result (success, failure, still in progress) and may include progress information and additional detail about failure reasons. |
| <a id="COMMAND_CANCEL"></a>[COMMAND_CANCEL](../messages/common.md#COMMAND_CANCEL) | Cancel a long running command. |
@@ -85,8 +85,8 @@ sequenceDiagram;
### Long Running Commands {#long_running_commands}
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](../messages/common.md#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](#MAV_RESULT) of the operation: `MAV_RESULT_ACCEPTED`, `MAV_RESULT_FAILED`, `MAV_RESULT_CANCELLED`).
The drone reports its progress by sending `COMMAND_ACK` messages with [COMMAND_ACK.result=MAV_RESULT_IN_PROGRESS](../messages/common.md#MAV_RESULT_IN_PROGRESS) and the progress as a percentage in `COMMAND_ACK.progress` ([0-100] percent complete, 255 if progress not supplied).
When the operation completes, the drone must terminate with a `COMMAND_ACK` containing the final [result](#MAV_RESULT) of the operation: `MAV_RESULT_ACCEPTED`, `MAV_RESULT_FAILED`, `MAV_RESULT_CANCELLED`).
[![Mermaid Sequence: MAV_RESULT_IN_PROGRESS](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6IENPTU1BTkRfTE9ORygpXG4gICAgR0NTLT4-R0NTOiBTdGFydCB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgTm90ZSByaWdodCBvZiBHQ1M6IC4uLlxuICAgIERyb25lLT4-R0NTOiBDT01NQU5EX0FDSyhyZXN1bHQ9TUFWX1JFU1VMVF9BQ0NFUFRFRCkiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IEdDU1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgR0NTLT4-RHJvbmU6IENPTU1BTkRfTE9ORygpXG4gICAgR0NTLT4-R0NTOiBTdGFydCB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgRHJvbmUtPj5HQ1M6IENPTU1BTkRfQUNLKHJlc3VsdD1NQVZfUkVTVUxUX0lOX1BST0dSRVNTLHByb2dyZXNzPT8pXG4gICAgR0NTLT4-R0NTOiBTdGFydCAobG9uZ2VyKSB0aW1lb3V0XG4gICAgTm90ZSByaWdodCBvZiBHQ1M6IC4uLlxuICAgIERyb25lLT4-R0NTOiBDT01NQU5EX0FDSyhyZXN1bHQ9TUFWX1JFU1VMVF9BQ0NFUFRFRCkiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)
@@ -116,9 +116,9 @@ Generally though, the GCS should have a much increased timeout after receiving a
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).
If the same command is received 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.
The protocol allows for _different_ long running commands to run in parallel, if supported by the state machine of the receiving 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](#COMMAND_CANCEL), which might be used to cancel the first request).
## Location Commands and Frame Types
zh/services/component_metadata.md
+3 -3
View File
@@ -30,7 +30,7 @@ Information supplied by the service is assumed to be invariant after boot. There
| <a id="COMP_METADATA_TYPE"></a>[COMP_METADATA_TYPE](../messages/common.md#COMP_METADATA_TYPE) | Types of component metadata supported by the protocol - e.g. general information, parameter metadata, supported commands, events, peripherals, etc. The type identifiers are used in the "general" metadata file to identify the sections that provide information about each supported type of metadata. The type identifiers are used in the "general" metadata file to identify the sections that provide information about each supported type of metadata. |
:::info
[COMPONENT_INFORMATION](../messages/common.md#COMPONENT_INFORMATION) is not used by thie service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)).
[COMPONENT_INFORMATION](../messages/common.md#COMPONENT_INFORMATION) is not used by this service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)).
:::
## Component Information File Format (Schema) {#schema_files}
@@ -42,7 +42,7 @@ The component information file types and schema are (at time of writing):
| ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="COMP_METADATA_TYPE_GENERAL"></a>General metadata | [COMP_METADATA_TYPE_GENERAL](../messages/common.md#COMP_METADATA_TYPE_GENERAL) | [general.schema.json](https://github.com/mavlink/mavlink/blob/master/component_metadata/general.schema.json) | General information about the component including hardware/firmware vendor version. This metadata includes information about all the other metadata types are supported by the component and where their metadata files are located. General information about the component including hardware/firmware vendor version. This metadata includes information about all the other metadata types are supported by the component and where their metadata files are located. This metadata type must be supported if this protocol is supported and the file must be present on vehicle and delivered by MAVLink FTP. Note however that you never actually need to specify this type! Note however that you never actually need to specify this type! |
| <a id="COMP_METADATA_TYPE_PARAMETER"></a>Parameter metadata | [COMP_METADATA_TYPE_PARAMETER](../messages/common.md#COMP_METADATA_TYPE_PARAMETER) | [parameter.schema.json](https://github.com/mavlink/mavlink/blob/master/component_metadata/parameter.schema.json) | Information about parameters supported by the vehicle (on boot). |
| <a id="COMP_METADATA_TYPE_COMMANDS"></a> Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command paramters are supported in via the command protocol. |
| <a id="COMP_METADATA_TYPE_COMMANDS"></a> Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command parameters are supported via the command protocol. |
| <a id="COMP_METADATA_TYPE_PERIPHERALS"></a> Peripheral metadata | [COMP_METADATA_TYPE_PERIPHERALS](../messages/common.md#COMP_METADATA_TYPE_PERIPHERALS) | [peripherals.schema.json](https://github.com/mavlink/mavlink/blob/master/component_metadata/peripherals.schema.json) | Information about non-MAVLink peripherals connected to vehicle (on boot). |
| <a id="COMP_METADATA_TYPE_EVENTS"></a> Event metadata | [COMP_METADATA_TYPE_EVENTS](../messages/common.md#COMP_METADATA_TYPE_EVENTS) | TBD | Information about events interface support by the vehicle. |
| <a id="COMP_METADATA_TYPE_ACTUATORS"></a> Event metadata | [COMP_METADATA_TYPE_ACTUATORS](../messages/common.md#COMP_METADATA_TYPE_ACTUATORS) | [actuators.schema.json ](https://github.com/mavlink/mavlink/blob/master/component_metadata/actuators.schema.json) | Metadata for actuator configuration (motors, servos and vehicle geometry) and testing. |
@@ -262,7 +262,7 @@ The example repository is https://github.com/PX4/PX4-Metadata-Translations:
Schema _management_ has not yet been signed off.
### Guaranteed Availablility of Component Information
### Guaranteed Availability of Component Information
There is a concern that vehicles reliant on internet-hosted component information files may stop working if the hosting ceases.
zh/services/events.md
+1 -1
View File
@@ -50,7 +50,7 @@ The following key features are provided by the interface:
| Enum | 描述 |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="MAV_EVENT_CURRENT_SEQUENCE_FLAGS"></a>[MAV_EVENT_CURRENT_SEQUENCE_FLAGS](../messages/common.md#CURRENT_EVENT_SEQUENCE) | Flags for [CURRENT_EVENT_SEQUENCE](#CURRENT_EVENT_SEQUENCE). For exmaple, to indicate when the sequence has reset. |
| <a id="MAV_EVENT_CURRENT_SEQUENCE_FLAGS"></a>[MAV_EVENT_CURRENT_SEQUENCE_FLAGS](../messages/common.md#CURRENT_EVENT_SEQUENCE) | Flags for [CURRENT_EVENT_SEQUENCE](#CURRENT_EVENT_SEQUENCE). For example, to indicate when the sequence has reset. |
| <a id="MAV_EVENT_ERROR_REASON"></a>[MAV_EVENT_ERROR_REASON](../messages/common.md#MAV_EVENT_ERROR_REASON) | Reasons for an error, as provided in [RESPONSE_EVENT_ERROR](#RESPONSE_EVENT_ERROR). For example, common error would be that the event is not available (i.e. it has been discarded). |
## Implementations
zh/services/gimbal_v2.md
+6 -6
View File
@@ -178,7 +178,7 @@ It is possible for multiple components to want to control a gimbal at the same t
In order to start controlling a gimbal, a component first needs to send the [MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE](#MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE) command.
This allows setting which MAVLink component (set by system ID and component ID) is in primary control and which one is in secondary control.
The gimbal manager is to ignore any gimbal controls which come from MAVLink components that are not explicity set to "in control".
The gimbal manager is to ignore any gimbal controls which come from MAVLink components that are not explicitly set to "in control".
This should prevent conflicts between various inputs as long as all components are fair/co-operative when using the configure command.
To be co-operative entails the following rules:
@@ -203,7 +203,7 @@ A ground station can manually control a gimbal by sending [GIMBAL_MANAGER_SET_MA
This allows controlling the gimbal with either angles, or angular rates, using a normalized unit (-1..1).
The gimbal device is responsible for translating the input based on angle, speed, and "smoothness" settings.
This input can additionally be scaled by the gimbal manager depending on its state. For example, if the gimbal manager is on a camera and knows the current zoom level / focal length of the camera, it can scale the angular rate down to support smooth paning and tilting.
This input can additionally be scaled by the gimbal manager depending on its state. For example, if the gimbal manager is on a camera and knows the current zoom level / focal length of the camera, it can scale the angular rate down to support smooth panning and tilting.
#### Controlling Gimbal Angle and/or Angular Rate using MAVLink
@@ -232,7 +232,7 @@ This data is required by the _Gimbal Device_ attitude estimator (horizon compens
The gimbal device should send out its attitude and status in [GIMBAL_DEVICE_ATTITUDE_STATUS](#GIMBAL_DEVICE_ATTITUDE_STATUS) at a regular rate, e.g. 10 Hz.
This message is a meant as broadcast, so it's set to the GCS, _Gimbal Manager_, and all parties on the network (not just _Gimbal Manager_, like all other messages).
This message is a meant as broadcast, so it's sent to the GCS, _Gimbal Manager_, and all parties on the network (not just _Gimbal Manager_, like all other messages).
### Custom Gimbal Device Settings
@@ -278,7 +278,7 @@ The recommendation is to make it configurable using (for instance) a parameter.
A non-MAVLink gimbal needs to be connected to a gimbal manager, which then takes care of sending the gimbal device messages.
Since a non-MAVLink gimbal can't be addressed with a MAVLink component ID, the `gimbal_device_id` needs to be set to one of the magic values (1 to 6).
This signals that the gimbal manager also is also acting as the gimbal device.
This signals that the gimbal manager is also acting as the gimbal device.
Also see [how to address non-MAVLink gimbal devices](#non_mavlink_gimbal_device_addressing).
@@ -350,7 +350,7 @@ This is the set of messages/enums for communication between gimbal manager and g
## Sequences
Depicted below are message sequences for some common scenarious.
Depicted below are message sequences for some common scenarios.
### Discovery
@@ -408,7 +408,7 @@ sequenceDiagram
[![](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgcGFydGljaXBhbnQgR3JvdW5kIFN0YXRpb25cbiAgICBwYXJ0aWNpcGFudCBHaW1iYWwgTWFuYWdlclxuICAgIHBhcnRpY2lwYW50IEdpbWJhbCBEZXZpY2VcbiAgICBHcm91bmQgU3RhdGlvbi0-PkdpbWJhbCBNYW5hZ2VyOiBNQVZfQ01EX0RPX1NFVF9ST0lfTE9DQVRJT05cbiAgICBHaW1iYWwgTWFuYWdlci0-Pkdyb3VuZCBTdGF0aW9uOiBDT01NQU5EX0FDS1xuICAgIEdpbWJhbCBNYW5hZ2VyLT4-R2ltYmFsIERldmljZTogR0lNQkFMX0RFVklDRV9TRVRfQVRUSVRVREUgKHN0cmVhbSlcbiAgICBHaW1iYWwgRGV2aWNlLT4-R2ltYmFsIE1hbmFnZXI6IEdJTUJBTF9ERVZJQ0VfQVRUSVRVREVfU1RBVFVTIChzdHJlYW0pXG4gICAgR2ltYmFsIERldmljZS0-Pkdyb3VuZCBTdGF0aW9uOiBHSU1CQUxfREVWSUNFX0FUVElUVURFX1NUQVRVUyAoc3RyZWFtKVxuICAgIEdyb3VuZCBTdGF0aW9uLT4-R2ltYmFsIE1hbmFnZXI6IE1BVl9DTURfRE9fU0VUX1JPSV9OT05FXG4gICAgR2ltYmFsIE1hbmFnZXItPj5Hcm91bmQgU3RhdGlvbjogQ09NTUFORF9BQ0siLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgcGFydGljaXBhbnQgR3JvdW5kIFN0YXRpb25cbiAgICBwYXJ0aWNpcGFudCBHaW1iYWwgTWFuYWdlclxuICAgIHBhcnRpY2lwYW50IEdpbWJhbCBEZXZpY2VcbiAgICBHcm91bmQgU3RhdGlvbi0-PkdpbWJhbCBNYW5hZ2VyOiBNQVZfQ01EX0RPX1NFVF9ST0lfTE9DQVRJT05cbiAgICBHaW1iYWwgTWFuYWdlci0-Pkdyb3VuZCBTdGF0aW9uOiBDT01NQU5EX0FDS1xuICAgIEdpbWJhbCBNYW5hZ2VyLT4-R2ltYmFsIERldmljZTogR0lNQkFMX0RFVklDRV9TRVRfQVRUSVRVREUgKHN0cmVhbSlcbiAgICBHaW1iYWwgRGV2aWNlLT4-R2ltYmFsIE1hbmFnZXI6IEdJTUJBTF9ERVZJQ0VfQVRUSVRVREVfU1RBVFVTIChzdHJlYW0pXG4gICAgR2ltYmFsIERldmljZS0-Pkdyb3VuZCBTdGF0aW9uOiBHSU1CQUxfREVWSUNFX0FUVElUVURFX1NUQVRVUyAoc3RyZWFtKVxuICAgIEdyb3VuZCBTdGF0aW9uLT4-R2ltYmFsIE1hbmFnZXI6IE1BVl9DTURfRE9fU0VUX1JPSV9OT05FXG4gICAgR2ltYmFsIE1hbmFnZXItPj5Hcm91bmQgU3RhdGlvbjogQ09NTUFORF9BQ0siLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)
ROI can be started using a command and should also be stopped again with a command. The ROI command is translated to a gimbal attitude in the the gimbal manager.
ROI can be started using a command and should also be stopped again with a command. The ROI command is translated to a gimbal attitude in the gimbal manager.
### Attitude Set During Mission
zh/services/mission.md
+5 -5
View File
@@ -107,7 +107,7 @@ The following messages and enums are used by the service.
The legacy version of the protocol also supported [MISSION_REQUEST](../messages/common.md#MISSION_REQUEST) for requesting that a mission be sent as a sequence of [MISSION_ITEM](../messages/common.md#MISSION_ITEM) messages.
Both `MISSION_REQUEST` and `MISSION_ITEM` messages are now deprecated, and should no longer be sent.
If `MISSION_REQUEST` is recieved the system should instead respond with [MISSION_ITEM_INT](#MISSION_ITEM_INT) items (as though it received [MISSION_REQUEST_INT](#MISSION_REQUEST_INT)).
If `MISSION_REQUEST` is received the system should instead respond with [MISSION_ITEM_INT](#MISSION_ITEM_INT) items (as though it received [MISSION_REQUEST_INT](#MISSION_REQUEST_INT)).
## Frames & Positional Information
@@ -176,7 +176,7 @@ The only expectation is that the scheme used makes it unlikely that the GCS will
On upload, the generated ID is sent to the GCS in the final part of the upload sequence in the [MISSION_ACK.opaque_id](#MISSION_ACK) field.
On download, the stored ID is sent to the GCS in the [MISSION_COUNT.opaque_id](#MISSION_COUNT) field.
The GCS should store the value of the ID from the flight stack as the "current id" for whatever part of the plan was uploaded/download.
The GCS should store the value of the ID from the flight stack as the "current id" for whatever part of the plan was uploaded/downloaded.
It can then monitor `MISSION_CURRENT`, and check its cached values against the current plan ids to determine whether it has a matching mission, or needs to download the mission from the vehicle.
### Upload a Mission to the Vehicle {#uploading_mission}
@@ -340,7 +340,7 @@ In more detail, the sequence of operations is:
1. GCS/API sends [MISSION_CLEAR_ALL](../messages/common.md#MISSION_CLEAR_ALL)
- A [timeout](#timeout) is started for the GCS to wait on `MISSION_ACK` from Drone.
2. Drone receives the message, and clears the mission from storage.
3. Drone responds with [MISSION_ACK](../messages/common.md#MISSION_ACK) with result `type` of [MAV_MISSION_ACCEPTED](../messages/common.md#MAV_MISSION_ACCEPTED)[MAV_MISSION_RESULT](../messages/common.md#MAV_MISSION_RESULT).
3. Drone responds with [MISSION_ACK](../messages/common.md#MISSION_ACK) with result `type` of [MAV_MISSION_ACCEPTED](../messages/common.md#MAV_MISSION_ACCEPTED) indicating success.
4. GCS receives `MISSION_ACK` and clears its own stored information about the mission.
The operation is now complete.
@@ -382,7 +382,7 @@ An operation may also complete with an error - `MISSION_ACK.type` set to [MAV_MI
This can occur in response to any message/anywhere in the sequence.
Errors are considered unrecoverable.
In an error is sent, both ends of the system should reset themselves to the idle state and the current state of the mission on the vehicle should be unaltered.
If an error is sent, both ends of the system should reset themselves to the idle state and the current state of the mission on the vehicle should be unaltered.
Note:
@@ -427,7 +427,7 @@ The direction of loiter for `MAV_CMD_NAV_LOITER_UNLIM` can be set using `param4`
The remaining parameters (xtrack and heading) apply only to forward flying aircraft (not multicopters!)
:::
Xtrack and heading define the location at which a forward flying (fixed wing) vehicle will _exit the loiter circle, and its path to the next waypoint_ (these apply only to apply to only `MAV_CMD_NAV_LOITER_TIME` and `MAV_CMD_NAV_LOITER_TURNS`).
Xtrack and heading define the location at which a forward flying (fixed wing) vehicle will _exit the loiter circle, and its path to the next waypoint_ (these apply only to `MAV_CMD_NAV_LOITER_TIME` and `MAV_CMD_NAV_LOITER_TURNS`).
| Param (:Label) | 描述 | Units |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
zh/services/offboard_control.md
+1 -1
View File
@@ -13,7 +13,7 @@ The particular types of setpoints that are supported, if any, depend on the vehi
| 消息 | 描述 |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| <a id="SET_POSITION_TARGET_LOCAL_NED"></a>[SET_POSITION_TARGET_LOCAL_NED](../messages/common.md#SET_POSITION_TARGET_LOCAL_NED) | Sets a desired vehicle position, velocity, and/or accelaration setpoint in a local north-east-down coordinate frame. |
| <a id="SET_POSITION_TARGET_LOCAL_NED"></a>[SET_POSITION_TARGET_LOCAL_NED](../messages/common.md#SET_POSITION_TARGET_LOCAL_NED) | Sets a desired vehicle position, velocity, and/or acceleration setpoint in a local north-east-down coordinate frame. |
| <a id="SET_POSITION_TARGET_GLOBAL_INT"></a>[SET_POSITION_TARGET_GLOBAL_INT](../messages/common.md#SET_POSITION_TARGET_GLOBAL_INT) | Sets a desired vehicle position, velocity, and/or acceleration in a global coordinate system (WGS84) |
| <a id="SET_ATTITUDE_TARGET"></a>[SET_ATTITUDE_TARGET](../messages/common.md#SET_ATTITUDE_TARGET) | Sets a desired vehicle attitude. |
| <a id="POSITION_TARGET_LOCAL_NED"></a>[POSITION_TARGET_LOCAL_NED](../messages/common.md#POSITION_TARGET_LOCAL_NED) | Publishes current local NED target (set by `SET_POSITION_TARGET_LOCAL_NED`). |
zh/services/parameter.md
+2 -2
View File
@@ -48,7 +48,7 @@ Parameters names/ids are set in the `param_id` field of messages where they are
The `param_id` string can store up to 16 characters.
The string is terminated with a NULL (`\0`) character if there are less than 16 human-readable chars, and without a null termination byte if the length is exactly 16 chars.
## Parameter Encoding
## Parameter Encoding {#parameter_encoding}
Parameter values are encoded in the `param_value` field, an IEE754 single-precision, 4 byte, floating point value (see [PARAM_SET](#PARAM_SET) and [PARAM_VALUE](#PARAM_VALUE)).
The `param_type` ([MAV_PARAM_TYPE](../messages/common.md#MAV_PARAM_TYPE)) is used to indicate the actual type of the data, so that it can be decoded by the recipient.
@@ -58,7 +58,7 @@ Two encoding approaches are supported:
- **Byte-wise encoding:** The parameter's bytes are copied directly into the bytes used for the field.
A 32-bit integer is sent as 32 bits of data.
- **C-style cast:** The parameter value is converted to a `float`. This may result in some loss of precision as a `float` can represent an integer with up to 24 bits of pecision.
- **C-style cast:** The parameter value is converted to a `float`. This may result in some loss of precision as a `float` can represent an integer with up to 24 bits of precision.
Byte wise encoding is recommended as it allows very large integers to be exchanged (e.g. 1E7 scaled integers can be useful for encoding some types of data, but lose precision if cast directly to floats).
zh/services/payload.md
+1 -1
View File
@@ -39,7 +39,7 @@ MAVLink has a number of commands for setting actuator outputs. These can be used
## Payload Deployment Commands
These commands can be used to deploy a payload at a specfic location, controlling the approach and land behaviour.
These commands can be used to deploy a payload at a specific location, controlling the approach and land behaviour.
| 消息 | 描述 |
| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
zh/services/timesync.md
+1 -1
View File
@@ -61,7 +61,7 @@ This allows filtering of the response to a particular system (but not component)
:::
:::info
Version 2 makes adds the target address, so a syncing system can filter on just the responses to its requests.
Version 2 adds the target address, so a syncing system can filter on just the responses to its requests.
:::
## Implementations
zh/services/traffic_management.md
+2 -2
View File
@@ -1,4 +1,4 @@
# Traffic Managment and Avoidance (UTM/ADSB)
# Traffic Management and Avoidance (UTM/ADSB)
Air traffic management and avoidance systems enable vehicles to share their position and planned path or trajectory with other vehicles (and ground stations), allowing them to take appropriate action to avoid collisions.
@@ -15,7 +15,7 @@ There are two main traffic management systems supported by MAVLink:
FLARM is a transponder-based system that integrates with MAVLink using the ADS-B messages.
:::
The two systems share significant overlap and have very similar messages. The two systems share sigificant overlap and have very similar messages. Both have a single message that encapsulates the vehicle position and trajectory: [UTM_GLOBAL_POSITION](#UTM_GLOBAL_POSITION) and [ADSB_VEHICLE](#ADSB_VEHICLE). A flight controller will typically recieve these messages from the appropriate transponder or service, and may also publish them to a transponder or service. A flight controller will typically recieve these messages from the appropriate transponder or service, and may also publish them to a transponder or service.
The two systems share significant overlap and have very similar messages. The two systems share sigificant overlap and have very similar messages. Both have a single message that encapsulates the vehicle position and trajectory: [UTM_GLOBAL_POSITION](#UTM_GLOBAL_POSITION) and [ADSB_VEHICLE](#ADSB_VEHICLE). A flight controller will typically recieve these messages from the appropriate transponder or service, and may also publish them to a transponder or service. A flight controller will typically receive these messages from the appropriate transponder or service, and may also publish them to a transponder or service.
::: info The [Open Drone ID](https://mavlink.io/en/services/opendroneid.html) service provides additional information about vehicle identity. This is still a "work in progress", and there are no known MAVLink implementations, :::