diff --git a/en/contributing/contributing.md b/en/contributing/contributing.md index c017dbdee..91a91adcb 100644 --- a/en/contributing/contributing.md +++ b/en/contributing/contributing.md @@ -47,7 +47,7 @@ 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. diff --git a/en/guide/mavlink_2.md b/en/guide/mavlink_2.md index 6d86e1620..7941a82d8 100644 --- a/en/guide/mavlink_2.md +++ b/en/guide/mavlink_2.md @@ -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. diff --git a/en/guide/message_signing.md b/en/guide/message_signing.md index b563b78a0..5355c8952 100644 --- a/en/guide/message_signing.md +++ b/en/guide/message_signing.md @@ -154,7 +154,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). diff --git a/en/guide/packet_loss.md b/en/guide/packet_loss.md index 75c73ff77..ae72ec9ee 100644 --- a/en/guide/packet_loss.md +++ b/en/guide/packet_loss.md @@ -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. diff --git a/en/guide/serialization.md b/en/guide/serialization.md index 14659f16d..54b0f3e39 100644 --- a/en/guide/serialization.md +++ b/en/guide/serialization.md @@ -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 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 diff --git a/en/guide/wireshark.md b/en/guide/wireshark.md index 11c51d3cb..be01dcaa0 100644 --- a/en/guide/wireshark.md +++ b/en/guide/wireshark.md @@ -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). -1. Build libraries for your target dialect, specifing `WLua` as the target language. +1. 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: diff --git a/en/mavgen_c/index.md b/en/mavgen_c/index.md index ed8ba8b52..4a7aa3771 100644 --- a/en/mavgen_c/index.md +++ b/en/mavgen_c/index.md @@ -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`. diff --git a/en/mavgen_python/howto_requestmessages.md b/en/mavgen_python/howto_requestmessages.md index e6a9c78f9..5116ea1a9 100644 --- a/en/mavgen_python/howto_requestmessages.md +++ b/en/mavgen_python/howto_requestmessages.md @@ -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 diff --git a/en/services/arm_authorization.md b/en/services/arm_authorization.md index 0dc69c0c0..963fb7b31 100644 --- a/en/services/arm_authorization.md +++ b/en/services/arm_authorization.md @@ -7,7 +7,7 @@ This is required to comply with [NASA UTM](https://utm.arc.nasa.gov/), but may a ## Authorization Flow -[![Mermaid Squence: Authorization Flow](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ) +[![Mermaid Sequence: Authorization Flow](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ) @@ -41,7 +41,7 @@ sequenceDiagram; Drone->>Arm authorizer: COMMAND_LONG command=MAV_CMD_ARM_AUTHORIZATION_REQUEST Arm authorizer->>Drone: COMMAND_ACK result=MAV_RESULT_IN_PROGRESS Arm authorizer->>Drone: (optional)Request information about mission, battery level and etc. - Arm authorizer->>Internet: (optional)Request information about weather, aerospace trafic and etc. + Arm authorizer->>Internet: (optional)Request information about weather, aerospace traffic and etc. Arm authorizer->>Drone: COMMAND_ACK command=MAV_CMD_ARM_AUTHORIZATION_REQUEST result=ACCEPTED, TEMPORARILY_REJECTED or DENIED Drone->>Remote control/QCS: QCS STATUSTEXT text=Arm authorization was approved or denied @@ -65,7 +65,7 @@ COMMAND_ACK command=MAV_CMD_ARM_AUTHORIZATION_REQUEST result=ACCEPTED, TEMPORARILY_REJECTED or DENIED progress/result_param1=if result is TEMPORARILY_REJECTED or DENIED the reason should be set MAV_ARM_AUTH_DENIED_REASON otherwise it should be set as 0 -result_param2=if result is ACCEPTED the it should be set with the time in seconds that this authorization is valid otherwise an aditional information about why it was denied should be set. example: for result_param1=MAV_ARM_AUTH_DENIED_REASON_INVALID_WAYPOINT or MAV_ARM_AUTH_DENIED_REASON_AIRSPACE_IN_USE it may have the index of the waypoint that caused it to be denied. +result_param2=if result is ACCEPTED the it should be set with the time in seconds that this authorization is valid otherwise an additional information about why it was denied should be set. example: for result_param1=MAV_ARM_AUTH_DENIED_REASON_INVALID_WAYPOINT or MAV_ARM_AUTH_DENIED_REASON_AIRSPACE_IN_USE it may have the index of the waypoint that caused it to be denied. target_system=system id of the drone target_component=component id of the drone ``` diff --git a/en/services/camera.md b/en/services/camera.md index 903b87940..03d83dc13 100644 --- a/en/services/camera.md +++ b/en/services/camera.md @@ -10,7 +10,7 @@ The older protocol enables camera triggering, but does not support other feature ::: ::: warning -We are transitioning from specific request commands to a single generic requestor. +We are transitioning from specific request commands to a single generic requester. GCS and MAVLink SDKs/apps should support both approaches as we migrate to exclusive use of the new method (documented here). For more information see [Migration Notes for GCS & Camera Servers](#migration-notes-for-gcs--mavlink-sdks). ::: @@ -411,7 +411,7 @@ After starting camera tracking you should call [MAV_CMD_SET_MESSAGE_INTERVAL](.. This message contains information about the tracked point/rectangle in an image, and may be used by the receiving system to determine the location of the target (alongside other information like the [CAMERA_FOV_STATUS](#CAMERA_FOV_STATUS)). If geo-tracking status information is supported (indicated by `CAMERA_CAP_FLAGS_HAS_TRACKING_GEO_STATUS`) you should also call [MAV_CMD_SET_MESSAGE_INTERVAL](../messages/common.md#MAV_CMD_SET_MESSAGE_INTERVAL) to stream [CAMERA_TRACKING_GEO_STATUS](#CAMERA_TRACKING_GEO_STATUS) at your desired rate. -This message provides the location of the target in physical co-ordinates that can be passed to a gimbal. +This message provides the location of the target in physical coordinates that can be passed to a gimbal. To stop any kind of tracking, a GCS uses the [MAV_CMD_CAMERA_STOP_TRACKING](#MAV_CMD_CAMERA_STOP_TRACKING) command. After stopping tracking you should call `MAV_CMD_SET_MESSAGE_INTERVAL` to stop streaming `CAMERA_TRACKING_IMAGE_STATUS` and `CAMERA_TRACKING_GEO_STATUS` (set their rates to 0). @@ -434,7 +434,7 @@ The steps are: The sequence above just shows point tracking. 1. Set the desired rates (intervals) for streaming the tracking status messages. 1. Camera streams [CAMERA_TRACKING_IMAGE_STATUS](#CAMERA_TRACKING_IMAGE_STATUS) and/or [CAMERA_TRACKING_GEO_STATUS](#CAMERA_TRACKING_GEO_STATUS). - These are used to provide camera targetting information. + These are used to provide camera targeting information. 1. To stop tracking, a GCS uses the [MAV_CMD_CAMERA_STOP_TRACKING](#MAV_CMD_CAMERA_STOP_TRACKING) command. The streaming intervals must also be set to zero. @@ -476,7 +476,7 @@ Other components like a GCS will typically only use the camera `BATTERY_STATUS.b | [MAV_CMD_VIDEO_STOP_CAPTURE](../messages/common.md#MAV_CMD_VIDEO_STOP_CAPTURE) | Send command to stop video capture. | | [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) | Send command to start video streaming for the given Stream ID (`stream_id`.) This is mostly for streaming protocols that _push_ a stream. If your camera uses a connection based streaming configuration (RTSP, TCP, etc.), you may ignore it if you don't need it but note that you still must ACK the command, like all `MAV_CMD_XXX` commands. When using a connection based streaming configuration, the GCS will connect the stream from its side. When a camera offers more than one stream and the user switches from one stream to another, the GCS will send a [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) command targeting the current Stream ID followed by a [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) targeting the newly selected Stream ID. | | [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) | Send command to stop video streaming for the given Stream ID (`stream_id`.) This is mostly for streaming protocols that _push_ a stream. If your camera uses a connection based streaming configuration (RTSP, TCP, etc.), you may ignore it if you don't need it but note that you still must ACK the command, like all `MAV_CMD_XXX` commands. When using a connection based streaming configuration, the GCS will disconnect the stream from its side. When a camera offers more than one stream and the user switches from one stream to another, the GCS will send a [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) command targeting the current Stream ID followed by a [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) targeting the newly selected Stream ID. | -| [MAV_CMD_CAMERA_TRACK_POINT](../messages/common.md#MAV_CMD_CAMERA_TRACK_POINT) | Initate visual point tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_POINT](#CAMERA_CAP_FLAGS) is set). | +| [MAV_CMD_CAMERA_TRACK_POINT](../messages/common.md#MAV_CMD_CAMERA_TRACK_POINT) | Initiate visual point tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_POINT](#CAMERA_CAP_FLAGS) is set). | | [MAV_CMD_CAMERA_TRACK_RECTANGLE](../messages/common.md#MAV_CMD_CAMERA_TRACK_RECTANGLE) | Initiate visual rectangle tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_RECTANGLE](#CAMERA_CAP_FLAGS) is set). | | [MAV_CMD_CAMERA_STOP_TRACKING](../messages/common.md#MAV_CMD_CAMERA_STOP_TRACKING) | Stop camera tracking (as initiated using `MAV_CMD_CAMERA_TRACK_POINT` or `MAV_CMD_CAMERA_TRACK_RECTANGLE`). | @@ -510,7 +510,7 @@ These commands have been deprecated, replaced by the generic requester command [ The original definition of this protocol used specific commands to query for each type of information requested from the camera: [MAV_CMD_REQUEST_CAMERA_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_CAMERA_INFORMATION) (for [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION)), [MAV_CMD_REQUEST_CAMERA_SETTINGS](../messages/common.md#MAV_CMD_REQUEST_CAMERA_SETTINGS), [MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS](../messages/common.md#MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS), [MAV_CMD_REQUEST_VIDEO_STREAM_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_VIDEO_STREAM_INFORMATION), [MAV_CMD_REQUEST_STORAGE_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_STORAGE_INFORMATION). -The latest version replaces all of these specific commands with the general requestor [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE). +The latest version replaces all of these specific commands with the general requester [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE). The transition works like this: diff --git a/en/services/camera_def.md b/en/services/camera_def.md index 04cae3612..613e5dbd9 100644 --- a/en/services/camera_def.md +++ b/en/services/camera_def.md @@ -258,7 +258,7 @@ This example also tells the GCS not to display this parameter to the user (`cont #### Param Ranges -It is also possible to define param ranges without individual options, but by specifiying the minimum, maximum, and optionally a step size: +It is also possible to define param ranges without individual options, but by specifying the minimum, maximum, and optionally a step size: ```xml diff --git a/en/services/camera_v1.md b/en/services/camera_v1.md index 9c08adb5e..aff6929a5 100644 --- a/en/services/camera_v1.md +++ b/en/services/camera_v1.md @@ -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. diff --git a/en/services/command.md b/en/services/command.md index 2bf06f50e..b3bd29287 100644 --- a/en/services/command.md +++ b/en/services/command.md @@ -13,20 +13,20 @@ If no acknowledgement is received the command must be automatically re-sent. | Message | Description | | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [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). | -| [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). | +| [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 coordinates is implementation dependent. Any command may be packaged in this message, but there may be some loss of precision for positional coordinates (latitude, longitude). | | [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. | | [COMMAND_CANCEL](../messages/common.md#COMMAND_CANCEL) | Cancel a long running command. | | Enum | Description | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | [MAV_CMD](../messages/common.md#mav_commands) | Commands to be executed/sent in the command messages. | -| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame. Used in `COMMAND_INT` to specify the co-ordinate frame of any positional parameters. | +| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame. Used in `COMMAND_INT` to specify the coordinate frame of any positional parameters. | | [MAV_RESULT](../messages/common.md#MAV_RESULT) | Result of command, included in [COMMAND_ACK.result](#COMMAND_ACK). | ## Use COMMAND_INT or COMMAND_LONG? `COMMAND_INT` should be used when sending commands that contain positional or navigation information, if supported by the flight stack for the particular command. -This is because it allows the co-ordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". +This is because it allows the coordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". In addition latitudes/longitudes can be sent with greater precision in a `COMMAND_INT` as scaled integers in params 5 and 6 (than when sent in float values in `COMMAND_LONG`). `COMMAND_LONG` must be used for sending `MAV_CMD` commands that send float properties in parameters 5 and 6, as these values would be truncated to integers if sent in `COMMAND_INT`. @@ -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 diff --git a/en/services/component_information.md b/en/services/component_information.md index 3bf5266cf..217943361 100644 --- a/en/services/component_information.md +++ b/en/services/component_information.md @@ -35,7 +35,7 @@ There is no mechanism, for example, to provide an update if the set of supported | [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 the service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)). ::: ## Component Information File Format (Schema) {#schema_files} @@ -47,7 +47,7 @@ The component information file types and schema are (at time of writing): | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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! | | 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). | -| 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. | +| Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command parameters are supported in via the command protocol. | | 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). | | Event metadata | [COMP_METADATA_TYPE_EVENTS](../messages/common.md#COMP_METADATA_TYPE_EVENTS) | TBD | Information about events interface support by the vehicle. | | 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. | @@ -136,7 +136,7 @@ In summary: 1. The component will ACK the command and immediately send the requested `COMPONENT_METADATA` message (populated with URI and CRC for the general metadata file). - A `CMD_ACK` of anything other than `MAV_RESULT_ACCEPTED` indicates the protocol is not supported (sequence completes). 1. GCS waits for the `COMPONENT_METADATA` message - - If not recieved the GCS should resend the request (typically in the application level). + - If not received the GCS should resend the request (typically in the application level). - Once information is received: - the GCS checks if `COMPONENT_METADATA.file_crc` matches its cached CRC value. If so, there is no need to download the [general metadata file](#COMP_METADATA_TYPE_GENERAL) (or other files it references) as it has not changed since the last download. @@ -267,7 +267,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. diff --git a/en/services/events.md b/en/services/events.md index b20026849..d8a6551e0 100644 --- a/en/services/events.md +++ b/en/services/events.md @@ -50,7 +50,7 @@ The following key features are provided by the interface: | Enum | Description | | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| [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. | +| [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. | | [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 diff --git a/en/services/ftp.md b/en/services/ftp.md index 8711f58f9..39c59d351 100644 --- a/en/services/ftp.md +++ b/en/services/ftp.md @@ -65,7 +65,7 @@ The opcodes that may be sent by the GCS (client) to the drone (server) are liste | Opcode | Name | Description | | ------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | None | Ignored, always ACKed | -| 1 | TerminateSession | Terminates open Read `session`.
- Closes the file associated with (`session`) and frees the session ID for re-use. | +| 1 | TerminateSession | Terminates open Read `session`.
- Closes the file associated with (`session`) and frees the session ID for reuse. | | 2 | ResetSessions | Terminates _all_ open read sessions.
- Clears all state held by the drone (server); closes all open files, etc.
- Sends an ACK reply with no data. | | 3 | [ListDirectory](#list_directory) | List directory entry information (files, folders etc.) in ``, starting from a specified entry index (``).
- Response is an ACK packet with one or more entries on success, otherwise a NAK packet with an error code.
- Completion is indicated by a NACK with EOF in response to a requested index (`offset`) beyond the list of entries.
- The directory is closed after the operation, so this leaves no state on the server. | | 4 | [OpenFileRO](#reading-a-file) | Opens file at `` for reading, returns ``
- The `path` is stored in the [payload](#payload) `data`. The drone opens the file (`path`) and allocates a _session number_. The file must exist.
- An ACK packet must include the allocated `session` and the data size of the file to be opened (`size`)
- A NAK packet must contain [error information](#error_codes) . Typical error codes for this command are `NoSessionsAvailable`, `FileExists`.
- The file remains open after the operation, and must eventually be closed by `Reset` or `Terminate`. | @@ -208,7 +208,7 @@ After opening a file for reading, it is read in "bursts". Each burst delivers a part of the file as a stream of messages. The last message in the burst is indicated by setting `burst_complete=1` (without any ACKs). -The client tracks the recieved chunks. +The client tracks the received chunks. On completion of the burst (or the file), if there are any missing parts of the file it can request them using either another burst or using [ReadFile](#reading-a-file-readfile). ::: info diff --git a/en/services/gimbal.md b/en/services/gimbal.md index cecabcdef..1954ea07a 100644 --- a/en/services/gimbal.md +++ b/en/services/gimbal.md @@ -45,7 +45,7 @@ This version of the gimbal protocol (v1) has a number of known issues: - Unclear “stabilize” flags in `DO_MOUNT_CONFIGURE`. - Confusing and unimplemented “absolute” flags in `DO_MOUNT_CONFIGURE`. - Unclear when to use `DO_MOUNT_CONTROL` or `DO_MOUNT_CONFIGURE`. -- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targetting. +- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targeting. - Unusual param number for `DO_MOUNT_CONTROL`. - The GPS mode in `DO_MOUNT_CONTROL` conflicts with `DO_SET_ROI_*` commands. - MOUNT naming makes discovery hard. diff --git a/en/services/gimbal_v2.md b/en/services/gimbal_v2.md index e651fe135..04bea03f9 100644 --- a/en/services/gimbal_v2.md +++ b/en/services/gimbal_v2.md @@ -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: @@ -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 diff --git a/en/services/image_transmission.md b/en/services/image_transmission.md index b25c746c2..3de7901c5 100644 --- a/en/services/image_transmission.md +++ b/en/services/image_transmission.md @@ -3,7 +3,7 @@ ::: warning The [Camera Protocol](../services/camera.md) and [MAVLink FTP](../services/ftp.md) are recommended for sending images, video and files. -This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transfering small images over a low bandwidth channel from an optical flow sensor to a GCS). +This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transferring small images over a low bandwidth channel from an optical flow sensor to a GCS). ::: The image transmission protocol uses MAVLink as the communication channel to transport any kind of image (raw images, Kinect data, etc.) from one MAVLink node to another. diff --git a/en/services/manual_control.md b/en/services/manual_control.md index 0239f63ee..388ac24c0 100644 --- a/en/services/manual_control.md +++ b/en/services/manual_control.md @@ -57,7 +57,7 @@ Channels can be mapped to firmware parameters using [`PARAM_MAP_RC`](../messages It's worth noting that the generality of RC channels control is a double-edged sword. It is incredibly versatile, and can be used to provide support for several arbitrary control axes, but the user-defined in-vehicle nature of the mapped parameters means additional setup is frequently required for compatibility with GCSs, and there are no guarantees that multiple vehicles running the same firmware will have the same channel-parameter mapping. -This is a similar issue to the `MANUAL_CONTROL` buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targetted MAVLink commands where possible. +This is a similar issue to the `MANUAL_CONTROL` buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targeted MAVLink commands where possible. ## Implementations @@ -93,4 +93,4 @@ ArduPilot Implementations: ## Future Extensions -Future extensions are likely to be handled with additional targetted [MAVLink commands](./command.md) rather than mapping functionality in the flight controller (i.e. handling more complex inputs in the GCS to reduce vehicle firmware complexity). +Future extensions are likely to be handled with additional targeted [MAVLink commands](./command.md) rather than mapping functionality in the flight controller (i.e. handling more complex inputs in the GCS to reduce vehicle firmware complexity). diff --git a/en/services/mission.md b/en/services/mission.md index b7f901537..723ca21f3 100644 --- a/en/services/mission.md +++ b/en/services/mission.md @@ -99,7 +99,7 @@ The following messages and enums are used by the service. | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | [MAV_MISSION_TYPE](../messages/common.md#MAV_MISSION_TYPE) | [Mission type](#mission_types) for message (mission, geofence, rallypoints). | | [MAV_MISSION_RESULT](../messages/common.md#MAV_MISSION_RESULT) | Used to indicate the success or failure reason for an operation (e.g. to upload or download a mission). This is carried in a [MISSION_ACK](#MISSION_ACK). | -| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Co-ordinate frame for position/velocity/acceleration data in the message. | +| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame for position/velocity/acceleration data in the message. | | [MAV_CMD](../messages/common.md#mav_commands) | [Mission Items](#mavlink_commands) (and MAVLink commands) sent in [MISSION_ITEM_INT](#MISSION_ITEM_INT). | ## Deprecated Types: MISSION_ITEM {#command_message_type} @@ -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 @@ -120,7 +120,7 @@ The table below shows that the positional parameters can be local (x, y, z), glo | param6 | `int32_t` | y | Longitude | | param7 | `float` | z | Altitude (global - relative or absolute) | -The co-ordinate frame of positional parameters is defined in the `MISSION_ITEM_INT.frame` field using a [MAV_FRAME](#MAV_FRAME) value. +The coordinate frame of positional parameters is defined in the `MISSION_ITEM_INT.frame` field using a [MAV_FRAME](#MAV_FRAME) value. The global frames are prefixed with `MAV_FRAME_GLOBAL_*`. Mission items should use frame variants that have the suffix `_INT`: e.g. `MAV_FRAME_GLOBAL_RELATIVE_ALT_INT`, `MAV_FRAME_GLOBAL_INT`, `MAV_FRAME_GLOBAL_TERRAIN_ALT_INT`. @@ -539,7 +539,7 @@ The following behaviour is not defined by the specification (but is still of int - ArduPilot performs some validation of fields when mission items are submitted. The validation code is common to all vehicles; mission items that are not understood by the vehicle type are accepted on upload but skipped during mission execution. -- ArduPilot preforms some vehicle-specific validation at mission runtime (e.g. of jump targets). +- ArduPilot performs some vehicle-specific validation at mission runtime (e.g. of jump targets). - A new mission can be uploaded while a mission is being executed. In this case the current waypoint will be executed to completion even if the waypoint sequence is different in the new mission (to get the new item you would need to reset the sequence or switch in/out of auto mode). - ArduPilot missions are not stored in an SD card and therefore have a vehicle/board-specific maximum mission size (as a benefit, on ArduPilot, missions can survive SD card failure in flight). diff --git a/en/services/offboard_control.md b/en/services/offboard_control.md index 0de0e1949..2748ca97d 100644 --- a/en/services/offboard_control.md +++ b/en/services/offboard_control.md @@ -5,7 +5,7 @@ The offboard control interface allows an external controller to send low-level a This is commonly used to provide external control of a real-time flight stack from a companion/mission computer, for example, in order to implement features such as obstacle avoidance or collision prevention. Generally setpoints are only obeyed in a specific flight-stack mode. -The flight stack requires the setpoints to be recieved for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received. +The flight stack requires the setpoints to be received for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received. The particular types of setpoints that are supported, if any, depend on the vehicle type and flight stack. @@ -13,7 +13,7 @@ The particular types of setpoints that are supported, if any, depend on the vehi | Message | Description | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | -| [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. | +| [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. | | [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) | | [SET_ATTITUDE_TARGET](../messages/common.md#SET_ATTITUDE_TARGET) | Sets a desired vehicle attitude. | | [POSITION_TARGET_LOCAL_NED](../messages/common.md#POSITION_TARGET_LOCAL_NED) | Publishes current local NED target (set by `SET_POSITION_TARGET_LOCAL_NED`). | diff --git a/en/services/parameter.md b/en/services/parameter.md index 9dc4c6537..d6299a7ab 100644 --- a/en/services/parameter.md +++ b/en/services/parameter.md @@ -141,7 +141,7 @@ If working with a non-compliant component, the risk of problems when working wit A GCS (or other component) that wants to [cache parameters](#parameter_caching) with a component and keep them synchronised, should first get all parameters, and then track any new parameter changes by monitoring for `PARAM_VALUE` messages (updating their internal list appropriately). -This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not recieved. +This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not received. This approach may fail for components that did not originate the change, as they will not know about updates they do not receive (i.e. if messages are dropped). A component may mitigate this risk by, for example, sending the `PARAM_VALUE` multiple times after a parameter is changed. @@ -241,7 +241,7 @@ sequenceDiagram; The sequence of operations is: 1. GCS (client) sends [PARAM_SET](../messages/common.md#PARAM_VALUE) specifying the param name to update and its new value (also target system/component and the param type). -1. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message). +1. GCS starts timeout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message). 1. Drone writes parameter and responds by _broadcasting_ a `PARAM_VALUE` containing the updated parameter value to all components/systems. ::: info diff --git a/en/services/parameter_ext.md b/en/services/parameter_ext.md index 5da9b3477..e18266bd5 100644 --- a/en/services/parameter_ext.md +++ b/en/services/parameter_ext.md @@ -263,7 +263,7 @@ sequenceDiagram; The sequence of operations is: 1. GCS (client) sends [PARAM_EXT_SET](../messages/common.md#PARAM_EXT_SET) specifying the param name to update and its new value (also target system/component and the param type). -1. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_EXT_ACK](../messages/common.md#PARAM_EXT_ACK) message). +1. GCS starts timeout waiting for acknowledgment (in the form of a [PARAM_EXT_ACK](../messages/common.md#PARAM_EXT_ACK) message). 1. Drone (starts to) write parameter and responds by _broadcasting_ a `PARAM_EXT_ACK`. - If the write succeeded the `PARAM_EXT_ACK` will contain a result of `PARAM_ACK_ACCEPTED` and the updated parameter value. - If the parameter was unknown or of an unsupported type `PARAM_EXT_ACK` will contain a result of `PARAM_ACK_VALUE_UNSUPPORTED` and the current parameter value will be XXXXX. diff --git a/en/services/payload.md b/en/services/payload.md index 566f104f6..3ef5b0352 100644 --- a/en/services/payload.md +++ b/en/services/payload.md @@ -49,7 +49,7 @@ Use the [commands for known payload types](#payload-specific-commands) where pos ## 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 | | ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------- | diff --git a/en/services/traffic_management.md b/en/services/traffic_management.md index 6ef62ce43..c68e51b77 100644 --- a/en/services/traffic_management.md +++ b/en/services/traffic_management.md @@ -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. @@ -19,7 +19,7 @@ There are two main traffic management systems supported by MAVLink: 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. +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. diff --git a/ko/SUMMARY.md b/ko/SUMMARY.md index 23167ac46..adf72bec5 100644 --- a/ko/SUMMARY.md +++ b/ko/SUMMARY.md @@ -64,7 +64,7 @@ - [Component Metadata Protocol (WIP)](services/component_information.md) - [MAVLink Id Assignment (sysid, compid)](services/mavlink_id_assignment.md) - [Payload Protocols](services/payload.md) - - [Traffic Managment (UTM/ADS-B)](services/traffic_management.md) + - [Traffic Management (UTM/ADS-B)](services/traffic_management.md) - [Events Interface (WIP)](services/events.md) - [Standard Flight Modes](services/standard_modes.md) - [Time Synchronization](services/timesync.md) diff --git a/ko/contributing/contributing.md b/ko/contributing/contributing.md index 6b4cb620f..02bfdde00 100644 --- a/ko/contributing/contributing.md +++ b/ko/contributing/contributing.md @@ -47,7 +47,7 @@ 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. diff --git a/ko/guide/mavlink_2.md b/ko/guide/mavlink_2.md index 02fb241a3..ef6bf769e 100644 --- a/ko/guide/mavlink_2.md +++ b/ko/guide/mavlink_2.md @@ -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. diff --git a/ko/guide/message_signing.md b/ko/guide/message_signing.md index e05637ec6..9d5e02452 100644 --- a/ko/guide/message_signing.md +++ b/ko/guide/message_signing.md @@ -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). diff --git a/ko/guide/packet_loss.md b/ko/guide/packet_loss.md index 75c73ff77..ae72ec9ee 100644 --- a/ko/guide/packet_loss.md +++ b/ko/guide/packet_loss.md @@ -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. diff --git a/ko/guide/serialization.md b/ko/guide/serialization.md index 55b1af55c..f8a91daa8 100644 --- a/ko/guide/serialization.md +++ b/ko/guide/serialization.md @@ -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 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 diff --git a/ko/guide/wireshark.md b/ko/guide/wireshark.md index a4a4f9503..75abcb149 100644 --- a/ko/guide/wireshark.md +++ b/ko/guide/wireshark.md @@ -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: diff --git a/ko/mavgen_c/index.md b/ko/mavgen_c/index.md index 8f9e1bfd2..de16a1d37 100644 --- a/ko/mavgen_c/index.md +++ b/ko/mavgen_c/index.md @@ -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`. diff --git a/ko/mavgen_python/howto_requestmessages.md b/ko/mavgen_python/howto_requestmessages.md index e6a9c78f9..5116ea1a9 100644 --- a/ko/mavgen_python/howto_requestmessages.md +++ b/ko/mavgen_python/howto_requestmessages.md @@ -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 diff --git a/ko/services/arm_authorization.md b/ko/services/arm_authorization.md index 0dc69c0c0..963fb7b31 100644 --- a/ko/services/arm_authorization.md +++ b/ko/services/arm_authorization.md @@ -7,7 +7,7 @@ This is required to comply with [NASA UTM](https://utm.arc.nasa.gov/), but may a ## Authorization Flow -[![Mermaid Squence: Authorization Flow](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ) +[![Mermaid Sequence: Authorization Flow](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ) @@ -41,7 +41,7 @@ sequenceDiagram; Drone->>Arm authorizer: COMMAND_LONG command=MAV_CMD_ARM_AUTHORIZATION_REQUEST Arm authorizer->>Drone: COMMAND_ACK result=MAV_RESULT_IN_PROGRESS Arm authorizer->>Drone: (optional)Request information about mission, battery level and etc. - Arm authorizer->>Internet: (optional)Request information about weather, aerospace trafic and etc. + Arm authorizer->>Internet: (optional)Request information about weather, aerospace traffic and etc. Arm authorizer->>Drone: COMMAND_ACK command=MAV_CMD_ARM_AUTHORIZATION_REQUEST result=ACCEPTED, TEMPORARILY_REJECTED or DENIED Drone->>Remote control/QCS: QCS STATUSTEXT text=Arm authorization was approved or denied @@ -65,7 +65,7 @@ COMMAND_ACK command=MAV_CMD_ARM_AUTHORIZATION_REQUEST result=ACCEPTED, TEMPORARILY_REJECTED or DENIED progress/result_param1=if result is TEMPORARILY_REJECTED or DENIED the reason should be set MAV_ARM_AUTH_DENIED_REASON otherwise it should be set as 0 -result_param2=if result is ACCEPTED the it should be set with the time in seconds that this authorization is valid otherwise an aditional information about why it was denied should be set. example: for result_param1=MAV_ARM_AUTH_DENIED_REASON_INVALID_WAYPOINT or MAV_ARM_AUTH_DENIED_REASON_AIRSPACE_IN_USE it may have the index of the waypoint that caused it to be denied. +result_param2=if result is ACCEPTED the it should be set with the time in seconds that this authorization is valid otherwise an additional information about why it was denied should be set. example: for result_param1=MAV_ARM_AUTH_DENIED_REASON_INVALID_WAYPOINT or MAV_ARM_AUTH_DENIED_REASON_AIRSPACE_IN_USE it may have the index of the waypoint that caused it to be denied. target_system=system id of the drone target_component=component id of the drone ``` diff --git a/ko/services/camera.md b/ko/services/camera.md index 40c5dce4f..8a13f1e91 100644 --- a/ko/services/camera.md +++ b/ko/services/camera.md @@ -10,7 +10,7 @@ The older protocol enables camera triggering, but does not support other feature ::: :::warning -We are transitioning from specific request commands to a single generic requestor. +We are transitioning from specific request commands to a single generic requester. GCS and MAVLink SDKs/apps should support both approaches as we migrate to exclusive use of the new method (documented here). For more information see [Migration Notes for GCS & Camera Servers](#migration-notes-for-gcs--mavlink-sdks). ::: @@ -413,7 +413,7 @@ After starting camera tracking you should call [MAV_CMD_SET_MESSAGE_INTERVAL](.. This message contains information about the tracked point/rectangle in an image, and may be used by the receiving system to determine the location of the target (alongside other information like the [CAMERA_FOV_STATUS](#CAMERA_FOV_STATUS)). If geo-tracking status information is supported (indicated by `CAMERA_CAP_FLAGS_HAS_TRACKING_GEO_STATUS`) you should also call [MAV_CMD_SET_MESSAGE_INTERVAL](../messages/common.md#MAV_CMD_SET_MESSAGE_INTERVAL) to stream [CAMERA_TRACKING_GEO_STATUS](#CAMERA_TRACKING_GEO_STATUS) at your desired rate. -This message provides the location of the target in physical co-ordinates that can be passed to a gimbal. +This message provides the location of the target in physical coordinates that can be passed to a gimbal. To stop any kind of tracking, a GCS uses the [MAV_CMD_CAMERA_STOP_TRACKING](#MAV_CMD_CAMERA_STOP_TRACKING) command. After stopping tracking you should call `MAV_CMD_SET_MESSAGE_INTERVAL` to stop streaming `CAMERA_TRACKING_IMAGE_STATUS` and `CAMERA_TRACKING_GEO_STATUS` (set their rates to 0). @@ -436,7 +436,7 @@ The steps are: The sequence above just shows point tracking. 4. Set the desired rates (intervals) for streaming the tracking status messages. 5. Camera streams [CAMERA_TRACKING_IMAGE_STATUS](#CAMERA_TRACKING_IMAGE_STATUS) and/or [CAMERA_TRACKING_GEO_STATUS](#CAMERA_TRACKING_GEO_STATUS). - These are used to provide camera targetting information. + These are used to provide camera targeting information. 6. To stop tracking, a GCS uses the [MAV_CMD_CAMERA_STOP_TRACKING](#MAV_CMD_CAMERA_STOP_TRACKING) command. The streaming intervals must also be set to zero. @@ -478,7 +478,7 @@ Other components like a GCS will typically only use the camera `BATTERY_STATUS.b | [MAV_CMD_VIDEO_STOP_CAPTURE](../messages/common.md#MAV_CMD_VIDEO_STOP_CAPTURE) | Send command to stop video capture. | | [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) | Send command to start video streaming for the given Stream ID (`stream_id`.) This is mostly for streaming protocols that _push_ a stream. If your camera uses a connection based streaming configuration (RTSP, TCP, etc.), you may ignore it if you don't need it but note that you still must ACK the command, like all `MAV_CMD_XXX` commands. When using a connection based streaming configuration, the GCS will connect the stream from its side. When a camera offers more than one stream and the user switches from one stream to another, the GCS will send a [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) command targeting the current Stream ID followed by a [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) targeting the newly selected Stream ID. | | [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) | Send command to stop video streaming for the given Stream ID (`stream_id`.) This is mostly for streaming protocols that _push_ a stream. If your camera uses a connection based streaming configuration (RTSP, TCP, etc.), you may ignore it if you don't need it but note that you still must ACK the command, like all `MAV_CMD_XXX` commands. When using a connection based streaming configuration, the GCS will disconnect the stream from its side. When a camera offers more than one stream and the user switches from one stream to another, the GCS will send a [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) command targeting the current Stream ID followed by a [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) targeting the newly selected Stream ID. | -| [MAV_CMD_CAMERA_TRACK_POINT](../messages/common.md#MAV_CMD_CAMERA_TRACK_POINT) | Initate visual point tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_POINT](#CAMERA_CAP_FLAGS) is set). | +| [MAV_CMD_CAMERA_TRACK_POINT](../messages/common.md#MAV_CMD_CAMERA_TRACK_POINT) | Initiate visual point tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_POINT](#CAMERA_CAP_FLAGS) is set). | | [MAV_CMD_CAMERA_TRACK_RECTANGLE](../messages/common.md#MAV_CMD_CAMERA_TRACK_RECTANGLE) | Initiate visual rectangle tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_RECTANGLE](#CAMERA_CAP_FLAGS) is set). | | [MAV_CMD_CAMERA_STOP_TRACKING](../messages/common.md#MAV_CMD_CAMERA_STOP_TRACKING) | Stop camera tracking (as initiated using `MAV_CMD_CAMERA_TRACK_POINT` or `MAV_CMD_CAMERA_TRACK_RECTANGLE`). | @@ -512,7 +512,7 @@ These commands have been deprecated, replaced by the generic requester command [ The original definition of this protocol used specific commands to query for each type of information requested from the camera: [MAV_CMD_REQUEST_CAMERA_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_CAMERA_INFORMATION) (for [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION)), [MAV_CMD_REQUEST_CAMERA_SETTINGS](../messages/common.md#MAV_CMD_REQUEST_CAMERA_SETTINGS), [MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS](../messages/common.md#MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS), [MAV_CMD_REQUEST_VIDEO_STREAM_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_VIDEO_STREAM_INFORMATION), [MAV_CMD_REQUEST_STORAGE_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_STORAGE_INFORMATION). -The latest version replaces all of these specific commands with the general requestor [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE). +The latest version replaces all of these specific commands with the general requester [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE). The transition works like this: diff --git a/ko/services/camera_def.md b/ko/services/camera_def.md index 6a62375da..382a6ea24 100644 --- a/ko/services/camera_def.md +++ b/ko/services/camera_def.md @@ -258,7 +258,7 @@ This example also tells the GCS not to display this parameter to the user (`cont #### Param Ranges -It is also possible to define param ranges without individual options, but by specifiying the minimum, maximum, and optionally a step size: +It is also possible to define param ranges without individual options, but by specifying the minimum, maximum, and optionally a step size: ```xml diff --git a/ko/services/camera_v1.md b/ko/services/camera_v1.md index 25a43f065..5c9d29055 100644 --- a/ko/services/camera_v1.md +++ b/ko/services/camera_v1.md @@ -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. diff --git a/ko/services/command.md b/ko/services/command.md index f30b6e2c5..072215fe7 100644 --- a/ko/services/command.md +++ b/ko/services/command.md @@ -13,20 +13,20 @@ If no acknowledgement is received the command must be automatically re-sent. | Message | Description | | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [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). | -| [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). | +| [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 coordinates is implementation dependent. Any command may be packaged in this message, but there may be some loss of precision for positional coordinates (latitude, longitude). | | [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. | | [COMMAND_CANCEL](../messages/common.md#COMMAND_CANCEL) | Cancel a long running command. | | Enum | Description | | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | [MAV_CMD](../messages/common.md#mav_commands) | Commands to be executed/sent in the command messages. | -| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame. Used in `COMMAND_INT` to specify the co-ordinate frame of any positional parameters. | +| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame. Used in `COMMAND_INT` to specify the coordinate frame of any positional parameters. | | [MAV_RESULT](../messages/common.md#MAV_RESULT) | Result of command, included in [COMMAND_ACK.result](#COMMAND_ACK). | ## Use COMMAND_INT or COMMAND_LONG? `COMMAND_INT` should be used when sending commands that contain positional or navigation information, if supported by the flight stack for the particular command. -This is because it allows the co-ordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". +This is because it allows the coordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". In addition latitudes/longitudes can be sent with greater precision in a `COMMAND_INT` as scaled integers in params 5 and 6 (than when sent in float values in `COMMAND_LONG`). `COMMAND_LONG` must be used for sending `MAV_CMD` commands that send float properties in parameters 5 and 6, as these values would be truncated to integers if sent in `COMMAND_INT`. @@ -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 diff --git a/ko/services/component_information.md b/ko/services/component_information.md index 1c5963928..2440a522b 100644 --- a/ko/services/component_information.md +++ b/ko/services/component_information.md @@ -35,7 +35,7 @@ There is no mechanism, for example, to provide an update if the set of supported | [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 the service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)). ::: ## Component Information File Format (Schema) {#schema_files} @@ -47,7 +47,7 @@ The component information file types and schema are (at time of writing): | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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! | | 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). | -| 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. | +| Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command parameters are supported in via the command protocol. | | 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). | | Event metadata | [COMP_METADATA_TYPE_EVENTS](../messages/common.md#COMP_METADATA_TYPE_EVENTS) | TBD | Information about events interface support by the vehicle. | | 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. | @@ -136,7 +136,7 @@ In summary: 2. The component will ACK the command and immediately send the requested `COMPONENT_METADATA` message (populated with URI and CRC for the general metadata file). - A `CMD_ACK` of anything other than `MAV_RESULT_ACCEPTED` indicates the protocol is not supported (sequence completes). 3. GCS waits for the `COMPONENT_METADATA` message - - If not recieved the GCS should resend the request (typically in the application level). + - If not received the GCS should resend the request (typically in the application level). - Once information is received: - the GCS checks if `COMPONENT_METADATA.file_crc` matches its cached CRC value. If so, there is no need to download the [general metadata file](#COMP_METADATA_TYPE_GENERAL) (or other files it references) as it has not changed since the last download. @@ -267,7 +267,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. diff --git a/ko/services/events.md b/ko/services/events.md index f76c2b865..c22ac516f 100644 --- a/ko/services/events.md +++ b/ko/services/events.md @@ -50,7 +50,7 @@ The following key features are provided by the interface: | Enum | Description | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [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. | +| [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. | | [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). | ## 구현 diff --git a/ko/services/ftp.md b/ko/services/ftp.md index 4014751f0..8bda3cfda 100644 --- a/ko/services/ftp.md +++ b/ko/services/ftp.md @@ -62,7 +62,7 @@ The opcodes that may be sent by the GCS (client) to the drone (server) are liste | Opcode | Name | Description | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | None | Ignored, always ACKed | -| 1 | TerminateSession | Terminates open Read `session`.
- Closes the file associated with (`session`) and frees the session ID for re-use. | +| 1 | TerminateSession | Terminates open Read `session`.
- Closes the file associated with (`session`) and frees the session ID for reuse. | | 2 | ResetSessions | Terminates _all_ open read sessions.
- Clears all state held by the drone (server); closes all open files, etc.
- Sends an ACK reply with no data. | | 3 | [ListDirectory](#list_directory) | List directory entry information (files, folders etc.) in ``, starting from a specified entry index (``).
- Response is an ACK packet with one or more entries on success, otherwise a NAK packet with an error code.
- Completion is indicated by a NACK with EOF in response to a requested index (`offset`) beyond the list of entries.
- The directory is closed after the operation, so this leaves no state on the server. | | 4 | [OpenFileRO](#reading-a-file) | Opens file at `` for reading, returns ``
- The `path` is stored in the [payload](#payload) `data`. The drone opens the file (`path`) and allocates a _session number_. The file must exist.
- An ACK packet must include the allocated `session` and the data size of the file to be opened (`size`)
- A NAK packet must contain [error information](#error_codes) . Typical error codes for this command are `NoSessionsAvailable`, `FileExists`.
- The file remains open after the operation, and must eventually be closed by `Reset` or `Terminate`. | @@ -204,7 +204,7 @@ After opening a file for reading, it is read in "bursts". Each burst delivers a part of the file as a stream of messages. The last message in the burst is indicated by setting `burst_complete=1` (without any ACKs). -The client tracks the recieved chunks. +The client tracks the received chunks. On completion of the burst (or the file), if there are any missing parts of the file it can request them using either another burst or using [ReadFile](#reading-a-file-readfile). :::info diff --git a/ko/services/gimbal.md b/ko/services/gimbal.md index a3ed70d01..da5873211 100644 --- a/ko/services/gimbal.md +++ b/ko/services/gimbal.md @@ -45,7 +45,7 @@ This version of the gimbal protocol (v1) has a number of known issues: - Unclear “stabilize” flags in `DO_MOUNT_CONFIGURE`. - Confusing and unimplemented “absolute” flags in `DO_MOUNT_CONFIGURE`. - Unclear when to use `DO_MOUNT_CONTROL` or `DO_MOUNT_CONFIGURE`. -- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targetting. +- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targeting. - Unusual param number for `DO_MOUNT_CONTROL`. - The GPS mode in `DO_MOUNT_CONTROL` conflicts with `DO_SET_ROI_*` commands. - MOUNT naming makes discovery hard. diff --git a/ko/services/gimbal_v2.md b/ko/services/gimbal_v2.md index 618d8c6de..1b4427b46 100644 --- a/ko/services/gimbal_v2.md +++ b/ko/services/gimbal_v2.md @@ -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: @@ -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 diff --git a/ko/services/image_transmission.md b/ko/services/image_transmission.md index c2d117191..6d740ee4a 100644 --- a/ko/services/image_transmission.md +++ b/ko/services/image_transmission.md @@ -3,7 +3,7 @@ :::warning The [Camera Protocol](../services/camera.md) and [MAVLink FTP](../services/ftp.md) are recommended for sending images, video and files. -This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transfering small images over a low bandwidth channel from an optical flow sensor to a GCS). +This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transferring small images over a low bandwidth channel from an optical flow sensor to a GCS). ::: The image transmission protocol uses MAVLink as the communication channel to transport any kind of image (raw images, Kinect data, etc.) from one MAVLink node to another. diff --git a/ko/services/manual_control.md b/ko/services/manual_control.md index ce18c8688..00c454962 100644 --- a/ko/services/manual_control.md +++ b/ko/services/manual_control.md @@ -57,7 +57,7 @@ Channels can be mapped to firmware parameters using [`PARAM_MAP_RC`](../messages It's worth noting that the generality of RC channels control is a double-edged sword. It is incredibly versatile, and can be used to provide support for several arbitrary control axes, but the user-defined in-vehicle nature of the mapped parameters means additional setup is frequently required for compatibility with GCSs, and there are no guarantees that multiple vehicles running the same firmware will have the same channel-parameter mapping. -This is a similar issue to the `MANUAL_CONTROL` buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targetted MAVLink commands where possible. +This is a similar issue to the `MANUAL_CONTROL` buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targeted MAVLink commands where possible. ## 구현 @@ -93,4 +93,4 @@ ArduPilot Implementations: ## Future Extensions -Future extensions are likely to be handled with additional targetted [MAVLink commands](./command.md) rather than mapping functionality in the flight controller (i.e. handling more complex inputs in the GCS to reduce vehicle firmware complexity). +Future extensions are likely to be handled with additional targeted [MAVLink commands](./command.md) rather than mapping functionality in the flight controller (i.e. handling more complex inputs in the GCS to reduce vehicle firmware complexity). diff --git a/ko/services/mission.md b/ko/services/mission.md index 8bea35d15..720f22137 100644 --- a/ko/services/mission.md +++ b/ko/services/mission.md @@ -99,7 +99,7 @@ The following messages and enums are used by the service. | --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [MAV_MISSION_TYPE](../messages/common.md#MAV_MISSION_TYPE) | [Mission type](#mission_types) for message (mission, geofence, rallypoints). | | [MAV_MISSION_RESULT](../messages/common.md#MAV_MISSION_RESULT) | Used to indicate the success or failure reason for an operation (e.g. to upload or download a mission). This is carried in a [MISSION_ACK](#MISSION_ACK). | -| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Co-ordinate frame for position/velocity/acceleration data in the message. | +| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame for position/velocity/acceleration data in the message. | | [MAV_CMD](../messages/common.md#mav_commands) | [Mission Items](#mavlink_commands) (and MAVLink commands) sent in [MISSION_ITEM_INT](#MISSION_ITEM_INT). | ## Deprecated Types: MISSION_ITEM {#command_message_type} @@ -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 @@ -120,7 +120,7 @@ The table below shows that the positional parameters can be local (x, y, z), glo | param6 | `int32_t` | y | Longitude | | param7 | `float` | z | Altitude (global - relative or absolute) | -The co-ordinate frame of positional parameters is defined in the `MISSION_ITEM_INT.frame` field using a [MAV_FRAME](#MAV_FRAME) value. +The coordinate frame of positional parameters is defined in the `MISSION_ITEM_INT.frame` field using a [MAV_FRAME](#MAV_FRAME) value. The global frames are prefixed with `MAV_FRAME_GLOBAL_*`. Mission items should use frame variants that have the suffix `_INT`: e.g. `MAV_FRAME_GLOBAL_RELATIVE_ALT_INT`, `MAV_FRAME_GLOBAL_INT`, `MAV_FRAME_GLOBAL_TERRAIN_ALT_INT`. @@ -539,7 +539,7 @@ The following behaviour is not defined by the specification (but is still of int - ArduPilot performs some validation of fields when mission items are submitted. The validation code is common to all vehicles; mission items that are not understood by the vehicle type are accepted on upload but skipped during mission execution. -- ArduPilot preforms some vehicle-specific validation at mission runtime (e.g. of jump targets). +- ArduPilot performs some vehicle-specific validation at mission runtime (e.g. of jump targets). - A new mission can be uploaded while a mission is being executed. In this case the current waypoint will be executed to completion even if the waypoint sequence is different in the new mission (to get the new item you would need to reset the sequence or switch in/out of auto mode). - ArduPilot missions are not stored in an SD card and therefore have a vehicle/board-specific maximum mission size (as a benefit, on ArduPilot, missions can survive SD card failure in flight). diff --git a/ko/services/offboard_control.md b/ko/services/offboard_control.md index f9a275c2a..2ad1fec5e 100644 --- a/ko/services/offboard_control.md +++ b/ko/services/offboard_control.md @@ -5,7 +5,7 @@ The offboard control interface allows an external controller to send low-level a This is commonly used to provide external control of a real-time flight stack from a companion/mission computer, for example, in order to implement features such as obstacle avoidance or collision prevention. Generally setpoints are only obeyed in a specific flight-stack mode. -The flight stack requires the setpoints to be recieved for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received. +The flight stack requires the setpoints to be received for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received. The particular types of setpoints that are supported, if any, depend on the vehicle type and flight stack. @@ -13,7 +13,7 @@ The particular types of setpoints that are supported, if any, depend on the vehi | Message | Description | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -| [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. | +| [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. | | [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) | | [SET_ATTITUDE_TARGET](../messages/common.md#SET_ATTITUDE_TARGET) | Sets a desired vehicle attitude. | | [POSITION_TARGET_LOCAL_NED](../messages/common.md#POSITION_TARGET_LOCAL_NED) | Publishes current local NED target (set by `SET_POSITION_TARGET_LOCAL_NED`). | diff --git a/ko/services/parameter.md b/ko/services/parameter.md index fa6c86e3c..4fcecd9bb 100644 --- a/ko/services/parameter.md +++ b/ko/services/parameter.md @@ -141,7 +141,7 @@ If working with a non-compliant component, the risk of problems when working wit A GCS (or other component) that wants to [cache parameters](#parameter_caching) with a component and keep them synchronised, should first get all parameters, and then track any new parameter changes by monitoring for `PARAM_VALUE` messages (updating their internal list appropriately). -This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not recieved. +This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not received. This approach may fail for components that did not originate the change, as they will not know about updates they do not receive (i.e. if messages are dropped). A component may mitigate this risk by, for example, sending the `PARAM_VALUE` multiple times after a parameter is changed. @@ -242,7 +242,7 @@ The sequence of operations is: 1. GCS (client) sends [PARAM_SET](../messages/common.md#PARAM_VALUE) specifying the param name to update and its new value (also target system/component and the param type). -2. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message). +2. GCS starts timeout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message). 3. Drone writes parameter and responds by _broadcasting_ a `PARAM_VALUE` containing the updated parameter value to all components/systems. diff --git a/ko/services/parameter_ext.md b/ko/services/parameter_ext.md index 713505888..a7e81594e 100644 --- a/ko/services/parameter_ext.md +++ b/ko/services/parameter_ext.md @@ -263,7 +263,7 @@ sequenceDiagram; The sequence of operations is: 1. GCS (client) sends [PARAM_EXT_SET](../messages/common.md#PARAM_EXT_SET) specifying the param name to update and its new value (also target system/component and the param type). -2. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_EXT_ACK](../messages/common.md#PARAM_EXT_ACK) message). +2. GCS starts timeout waiting for acknowledgment (in the form of a [PARAM_EXT_ACK](../messages/common.md#PARAM_EXT_ACK) message). 3. Drone (starts to) write parameter and responds by _broadcasting_ a `PARAM_EXT_ACK`. - If the write succeeded the `PARAM_EXT_ACK` will contain a result of `PARAM_ACK_ACCEPTED` and the updated parameter value. - If the parameter was unknown or of an unsupported type `PARAM_EXT_ACK` will contain a result of `PARAM_ACK_VALUE_UNSUPPORTED` and the current parameter value will be XXXXX. diff --git a/ko/services/payload.md b/ko/services/payload.md index 40a73da3c..1e3400c95 100644 --- a/ko/services/payload.md +++ b/ko/services/payload.md @@ -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 | | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | diff --git a/ko/services/traffic_management.md b/ko/services/traffic_management.md index 35c990f17..07072c2e8 100644 --- a/ko/services/traffic_management.md +++ b/ko/services/traffic_management.md @@ -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, ::: diff --git a/zh/SUMMARY.md b/zh/SUMMARY.md index e6033533b..7d2cf5004 100644 --- a/zh/SUMMARY.md +++ b/zh/SUMMARY.md @@ -64,7 +64,7 @@ - [Component Metadata Protocol (WIP)](services/component_information.md) - [MAVLink Id Assignment (sysid, compid)](services/mavlink_id_assignment.md) - [Payload Protocols](services/payload.md) - - [Traffic Managment (UTM/ADS-B)](services/traffic_management.md) + - [Traffic Management (UTM/ADS-B)](services/traffic_management.md) - [Events Interface (WIP)](services/events.md) - [Standard Flight Modes](services/standard_modes.md) - [Time Synchronization](services/timesync.md) diff --git a/zh/contributing/contributing.md b/zh/contributing/contributing.md index a3c980cfa..d840059b4 100644 --- a/zh/contributing/contributing.md +++ b/zh/contributing/contributing.md @@ -47,7 +47,7 @@ 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. diff --git a/zh/guide/mavlink_2.md b/zh/guide/mavlink_2.md index 907a0bdaf..2bf947054 100644 --- a/zh/guide/mavlink_2.md +++ b/zh/guide/mavlink_2.md @@ -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. diff --git a/zh/guide/message_signing.md b/zh/guide/message_signing.md index b7cef4aea..b46891ac2 100644 --- a/zh/guide/message_signing.md +++ b/zh/guide/message_signing.md @@ -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) 自动转发到另一个系统的情况。 diff --git a/zh/guide/packet_loss.md b/zh/guide/packet_loss.md index 75c73ff77..ae72ec9ee 100644 --- a/zh/guide/packet_loss.md +++ b/zh/guide/packet_loss.md @@ -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. diff --git a/zh/guide/serialization.md b/zh/guide/serialization.md index 0c9206824..a1e64325e 100644 --- a/zh/guide/serialization.md +++ b/zh/guide/serialization.md @@ -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 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 生成器的开发者 diff --git a/zh/guide/wireshark.md b/zh/guide/wireshark.md index fe4b64379..dfb8c65d6 100644 --- a/zh/guide/wireshark.md +++ b/zh/guide/wireshark.md @@ -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: diff --git a/zh/mavgen_c/index.md b/zh/mavgen_c/index.md index bc40787cc..a6898ae57 100644 --- a/zh/mavgen_c/index.md +++ b/zh/mavgen_c/index.md @@ -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`. diff --git a/zh/mavgen_python/howto_requestmessages.md b/zh/mavgen_python/howto_requestmessages.md index e6a9c78f9..5116ea1a9 100644 --- a/zh/mavgen_python/howto_requestmessages.md +++ b/zh/mavgen_python/howto_requestmessages.md @@ -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 diff --git a/zh/services/arm_authorization.md b/zh/services/arm_authorization.md index 0dc69c0c0..963fb7b31 100644 --- a/zh/services/arm_authorization.md +++ b/zh/services/arm_authorization.md @@ -7,7 +7,7 @@ This is required to comply with [NASA UTM](https://utm.arc.nasa.gov/), but may a ## Authorization Flow -[![Mermaid Squence: Authorization Flow](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ) +[![Mermaid Sequence: Authorization Flow](https://mermaid.ink/img/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtO1xuICAgIHBhcnRpY2lwYW50IERyb25lXG4gICAgcGFydGljaXBhbnQgUmVtb3RlIGNvbnRyb2wvUUNTXG4gICAgcGFydGljaXBhbnQgQXJtIGF1dGhvcml6ZXJcbiAgICBwYXJ0aWNpcGFudCBJbnRlcm5ldFxuXG4gICAgUmVtb3RlIGNvbnRyb2wvUUNTLT4-RHJvbmU6IFJlcXVlc3QgYXJtXG4gICAgRHJvbmUtPj5Bcm0gYXV0aG9yaXplcjogQ09NTUFORF9MT05HIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUXG4gICAgQXJtIGF1dGhvcml6ZXItPj5Ecm9uZTogQ09NTUFORF9BQ0sgcmVzdWx0PU1BVl9SRVNVTFRfSU5fUFJPR1JFU1NcbiAgICBBcm0gYXV0aG9yaXplci0-PkRyb25lOiAob3B0aW9uYWwpUmVxdWVzdCBpbmZvcm1hdGlvbiBhYm91dCBtaXNzaW9uLCBiYXR0ZXJ5IGxldmVsIGFuZCBldGMuXG4gICAgQXJtIGF1dGhvcml6ZXItPj5JbnRlcm5ldDogKG9wdGlvbmFsKVJlcXVlc3QgaW5mb3JtYXRpb24gYWJvdXQgd2VhdGhlciwgYWVyb3NwYWNlIHRyYWZpYyBhbmQgZXRjLlxuICAgIEFybSBhdXRob3JpemVyLT4-RHJvbmU6IENPTU1BTkRfQUNLIGNvbW1hbmQ9TUFWX0NNRF9BUk1fQVVUSE9SSVpBVElPTl9SRVFVRVNUIHJlc3VsdD1BQ0NFUFRFRCwgVEVNUE9SQVJJTFlfUkVKRUNURUQgb3IgREVOSUVEXG4gICAgRHJvbmUtPj5SZW1vdGUgY29udHJvbC9RQ1M6IFFDUyBDT01NQU5EX0FDSyBjb21tYW5kPU1BVl9DTURfQ09NUE9ORU5UX0FSTV9ESVNBUk0gcmVzdWx0PUFDQ0VQVEVELCBURU1QT1JBUklMWV9SRUpFQ1RFRCBvciBERU5JRUQiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ) @@ -41,7 +41,7 @@ sequenceDiagram; Drone->>Arm authorizer: COMMAND_LONG command=MAV_CMD_ARM_AUTHORIZATION_REQUEST Arm authorizer->>Drone: COMMAND_ACK result=MAV_RESULT_IN_PROGRESS Arm authorizer->>Drone: (optional)Request information about mission, battery level and etc. - Arm authorizer->>Internet: (optional)Request information about weather, aerospace trafic and etc. + Arm authorizer->>Internet: (optional)Request information about weather, aerospace traffic and etc. Arm authorizer->>Drone: COMMAND_ACK command=MAV_CMD_ARM_AUTHORIZATION_REQUEST result=ACCEPTED, TEMPORARILY_REJECTED or DENIED Drone->>Remote control/QCS: QCS STATUSTEXT text=Arm authorization was approved or denied @@ -65,7 +65,7 @@ COMMAND_ACK command=MAV_CMD_ARM_AUTHORIZATION_REQUEST result=ACCEPTED, TEMPORARILY_REJECTED or DENIED progress/result_param1=if result is TEMPORARILY_REJECTED or DENIED the reason should be set MAV_ARM_AUTH_DENIED_REASON otherwise it should be set as 0 -result_param2=if result is ACCEPTED the it should be set with the time in seconds that this authorization is valid otherwise an aditional information about why it was denied should be set. example: for result_param1=MAV_ARM_AUTH_DENIED_REASON_INVALID_WAYPOINT or MAV_ARM_AUTH_DENIED_REASON_AIRSPACE_IN_USE it may have the index of the waypoint that caused it to be denied. +result_param2=if result is ACCEPTED the it should be set with the time in seconds that this authorization is valid otherwise an additional information about why it was denied should be set. example: for result_param1=MAV_ARM_AUTH_DENIED_REASON_INVALID_WAYPOINT or MAV_ARM_AUTH_DENIED_REASON_AIRSPACE_IN_USE it may have the index of the waypoint that caused it to be denied. target_system=system id of the drone target_component=component id of the drone ``` diff --git a/zh/services/camera.md b/zh/services/camera.md index fb7d808b1..9d0b0d438 100644 --- a/zh/services/camera.md +++ b/zh/services/camera.md @@ -10,7 +10,7 @@ The older protocol enables camera triggering, but does not support other feature ::: :::warning -We are transitioning from specific request commands to a single generic requestor. +We are transitioning from specific request commands to a single generic requester. GCS and MAVLink SDKs/apps should support both approaches as we migrate to exclusive use of the new method (documented here). For more information see [Migration Notes for GCS & Camera Servers](#migration-notes-for-gcs--mavlink-sdks). ::: @@ -413,7 +413,7 @@ After starting camera tracking you should call [MAV_CMD_SET_MESSAGE_INTERVAL](.. This message contains information about the tracked point/rectangle in an image, and may be used by the receiving system to determine the location of the target (alongside other information like the [CAMERA_FOV_STATUS](#CAMERA_FOV_STATUS)). If geo-tracking status information is supported (indicated by `CAMERA_CAP_FLAGS_HAS_TRACKING_GEO_STATUS`) you should also call [MAV_CMD_SET_MESSAGE_INTERVAL](../messages/common.md#MAV_CMD_SET_MESSAGE_INTERVAL) to stream [CAMERA_TRACKING_GEO_STATUS](#CAMERA_TRACKING_GEO_STATUS) at your desired rate. -This message provides the location of the target in physical co-ordinates that can be passed to a gimbal. +This message provides the location of the target in physical coordinates that can be passed to a gimbal. To stop any kind of tracking, a GCS uses the [MAV_CMD_CAMERA_STOP_TRACKING](#MAV_CMD_CAMERA_STOP_TRACKING) command. After stopping tracking you should call `MAV_CMD_SET_MESSAGE_INTERVAL` to stop streaming `CAMERA_TRACKING_IMAGE_STATUS` and `CAMERA_TRACKING_GEO_STATUS` (set their rates to 0). @@ -436,7 +436,7 @@ The steps are: The sequence above just shows point tracking. 4. Set the desired rates (intervals) for streaming the tracking status messages. 5. Camera streams [CAMERA_TRACKING_IMAGE_STATUS](#CAMERA_TRACKING_IMAGE_STATUS) and/or [CAMERA_TRACKING_GEO_STATUS](#CAMERA_TRACKING_GEO_STATUS). - These are used to provide camera targetting information. + These are used to provide camera targeting information. 6. To stop tracking, a GCS uses the [MAV_CMD_CAMERA_STOP_TRACKING](#MAV_CMD_CAMERA_STOP_TRACKING) command. The streaming intervals must also be set to zero. @@ -478,7 +478,7 @@ Other components like a GCS will typically only use the camera `BATTERY_STATUS.b | [MAV_CMD_VIDEO_STOP_CAPTURE](../messages/common.md#MAV_CMD_VIDEO_STOP_CAPTURE) | Send command to stop video capture. | | [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) | Send command to start video streaming for the given Stream ID (`stream_id`.) This is mostly for streaming protocols that _push_ a stream. If your camera uses a connection based streaming configuration (RTSP, TCP, etc.), you may ignore it if you don't need it but note that you still must ACK the command, like all `MAV_CMD_XXX` commands. When using a connection based streaming configuration, the GCS will connect the stream from its side. When a camera offers more than one stream and the user switches from one stream to another, the GCS will send a [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) command targeting the current Stream ID followed by a [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) targeting the newly selected Stream ID. | | [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) | Send command to stop video streaming for the given Stream ID (`stream_id`.) This is mostly for streaming protocols that _push_ a stream. If your camera uses a connection based streaming configuration (RTSP, TCP, etc.), you may ignore it if you don't need it but note that you still must ACK the command, like all `MAV_CMD_XXX` commands. When using a connection based streaming configuration, the GCS will disconnect the stream from its side. When a camera offers more than one stream and the user switches from one stream to another, the GCS will send a [MAV_CMD_VIDEO_STOP_STREAMING](../messages/common.md#MAV_CMD_VIDEO_STOP_STREAMING) command targeting the current Stream ID followed by a [MAV_CMD_VIDEO_START_STREAMING](../messages/common.md#MAV_CMD_VIDEO_START_STREAMING) targeting the newly selected Stream ID. | -| [MAV_CMD_CAMERA_TRACK_POINT](../messages/common.md#MAV_CMD_CAMERA_TRACK_POINT) | Initate visual point tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_POINT](#CAMERA_CAP_FLAGS) is set). | +| [MAV_CMD_CAMERA_TRACK_POINT](../messages/common.md#MAV_CMD_CAMERA_TRACK_POINT) | Initiate visual point tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_POINT](#CAMERA_CAP_FLAGS) is set). | | [MAV_CMD_CAMERA_TRACK_RECTANGLE](../messages/common.md#MAV_CMD_CAMERA_TRACK_RECTANGLE) | Initiate visual rectangle tracking, if supported by the camera ([CAMERA_CAP_FLAGS_HAS_TRACKING_RECTANGLE](#CAMERA_CAP_FLAGS) is set). | | [MAV_CMD_CAMERA_STOP_TRACKING](../messages/common.md#MAV_CMD_CAMERA_STOP_TRACKING) | Stop camera tracking (as initiated using `MAV_CMD_CAMERA_TRACK_POINT` or `MAV_CMD_CAMERA_TRACK_RECTANGLE`). | @@ -512,7 +512,7 @@ These commands have been deprecated, replaced by the generic requester command [ The original definition of this protocol used specific commands to query for each type of information requested from the camera: [MAV_CMD_REQUEST_CAMERA_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_CAMERA_INFORMATION) (for [CAMERA_INFORMATION](../messages/common.md#CAMERA_INFORMATION)), [MAV_CMD_REQUEST_CAMERA_SETTINGS](../messages/common.md#MAV_CMD_REQUEST_CAMERA_SETTINGS), [MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS](../messages/common.md#MAV_CMD_REQUEST_CAMERA_CAPTURE_STATUS), [MAV_CMD_REQUEST_VIDEO_STREAM_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_VIDEO_STREAM_INFORMATION), [MAV_CMD_REQUEST_STORAGE_INFORMATION](../messages/common.md#MAV_CMD_REQUEST_STORAGE_INFORMATION). -The latest version replaces all of these specific commands with the general requestor [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE). +The latest version replaces all of these specific commands with the general requester [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE). The transition works like this: diff --git a/zh/services/camera_def.md b/zh/services/camera_def.md index 55b2a7eb3..232e657c7 100644 --- a/zh/services/camera_def.md +++ b/zh/services/camera_def.md @@ -258,7 +258,7 @@ This example also tells the GCS not to display this parameter to the user (`cont #### Param Ranges -It is also possible to define param ranges without individual options, but by specifiying the minimum, maximum, and optionally a step size: +It is also possible to define param ranges without individual options, but by specifying the minimum, maximum, and optionally a step size: ```xml diff --git a/zh/services/camera_v1.md b/zh/services/camera_v1.md index ad970e84e..234268511 100644 --- a/zh/services/camera_v1.md +++ b/zh/services/camera_v1.md @@ -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. diff --git a/zh/services/command.md b/zh/services/command.md index a9711bb05..6f486188e 100644 --- a/zh/services/command.md +++ b/zh/services/command.md @@ -13,20 +13,20 @@ If no acknowledgement is received the command must be automatically re-sent. | 消息 | 描述 | | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [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). | -| [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). | +| [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 coordinates is implementation dependent. Any command may be packaged in this message, but there may be some loss of precision for positional coordinates (latitude, longitude). | | [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. | | [COMMAND_CANCEL](../messages/common.md#COMMAND_CANCEL) | Cancel a long running command. | | Enum | 描述 | | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | [MAV_CMD](../messages/common.md#mav_commands) | Commands to be executed/sent in the command messages. | -| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame. Used in `COMMAND_INT` to specify the co-ordinate frame of any positional parameters. | +| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame. Used in `COMMAND_INT` to specify the coordinate frame of any positional parameters. | | [MAV_RESULT](../messages/common.md#MAV_RESULT) | Result of command, included in [COMMAND_ACK.result](#COMMAND_ACK). | ## Use COMMAND_INT or COMMAND_LONG? `COMMAND_INT` should be used when sending commands that contain positional or navigation information, if supported by the flight stack for the particular command. -This is because it allows the co-ordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". +This is because it allows the coordinate frame to be specified for location and altitude values, which may otherwise be "unspecified". In addition latitudes/longitudes can be sent with greater precision in a `COMMAND_INT` as scaled integers in params 5 and 6 (than when sent in float values in `COMMAND_LONG`). `COMMAND_LONG` must be used for sending `MAV_CMD` commands that send float properties in parameters 5 and 6, as these values would be truncated to integers if sent in `COMMAND_INT`. @@ -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 diff --git a/zh/services/component_information.md b/zh/services/component_information.md index 24740f8a5..828b2a94e 100644 --- a/zh/services/component_information.md +++ b/zh/services/component_information.md @@ -35,7 +35,7 @@ Information supplied by the service is assumed to be invariant after boot. There | [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 the service (it is a deprecated legacy version of [COMPONENT_METADATA](../messages/common.md#COMPONENT_METADATA)). ::: ## Component Information File Format (Schema) {#schema_files} @@ -47,7 +47,7 @@ The component information file types and schema are (at time of writing): | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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! | | 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). | -| 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. | +| Command protocol metadata | [COMP_METADATA_TYPE_COMMANDS](../messages/common.md#COMP_METADATA_TYPE_COMMANDS) | TBD | Information about which commands and command parameters are supported in via the command protocol. | | 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). | | Event metadata | [COMP_METADATA_TYPE_EVENTS](../messages/common.md#COMP_METADATA_TYPE_EVENTS) | TBD | Information about events interface support by the vehicle. | | 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. | @@ -136,7 +136,7 @@ In summary: 2. The component will ACK the command and immediately send the requested `COMPONENT_METADATA` message (populated with URI and CRC for the general metadata file). - A `CMD_ACK` of anything other than `MAV_RESULT_ACCEPTED` indicates the protocol is not supported (sequence completes). 3. GCS waits for the `COMPONENT_METADATA` message - - If not recieved the GCS should resend the request (typically in the application level). + - If not received the GCS should resend the request (typically in the application level). - Once information is received: - the GCS checks if `COMPONENT_METADATA.file_crc` matches its cached CRC value. If so, there is no need to download the [general metadata file](#COMP_METADATA_TYPE_GENERAL) (or other files it references) as it has not changed since the last download. @@ -267,7 +267,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. diff --git a/zh/services/events.md b/zh/services/events.md index 53c2a9783..43ae55075 100644 --- a/zh/services/events.md +++ b/zh/services/events.md @@ -50,7 +50,7 @@ The following key features are provided by the interface: | Enum | 描述 | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [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. | +| [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. | | [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 diff --git a/zh/services/ftp.md b/zh/services/ftp.md index 8234d418e..f49f0e106 100644 --- a/zh/services/ftp.md +++ b/zh/services/ftp.md @@ -62,7 +62,7 @@ The opcodes that may be sent by the GCS (client) to the drone (server) are liste | Opcode | Name | 描述 | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | None | Ignored, always ACKed | -| 1 | TerminateSession | Terminates open Read `session`.
- Closes the file associated with (`session`) and frees the session ID for re-use. | +| 1 | TerminateSession | Terminates open Read `session`.
- Closes the file associated with (`session`) and frees the session ID for reuse. | | 2 | ResetSessions | Terminates _all_ open read sessions.
- Clears all state held by the drone (server); closes all open files, etc.
- Sends an ACK reply with no data. | | 3 | [ListDirectory](#list_directory) | List directory entry information (files, folders etc.) in ``, starting from a specified entry index (``).
- Response is an ACK packet with one or more entries on success, otherwise a NAK packet with an error code.
- Completion is indicated by a NACK with EOF in response to a requested index (`offset`) beyond the list of entries.
- The directory is closed after the operation, so this leaves no state on the server. | | 4 | [OpenFileRO](#reading-a-file) | Opens file at `` for reading, returns ``
- The `path` is stored in the [payload](#payload) `data`. The drone opens the file (`path`) and allocates a _session number_. The file must exist.
- An ACK packet must include the allocated `session` and the data size of the file to be opened (`size`)
- A NAK packet must contain [error information](#error_codes) . Typical error codes for this command are `NoSessionsAvailable`, `FileExists`.
- The file remains open after the operation, and must eventually be closed by `Reset` or `Terminate`. | @@ -204,7 +204,7 @@ After opening a file for reading, it is read in "bursts". Each burst delivers a part of the file as a stream of messages. The last message in the burst is indicated by setting `burst_complete=1` (without any ACKs). -The client tracks the recieved chunks. +The client tracks the received chunks. On completion of the burst (or the file), if there are any missing parts of the file it can request them using either another burst or using [ReadFile](#reading-a-file-readfile). :::info diff --git a/zh/services/gimbal.md b/zh/services/gimbal.md index 3bd48a5bb..a23ddc123 100644 --- a/zh/services/gimbal.md +++ b/zh/services/gimbal.md @@ -45,7 +45,7 @@ This version of the gimbal protocol (v1) has a number of known issues: - Unclear “stabilize” flags in `DO_MOUNT_CONFIGURE`. - Confusing and unimplemented “absolute” flags in `DO_MOUNT_CONFIGURE`. - Unclear when to use `DO_MOUNT_CONTROL` or `DO_MOUNT_CONFIGURE`. -- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targetting. +- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targeting. - Unusual param number for `DO_MOUNT_CONTROL`. - The GPS mode in `DO_MOUNT_CONTROL` conflicts with `DO_SET_ROI_*` commands. - MOUNT naming makes discovery hard. diff --git a/zh/services/gimbal_v2.md b/zh/services/gimbal_v2.md index a077ec205..2f12b0975 100644 --- a/zh/services/gimbal_v2.md +++ b/zh/services/gimbal_v2.md @@ -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: @@ -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 diff --git a/zh/services/image_transmission.md b/zh/services/image_transmission.md index c2d117191..6d740ee4a 100644 --- a/zh/services/image_transmission.md +++ b/zh/services/image_transmission.md @@ -3,7 +3,7 @@ :::warning The [Camera Protocol](../services/camera.md) and [MAVLink FTP](../services/ftp.md) are recommended for sending images, video and files. -This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transfering small images over a low bandwidth channel from an optical flow sensor to a GCS). +This protocol is not intended for general image transmission use (it was originally designed as a simple protocol for transferring small images over a low bandwidth channel from an optical flow sensor to a GCS). ::: The image transmission protocol uses MAVLink as the communication channel to transport any kind of image (raw images, Kinect data, etc.) from one MAVLink node to another. diff --git a/zh/services/manual_control.md b/zh/services/manual_control.md index 1ea41ac57..938625baa 100644 --- a/zh/services/manual_control.md +++ b/zh/services/manual_control.md @@ -56,8 +56,8 @@ Vehicles may alternatively be controlled by sending information as a set of up t Channels can be mapped to firmware parameters using [`PARAM_MAP_RC`](../messages/common.md#PARAM_MAP_RC), and the autopilot can use the current parameter values at each point in time to determine control actions. It's worth noting that the generality of RC channels control is a double-edged sword. -It's worth noting that the generality of RC channels control is a double-edged sword. It is incredibly versatile, and can be used to provide support for several arbitrary control axes, but the user-defined in-vehicle nature of the mapped parameters means additional setup is frequently required for compatibility with GCSs, and there are no guarantees that multiple vehicles running the same firmware will have the same channel-parameter mapping. This is a similar issue to the MANUAL_CONTROL buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targetted MAVLink commands where possible. -This is a similar issue to the `MANUAL_CONTROL` buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targetted MAVLink commands where possible. +It's worth noting that the generality of RC channels control is a double-edged sword. It is incredibly versatile, and can be used to provide support for several arbitrary control axes, but the user-defined in-vehicle nature of the mapped parameters means additional setup is frequently required for compatibility with GCSs, and there are no guarantees that multiple vehicles running the same firmware will have the same channel-parameter mapping. This is a similar issue to the MANUAL_CONTROL buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targeted MAVLink commands where possible. +This is a similar issue to the `MANUAL_CONTROL` buttons, so to minimise firmware complexity and maximise interoperability between a vehicle type and GCSs it's recommended to use targeted MAVLink commands where possible. ## Implementations @@ -93,4 +93,4 @@ ArduPilot Implementations: ## Future Extensions -Future extensions are likely to be handled with additional targetted [MAVLink commands](./command.md) rather than mapping functionality in the flight controller (i.e. handling more complex inputs in the GCS to reduce vehicle firmware complexity). +Future extensions are likely to be handled with additional targeted [MAVLink commands](./command.md) rather than mapping functionality in the flight controller (i.e. handling more complex inputs in the GCS to reduce vehicle firmware complexity). diff --git a/zh/services/mission.md b/zh/services/mission.md index a51d16b6b..bd3ca6d21 100644 --- a/zh/services/mission.md +++ b/zh/services/mission.md @@ -99,7 +99,7 @@ The following messages and enums are used by the service. | --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [MAV_MISSION_TYPE](../messages/common.md#MAV_MISSION_TYPE) | [Mission type](#mission_types) for message (mission, geofence, rallypoints). | | [MAV_MISSION_RESULT](../messages/common.md#MAV_MISSION_RESULT) | Used to indicate the success or failure reason for an operation (e.g. to upload or download a mission). This is carried in a [MISSION_ACK](#MISSION_ACK). | -| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Co-ordinate frame for position/velocity/acceleration data in the message. | +| [MAV_FRAME](../messages/common.md#MAV_FRAME) | Coordinate frame for position/velocity/acceleration data in the message. | | [MAV_CMD](../messages/common.md#mav_commands) | [Mission Items](#mavlink_commands) (and MAVLink commands) sent in [MISSION_ITEM_INT](#MISSION_ITEM_INT). | ## Deprecated Types: MISSION_ITEM {#command_message_type} @@ -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 @@ -120,7 +120,7 @@ The table below shows that the positional parameters can be local (x, y, z), glo | param6 | `int32_t` | y | Longitude | | param7 | `float` | z | Altitude (global - relative or absolute) | -The co-ordinate frame of positional parameters is defined in the `MISSION_ITEM_INT.frame` field using a [MAV_FRAME](#MAV_FRAME) value. +The coordinate frame of positional parameters is defined in the `MISSION_ITEM_INT.frame` field using a [MAV_FRAME](#MAV_FRAME) value. The global frames are prefixed with `MAV_FRAME_GLOBAL_*`. Mission items should use frame variants that have the suffix `_INT`: e.g. `MAV_FRAME_GLOBAL_RELATIVE_ALT_INT`, `MAV_FRAME_GLOBAL_INT`, `MAV_FRAME_GLOBAL_TERRAIN_ALT_INT`. @@ -539,7 +539,7 @@ The following behaviour is not defined by the specification (but is still of int - ArduPilot performs some validation of fields when mission items are submitted. The validation code is common to all vehicles; mission items that are not understood by the vehicle type are accepted on upload but skipped during mission execution. -- ArduPilot preforms some vehicle-specific validation at mission runtime (e.g. of jump targets). +- ArduPilot performs some vehicle-specific validation at mission runtime (e.g. of jump targets). - A new mission can be uploaded while a mission is being executed. In this case the current waypoint will be executed to completion even if the waypoint sequence is different in the new mission (to get the new item you would need to reset the sequence or switch in/out of auto mode). - ArduPilot missions are not stored in an SD card and therefore have a vehicle/board-specific maximum mission size (as a benefit, on ArduPilot, missions can survive SD card failure in flight). diff --git a/zh/services/offboard_control.md b/zh/services/offboard_control.md index 335b18377..0039831db 100644 --- a/zh/services/offboard_control.md +++ b/zh/services/offboard_control.md @@ -5,7 +5,7 @@ The offboard control interface allows an external controller to send low-level a This is commonly used to provide external control of a real-time flight stack from a companion/mission computer, for example, in order to implement features such as obstacle avoidance or collision prevention. Generally setpoints are only obeyed in a specific flight-stack mode. -The flight stack requires the setpoints to be recieved for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received. +The flight stack requires the setpoints to be received for some time before it will allow the mode to be enabled, and will switch out of the mode if setpoints are no longer received. The particular types of setpoints that are supported, if any, depend on the vehicle type and flight stack. @@ -13,7 +13,7 @@ The particular types of setpoints that are supported, if any, depend on the vehi | 消息 | 描述 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | -| [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. | +| [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. | | [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) | | [SET_ATTITUDE_TARGET](../messages/common.md#SET_ATTITUDE_TARGET) | Sets a desired vehicle attitude. | | [POSITION_TARGET_LOCAL_NED](../messages/common.md#POSITION_TARGET_LOCAL_NED) | Publishes current local NED target (set by `SET_POSITION_TARGET_LOCAL_NED`). | diff --git a/zh/services/parameter.md b/zh/services/parameter.md index 437110e29..ca5b359c2 100644 --- a/zh/services/parameter.md +++ b/zh/services/parameter.md @@ -141,7 +141,7 @@ If working with a non-compliant component, the risk of problems when working wit A GCS (or other component) that wants to [cache parameters](#parameter_caching) with a component and keep them synchronised, should first get all parameters, and then track any new parameter changes by monitoring for `PARAM_VALUE` messages (updating their internal list appropriately). -This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not recieved. +This works for the originator of a parameter change, which can resend the request if an expected `PARAM_VALUE` is not received. This approach may fail for components that did not originate the change, as they will not know about updates they do not receive (i.e. if messages are dropped). A component may mitigate this risk by, for example, sending the `PARAM_VALUE` multiple times after a parameter is changed. @@ -242,7 +242,7 @@ The sequence of operations is: 1. GCS (client) sends [PARAM_SET](../messages/common.md#PARAM_VALUE) specifying the param name to update and its new value (also target system/component and the param type). -2. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message). +2. GCS starts timeout waiting for acknowledgment (in the form of a [PARAM_VALUE](../messages/common.md#PARAM_VALUE) message). 3. Drone writes parameter and responds by _broadcasting_ a `PARAM_VALUE` containing the updated parameter value to all components/systems. diff --git a/zh/services/parameter_ext.md b/zh/services/parameter_ext.md index f89d2e25c..d93dd6b39 100644 --- a/zh/services/parameter_ext.md +++ b/zh/services/parameter_ext.md @@ -263,7 +263,7 @@ sequenceDiagram; The sequence of operations is: 1. GCS (client) sends [PARAM_EXT_SET](../messages/common.md#PARAM_EXT_SET) specifying the param name to update and its new value (also target system/component and the param type). -2. GCS starts timout waiting for acknowledgment (in the form of a [PARAM_EXT_ACK](../messages/common.md#PARAM_EXT_ACK) message). +2. GCS starts timeout waiting for acknowledgment (in the form of a [PARAM_EXT_ACK](../messages/common.md#PARAM_EXT_ACK) message). 3. Drone (starts to) write parameter and responds by _broadcasting_ a `PARAM_EXT_ACK`. - If the write succeeded the `PARAM_EXT_ACK` will contain a result of `PARAM_ACK_ACCEPTED` and the updated parameter value. - If the parameter was unknown or of an unsupported type `PARAM_EXT_ACK` will contain a result of `PARAM_ACK_VALUE_UNSUPPORTED` and the current parameter value will be XXXXX. diff --git a/zh/services/payload.md b/zh/services/payload.md index bc219bb6e..efd0dbb9c 100644 --- a/zh/services/payload.md +++ b/zh/services/payload.md @@ -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. | 消息 | 描述 | | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | diff --git a/zh/services/traffic_management.md b/zh/services/traffic_management.md index e3e3ba7cf..675e23179 100644 --- a/zh/services/traffic_management.md +++ b/zh/services/traffic_management.md @@ -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 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. 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, :::