Typos and grammer fixes (#678)

Author: av-remco

en/services/camera.md

@@ -33,7 +33,7 @@ These cameras have inbuilt support for MAVLink (but not necessarily camera proto
 
 MAVLink cameras are identified and addressed by their system and component id.
 
-Components that have non-MAVLink cameras attached, such as companion computers, are expected expose each of them as a separate MAVLink camera component with its own `HEARTBEAT`.
+Components that have non-MAVLink cameras attached, such as companion computers, are expected to expose each of them as a separate MAVLink camera component with its own `HEARTBEAT`.
 
 The exception is the _autopilot_ component, which can "proxy" up to 6 attached non-MAVLink cameras: these are identified by a `camera_device_id` field in messages and `Target Camera ID` label in commands.
 
@@ -235,7 +235,7 @@ For formatting (or erasing depending on your implementation), the GCS will send
 
 ### Camera Capture Status
 
-In addition to querying about storage status, the GCS should also stream the _Camera Capture Status_ in order to provide the user with proper UI indicators.
+In addition to querying about storage status, the GCS should also request a stream of `CAMERA_CAPTURE_STATUS` messages in order to provide the user with proper UI indicators.
 
 This can be done by sending a [MAV_CMD_SET_MESSAGE_INTERVAL](../messages/common.md#MAV_CMD_SET_MESSAGE_INTERVAL) command asking for [CAMERA_CAPTURE_STATUS](../messages/common.md#CAMERA_CAPTURE_STATUS).
 The command it expects a [COMMAND_ACK](../messages/common.md#COMMAND_ACK) message back and then [CAMERA_CAPTURE_STATUS](../messages/common.md#CAMERA_CAPTURE_STATUS) should be streamed at the specified rate.
@@ -282,7 +282,7 @@ The message sequence for _interactive user-initiated image capture_ through a GU
 In this case the GCS should:
 
 - Confirm that the camera is _ready_ to take images before allowing the user to request image capture.
-  - It does this by by sending [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE) asking for [CAMERA_CAPTURE_STATUS](../messages/common.md#CAMERA_CAPTURE_STATUS).
+  - It does this by sending [MAV_CMD_REQUEST_MESSAGE](../messages/common.md#MAV_CMD_REQUEST_MESSAGE) asking for [CAMERA_CAPTURE_STATUS](../messages/common.md#CAMERA_CAPTURE_STATUS).
   - The camera should return a `MAV_RESULT` and then [CAMERA_CAPTURE_STATUS](../messages/common.md#CAMERA_CAPTURE_STATUS).
   - The GCS should check that the status is "Idle" before enabling camera capture in the GUI.
 - Send [MAV_CMD_IMAGE_START_CAPTURE](../messages/common.md#MAV_CMD_IMAGE_START_CAPTURE) specifying a single image (only).
@@ -424,7 +424,39 @@ The GCS should already have identified all connected cameras by their heartbeat
 
 The sequence for tracking a point is shown below (tracking a rectangle is the same sequence but a different tracking command).
 
-[![Mermaid Sequence: tracking info](https://mermaid.ink/img/pako:eNqlVGFvmzAQ_SuWP6USi5ZKWyW2RLIIYWgBIkz7CQm54CTWgs2M2VRV_e8zmCyobaImAQkd9t299853foa5KCi0YU1_N5TndM7IRpLyW8qBfioiFctZRbgCnoPfLjqkpJKY9VAoCsQfKltXy-zYwF8ABwVujDIHrbLFEnk4-4FwlsTI-emHXraK_DD5_ihnjO89_XARxQFK_Cgcr3dkU7fboFYaGChJ8l-Mb0AlGFcGWeN9ms32iAF6yJxgnvXJOiCDMgIp7MIA42shS6KY4CkENyaNSaAz6XwmTezi-2WSIcdxV4k7b91Sbt43im2AqdIkJSVly08SRVveQxqtXj9AnpvhBCX3-BR97CZZ4GLcemvubvyAliNde1JOprd3X6zOvJ1OPhvrbjo5R8YHyIPXzD036nm3ukZ1U1VCnwirAanrpqRgSyW9uVzT16s0vVZlQqwuwNi9vvrQQ4M2AJpHrbcE2LDykezeBT51lmA0-VDMoYqHCPBe4Hg8Pjcfv4B1G3OqdvqjCyeqQdkILwa98ndLOdA_xdOxsxpMI06i1X8mx0p2tGevmpRLB-WqVj4fFFpQe5SEFfpafu6uHKi2tKQptLVZ0DVpdiqFKX_Rrk1V6FF1C6aEhPaa7GpqQdIogZ94Dm0lG7p36q_23uvlH-Jn1w4?type=png)](https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNqlVGFvmzAQ_SuWP6USi5ZKWyW2RLIIYWgBIkz7CQm54CTWgs2M2VRV_e8zmCyobaImAQkd9t299853foa5KCi0YU1_N5TndM7IRpLyW8qBfioiFctZRbgCnoPfLjqkpJKY9VAoCsQfKltXy-zYwF8ABwVujDIHrbLFEnk4-4FwlsTI-emHXraK_DD5_ihnjO89_XARxQFK_Cgcr3dkU7fboFYaGChJ8l-Mb0AlGFcGWeN9ms32iAF6yJxgnvXJOiCDMgIp7MIA42shS6KY4CkENyaNSaAz6XwmTezi-2WSIcdxV4k7b91Sbt43im2AqdIkJSVly08SRVveQxqtXj9AnpvhBCX3-BR97CZZ4GLcemvubvyAliNde1JOprd3X6zOvJ1OPhvrbjo5R8YHyIPXzD036nm3ukZ1U1VCnwirAanrpqRgSyW9uVzT16s0vVZlQqwuwNi9vvrQQ4M2AJpHrbcE2LDykezeBT51lmA0-VDMoYqHCPBe4Hg8Pjcfv4B1G3OqdvqjCyeqQdkILwa98ndLOdA_xdOxsxpMI06i1X8mx0p2tGevmpRLB-WqVj4fFFpQe5SEFfpafu6uHKi2tKQptLVZ0DVpdiqFKX_Rrk1V6FF1C6aEhPaa7GpqQdIogZ94Dm0lG7p36q_23uvlH-Jn1w4)
+[![Mermaid Sequence: tracking info](https://mermaid.ink/img/pako:eNqlVNuOmzAQ_RXLT1mJImDJhtAmEiIkRc1Ngd2HKhLyBoegDTY1Zts0yr_XQG5Kd6NceEBjz5w5Z8Zjr-GMhhiaMMO_ckxmuBOjiKHk65QA8aWI8XgWp4hw0LO9_zdtlGCGqv0h5RjQd8yKUKnymMDtAtsaOBMrsK1x0O1bPS_4bnmBP7HsH-6wF4xH7tD_9sraMdlFusPuaDKwfHc0lOdLFGWFG2RcEAPO0OwtJhFIaUx4xSz4vrTbO8aB9RLYg06wTVYSVSw1MIUlDMRkTlmCeEzJFIKHKk2VQGQS-ao0E8d77vuBZdvO2Hc6RdgHtZrAw1zIYxglhTKGOC4UHwsoKnUHVs8JPN_yn71zwj3HDwaO5xXRQrUzebH6NdF1lKgtrVGXSlNrqUplNVrqNQVcIB6cKu85o63uoq5alqcpFWcRZwBlWZ5gsMAMP9xe09NdNZ1WVUGkElDZ2_qyw_QcDQAQOjLhoiCKk1e0_JD43FmCmnoR5tDFAwJ8BJRl-dp85AbVBeZc78RPNI6mR21DJDyald8LTIBYhKsL7qHnj8Z7JZ-17NOZveum3HpR7hrl60mhBCMWh9DkLMcSFNEJKpZwXT48kC9wgqfQFGaI2NsUTslGYMRD_JPSZAdjNI8W0JyjZSZWeRqKC7191U92nTDmlO03Uc6ptyKzfSJMQsxsmhMOTU0tiaC5hn-gqat1uanrj7pqNBRD14xHCa6gqepN2ag3Na1hNA1dUfSNBP-W0hS5UVd0Q6sLr6Krivq0-QcBRvlk?type=png)](https://mermaid.live/edit#pako:eNqlVNuOmzAQ_RXLT1mJImDJhtAmEiIkRc1Ngd2HKhLyBoegDTY1Zts0yr_XQG5Kd6NceEBjz5w5Z8Zjr-GMhhiaMMO_ckxmuBOjiKHk65QA8aWI8XgWp4hw0LO9_zdtlGCGqv0h5RjQd8yKUKnymMDtAtsaOBMrsK1x0O1bPS_4bnmBP7HsH-6wF4xH7tD_9sraMdlFusPuaDKwfHc0lOdLFGWFG2RcEAPO0OwtJhFIaUx4xSz4vrTbO8aB9RLYg06wTVYSVSw1MIUlDMRkTlmCeEzJFIKHKk2VQGQS-ao0E8d77vuBZdvO2Hc6RdgHtZrAw1zIYxglhTKGOC4UHwsoKnUHVs8JPN_yn71zwj3HDwaO5xXRQrUzebH6NdF1lKgtrVGXSlNrqUplNVrqNQVcIB6cKu85o63uoq5alqcpFWcRZwBlWZ5gsMAMP9xe09NdNZ1WVUGkElDZ2_qyw_QcDQAQOjLhoiCKk1e0_JD43FmCmnoR5tDFAwJ8BJRl-dp85AbVBeZc78RPNI6mR21DJDyald8LTIBYhKsL7qHnj8Z7JZ-17NOZveum3HpR7hrl60mhBCMWh9DkLMcSFNEJKpZwXT48kC9wgqfQFGaI2NsUTslGYMRD_JPSZAdjNI8W0JyjZSZWeRqKC7191U92nTDmlO03Uc6ptyKzfSJMQsxsmhMOTU0tiaC5hn-gqat1uanrj7pqNBRD14xHCa6gqepN2ag3Na1hNA1dUfSNBP-W0hS5UVd0Q6sLr6Krivq0-QcBRvlk)
+
+<!-- Original sequence
+sequenceDiagram;
+    participant GCS
+    participant Camera
+    Note over GCS,Camera: IF CAMERA_CAP_FLAGS_HAS_TRACKING_POINT<br>in CAMERA_INFORMATION.flags<br> start tracking point
+    GCS->>Camera: MAV_CMD_CAMERA_TRACK_POINT( "point information" )
+    Camera->>GCS: MAV_RESULT_ACCEPTED
+
+    Note over GCS: Set streaming rate<br>CAMERA_TRACKING_IMAGE_STATUS
+    GCS->>Camera: MAV_CMD_SET_MESSAGE_INTERVAL(param1=275,param2=10,param7=1)
+    Camera->>GCS: MAV_RESULT_ACCEPTED
+    Note over GCS: Set streaming rate CAMERA_TRACKING_GEO_STATUS<br>(support is assume here)
+    GCS->>Camera: MAV_CMD_SET_MESSAGE_INTERVAL(param1=276,param2=10,param7=1)
+    Camera->>GCS: MAV_RESULT_ACCEPTED
+
+    Note over Camera,GCS: Camera streams tracking information (pass to gimbal)
+    Camera->>GCS: CAMERA_TRACKING_IMAGE_STATUS (1)
+    Camera->>GCS: CAMERA_TRACKING_GEO_STATUS (1)
+
+    Camera->>GCS: ...
+    Camera->>GCS: CAMERA_TRACKING_GEO_STATUS (n)
+    Camera->>GCS: CAMERA_TRACKING_IMAGE_STATUS (n)
+
+    Note over Camera,GCS: GCS stops tracking and streaming when ready
+    GCS->>Camera: MAV_CMD_CAMERA_STOP_TRACKING (1)
+    Camera->>GCS: MAV_RESULT_ACCEPTED
+    GCS->>Camera: MAV_CMD_SET_MESSAGE_INTERVAL(param1=275,param2=0,param7=1)
+    Camera->>GCS: MAV_RESULT_ACCEPTED
+    GCS->>Camera: MAV_CMD_SET_MESSAGE_INTERVAL(param1=276,param2=0,param7=1)
+    Camera->>GCS: MAV_RESULT_ACCEPTED
+-->
 
 The steps are:
 
@@ -456,7 +488,7 @@ Other components like a GCS will typically only use the camera `BATTERY_STATUS.b
 | <a id="VIDEO_STREAM_STATUS"></a>[VIDEO_STREAM_STATUS](../messages/common.md#VIDEO_STREAM_STATUS)                            | Information updating a video stream configuration. <!-- TBD? -->                                                                                                                                                                                                                                                                                               |
 | <a id="storage_information"></a>[STORAGE_INFORMATION](../messages/common.md#STORAGE_INFORMATION)                            | Storage information (e.g. number and type of storage devices, total/used/available capacity, read/write speeds).                                                                                                                                                                                                                                               |
 | <a id="CAMERA_CAPTURE_STATUS"></a>[CAMERA_CAPTURE_STATUS](../messages/common.md#CAMERA_CAPTURE_STATUS)                      | Camera capture status, including current capture type (if any), capture interval, available capacity.                                                                                                                                                                                                                                                          |
-| <a id="CAMERA_IMAGE_CAPTURED"></a>[CAMERA_IMAGE_CAPTURED](../messages/common.md#CAMERA_IMAGE_CAPTURED)                      | Information about image captured (returned to GPS every time an image is captured).                                                                                                                                                                                                                                                                            |
+| <a id="CAMERA_IMAGE_CAPTURED"></a>[CAMERA_IMAGE_CAPTURED](../messages/common.md#CAMERA_IMAGE_CAPTURED)                      | Information about image captured (returned to GCS every time an image is captured).                                                                                                                                                                                                                                                                            |
 | <a id="CAMERA_FOV_STATUS"></a>[CAMERA_FOV_STATUS](../messages/common.md#CAMERA_FOV_STATUS)                                  | Information about the field of view of a camera. Requested using [MAV_CMD_REQUEST_MESSAGE](#MAV_CMD_REQUEST_MESSAGE).                                                                                                                                                                                                                                          |
 | <a id="CAMERA_TRACKING_IMAGE_STATUS"></a>[CAMERA_TRACKING_IMAGE_STATUS](../messages/common.md#CAMERA_TRACKING_IMAGE_STATUS) | Camera tracking status, sent while in active tracking. Use [MAV_CMD_SET_MESSAGE_INTERVAL](../messages/common.md#MAV_CMD_SET_MESSAGE_INTERVAL) to define message interval.                                                                                                                                                                                      |
 | <a id="CAMERA_TRACKING_GEO_STATUS"></a>[CAMERA_TRACKING_GEO_STATUS](../messages/common.md#CAMERA_TRACKING_GEO_STATUS)       | Camera tracking status, sent while in active tracking. Use [MAV_CMD_SET_MESSAGE_INTERVAL](../messages/common.md#MAV_CMD_SET_MESSAGE_INTERVAL) to define message interval.                                                                                                                                                                                      |
@@ -516,4 +548,4 @@ The transition works like this:
 
 1. Cameras need to handle both approaches for now (i.e. support both new generic and old specific commands).
 2. Ground stations will move from using the old specific commands to using both. They can try the new one and if they don't get an answer within a timeout they need to fall back to the previous command.
-3. After the new commands have been established in server and ground stations, the old specific commands may be removed from the implementations.
+3. After the new commands have been established in servers and ground stations, the old specific commands may be removed from the implementations.

en/services/ftp.md

@@ -212,7 +212,7 @@ The sequence of operations is:
 1. GCS sends [TerminateSession](#TerminateSession) to close the file.
    The drone should send an ACK/NAK, but this may (generally speaking) be ignored by the GCS.
 
-The GSC should create a timeout after `OpenFileRO` and `ReadFile` commands are sent and resend the messages as needed (and [described above](#timeouts)).
+The GCS should create a timeout after `OpenFileRO` and `ReadFile` commands are sent and resend the messages as needed (and [described above](#timeouts)).
 A timeout is not set for `TerminateSession` (the server may ignore failure of the command or the ACK).
 
 ### Reading a File (`BurstReadFile`)
@@ -322,7 +322,7 @@ The sequence of operations is:
 1. GCS sends [TerminateSession](#TerminateSession) to close the file.
    The drone should send an ACK/NAK, but this may (generally speaking) be ignored by the GCS.
 
-The GSC should create a timeout after `CreateFile` and `WriteFile` commands are sent, and resend the messages as needed (and [described above](#timeouts)).
+The GCS should create a timeout after `CreateFile` and `WriteFile` commands are sent, and resend the messages as needed (and [described above](#timeouts)).
 A timeout is not set for `TerminateSession` (the server may ignore failure of the command or the ACK).
 
 ::: warning
@@ -362,7 +362,7 @@ The sequence of operations is:
    - NAK on failure, with [error information](#error_codes).
    - The drone must clean up any resources associated with the request after sending the response.
 
-The GSC should create a timeout after the `RemoveFile` command is sent and resend the message as needed (and [described above](#timeouts)).
+The GCS should create a timeout after the `RemoveFile` command is sent and resend the message as needed (and [described above](#timeouts)).
 
 ### Truncate File
 
@@ -394,7 +394,7 @@ The sequence of operations is:
      - The request should fail if the offset is 0 (truncate whole file) and for normal file system errors.
    - The drone must clean up any resources associated with the request after sending the response.
 
-The GSC should create a timeout after the `TruncateFile` command is sent and resend the message as needed (and [described above](#timeouts)).
+The GCS should create a timeout after the `TruncateFile` command is sent and resend the message as needed (and [described above](#timeouts)).
 
 ### List Directory {#list_directory}
 
@@ -446,7 +446,7 @@ The sequence of operations is:
 1. The operation completes when the GCS requests an entry index (`offset`) greater than or equal to the number of entries.
    In this case the drone responds with a [NAK](#error_codes) containing [EOF](#EOF) (end of file).
 
-The GSC should create a timeout after the `ListDirectory` command is sent and resend the message as needed (and [described above](#timeouts)).
+The GCS should create a timeout after the `ListDirectory` command is sent and resend the message as needed (and [described above](#timeouts)).
 
 The drone may also [NAK](#error_codes) with an unexpected error.
 Generally errors are unrecoverable, and the drone must clean up all resources (i.e. close file handles) associated with the request after sending the NAK.
@@ -475,7 +475,7 @@ The sequence of operations is:
    - NAK on failure, with [error information](#error_codes).
    - The drone must clean up any resources associated with the request after sending the response.
 
-The GSC should not create timeouts or handle the NAK case (other than to report an error to the user).
+The GCS should not create timeouts or handle the NAK case (other than to report an error to the user).
 
 ### Remove Directory
 
@@ -506,7 +506,7 @@ The sequence of operations is:
    - NAK on failure, with [error information](#error_codes).
    - The drone must clean up any resources associated with the request after sending the response.
 
-The GSC should create a timeout after the `RemoveDirectory` command is sent and resend the message as needed (and [described above](#timeouts)).
+The GCS should create a timeout after the `RemoveDirectory` command is sent and resend the message as needed (and [described above](#timeouts)).
 
 ## Virtual Directory Entries (Directory Alias)
 

en/services/gimbal_v2.md

@@ -77,7 +77,7 @@ graph LR
 
 [![](https://mermaid.ink/img/eyJjb2RlIjoiZ3JhcGggTFJcblx0YXBbXCJBdXRvcGlsb3RcIl1cblx0Z1tcIkNhbWVyYSAvIEdpbWJhbCAoR2ltYmFsIE1hbmFnZXIpXCJdXG5cdGdjc1tcIkdyb3VuZCBTdGF0aW9uXCJdXG5cdGFwIC0tLXxcIkdpbWJhbCBtYW5hZ2VyIG1lc3NhZ2VzXCJ8IGdcblx0Z2NzIC0tLXxcIkdpbWJhbCBtYW5hZ2VyIG1lc3NhZ2VzXCJ8ZyIsIm1lcm1haWQiOnsidGhlbWUiOiJkZWZhdWx0In0sInVwZGF0ZUVkaXRvciI6ZmFsc2V9)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoiZ3JhcGggTFJcblx0YXBbXCJBdXRvcGlsb3RcIl1cblx0Z1tcIkNhbWVyYSAvIEdpbWJhbCAoR2ltYmFsIE1hbmFnZXIpXCJdXG5cdGdjc1tcIkdyb3VuZCBTdGF0aW9uXCJdXG5cdGFwIC0tLXxcIkdpbWJhbCBtYW5hZ2VyIG1lc3NhZ2VzXCJ8IGdcblx0Z2NzIC0tLXxcIkdpbWJhbCBtYW5hZ2VyIG1lc3NhZ2VzXCJ8ZyIsIm1lcm1haWQiOnsidGhlbWUiOiJkZWZhdWx0In0sInVwZGF0ZUVkaXRvciI6ZmFsc2V9)
 
-#### Onboard Computer with Camera and Gimbal Connected to Autopilot
+#### Onboard Computer with Gimbal Connected to Autopilot
 
 In this set-up the _Gimbal Manager_ can be on the onboard computer.
 

en/services/high_latency.md

@@ -66,7 +66,7 @@ A typical flight sequence might therefore look like:
   - While low latency link is active the mission and parameter protocols can be used.
   - While high latency link is active the vehicle provide telemetry updates but parameters and missions should not be updated.
 
-When the low latency link is lost, the GCS sends [MAV_CMD_CONTROL_HIGH_LATENCY](#MAV_CMD_CONTROL_HIGH_LATENCY) to the vehicle over the high latency channel to turn the high latency link on on (causing the vehicle to start emitting [HIGH_LATENCY2](#HIGH_LATENCY2) messages).
+When the low latency link is lost, the GCS sends [MAV_CMD_CONTROL_HIGH_LATENCY](#MAV_CMD_CONTROL_HIGH_LATENCY) to the vehicle over the high latency channel to turn the high latency link on (causing the vehicle to start emitting [HIGH_LATENCY2](#HIGH_LATENCY2) messages).
 When the low latency link is regained the GCS sends [MAV_CMD_CONTROL_HIGH_LATENCY](#MAV_CMD_CONTROL_HIGH_LATENCY) to stop the vehicle from broadcasting [HIGH_LATENCY2](#HIGH_LATENCY2) messages (usually this would be sent over the low latency link).
 
 The diagram below shows a GCS switching from a higher-latency primary link to a lower latency secondary link when one becomes available, and then back to the higher latency link when the primary link drops out.
@@ -80,4 +80,4 @@ A ground station may also support a handover model, where the high latency link
 This approach allows the GCS to verify that the high latency link is available before losing the low latency connection.
 
 If using this model the GCS and autopilot should be able to work with a mixed regime of low and high latency links.
-Specifically, this means that they should be able to handle the case where the same message is sent over different both channels.
+Specifically, this means that they should be able to handle the case where the same message is sent over both channels.

en/services/image_transmission.md

@@ -63,7 +63,7 @@ sequenceDiagram;
    The sequence number starts at 0 for every new image of the stream.
    :::
 
-1. To stop an image stream a GSC must send a new `DATA_TRANSMISSION_HANDSHAKE` request packet, with all 0 values.
+1. To stop an image stream a GCS must send a new `DATA_TRANSMISSION_HANDSHAKE` request packet, with all 0 values.
    The MAVLink node will acknowledge this by sending back `DATA_TRANSMISSION_HANDSHAKE` also containing 0 values.
 
 ## Usage / Configuration

en/services/mavlink_id_assignment.md

@@ -21,7 +21,7 @@ Instead you must use the [MAV_TYPE](../messages/common.md#MAV_TYPE) defined in t
 
 Any id in the range of 1-255 may be used for a system ID or for its component ids.
 
-By convention autopilots typically have a default system ID of `1`, GSC typically use a default system ID up around 255, and MAVLink SDKs typically use an ID in the middle of the range.
+By convention autopilots typically have a default system ID of `1`, GCS typically use a default system ID up around 255, and MAVLink SDKs typically use an ID in the middle of the range.
 This ensures that simple networks with just one vehicle and ground station are unlikely to have clashing system ids.
 If you have multiple vehicles, ground stations, or other systems on the same network, you will need to ensure they are each allocated their own ID.