Update mission protocol with info old site #88
Conversation
en/protocol/mission.md
Outdated
|
|
||
| MAVLink 2 supports several different mission types in the [MISSION_COUNT](../messages/common.md#MISSION_COUNT) and [MISSION_REQUEST](../messages/common.md#MISSION_REQUEST) messages using the `mission_type` field. This instructs the autopilot to read and write to different lists containing the regular mission ([MAV_MISSION_TYPE_MISSION](../messages/common.md#MAV_MISSION_TYPE_MISSION)), geofence ([MAV_MISSION_TYPE_FENCE](../messages/common.md#MAV_MISSION_TYPE_FENCE)) and safe points used as alternate landing sites ([MAV_MISSION_TYPE_RALLY](../messages/common.md#MAV_MISSION_TYPE_RALLY)). | ||
| The protocol supports re-request of messages that have not arrived, allowing missions to be reliably transferred over a lossy link. <!-- not quite guaranteed :-) --> |
There was a problem hiding this comment.
FYI, we can't really say "guaranteed". We make more reliable with resends, but we do fail on a certain number of resends and if the link goes down.
en/protocol/mission.md
Outdated
|
|
||
| ## Upload a Mission to the Vehicle | ||
| MAVLink 1 supports only "regular" missions. |
There was a problem hiding this comment.
Tried to make this section more clear. I "assume" that if you use the MAVLink 2 library but specify MAVLink 1 the mission type you enter will be ignored. But in either case, the protocol expects you to ignore it, because it doesn't "exist" for MAVLink 1.
| - On failure, `type` must set to [MAV_MISSION_ERROR](../messages/common.md#MAV_MISSION_ERROR) or some other error code. | ||
| 1. GCS receives `MISSION_ACK`: | ||
| - If `MAV_MISSION_ACCEPTED` the operation is complete. | ||
| - If an error, the transaction fails but may be retried. <!-- not clear here --> |
There was a problem hiding this comment.
I am not 100% sure of the handling here if the transaction fails. It appears to be that there is cleanup and an error message.
There was a problem hiding this comment.
Sorry, I missed this PR. If the mission is rejected, there is no cleanup, the transaction gets aborted. I also don't know how other autopilots implement it, but PX4 has a double buffer - if the transaction fails, it does not replace the current mission.
en/protocol/mission.md
Outdated
| Note: | ||
| - The GCS (client) sets a [timeout](#timeout) after every message and will resend if there is no response from the vehicle. | ||
| - The client will re-request mission items that are received out of sequence. | ||
| - The protocol also works with "similar" messages: [MISSION_ITEM_INT](../messages/common.md#MISSION_ITEM_INT) and [MISSION_REQUEST_INT](../messages/common.md#MISSION_REQUEST_INT). |
There was a problem hiding this comment.
Why do we need these different types?
| @@ -122,4 +249,36 @@ The standard file format for missions is JSON, as implemented in the QGroundCont | |||
| ``` | |||
|
|
|||
|
|
|||
| ## Plain Text File Format | |||
There was a problem hiding this comment.
This is a defacto standard. I think worth keeping the information.
|
Can I please get this checked @LorenzMeier |
Merge interesting content from http://qgroundcontrol.org/mavlink/waypoint_protocol and http://qgroundcontrol.org/mavlink/mission_interface
This is ready to review.
Still some open questions, but I have captured them separately in #95