mavlink/mavlink-devguide

How do we cancel a mission upload/download?

hamishwillee opened this issue · 15 comments

hamishwillee commented

Mission Protocol · MAVLink Developer Guide does not explain how to cancel a partially completed download/upload.

For download everything is driven by the GCS/API and that can just stop getting items whenever it likes - ie cancelling is just stopping.

For upload of mission to vehicle the API initiates the upload, which starts the process of the drone requesting mission items (which are returned in MISSION_ITEM or MISSION_ITEM_INT). In this case there is no ACK in the sequence, so how does an API tell the drone that it is ignoring future mission item requests and stopping the upload?

@julianoes , any ideas?

hamishwillee commented

Further to this,

  1. What is the state of the mission during upload?
    • If I start uploading items, can the mission be running?
  2. Is the update robust? i.e. if I update the mission and then cancel it or stop supplying items, is the mission reverted to the original set, or does it have some of the items from the original set and some from the new set?
  3. When a message is finished, is there a state machine that says the mission is no longer running? ie currently our docs talk about missions running to a pause or to completion, but our fail states sometimes talk about a mission being "as if complete". That is fine, except that we don't define what that state means. I assume it means:
    • "mission has been running and has either completed or failed?
    • It is no longer running and needs to be restarted/reset to run again.".
  4. Is a partial mission upload allowed - ie i just send one item to the autopilot?
julianoes commented
  1. What is the state of the mission during upload?
    • If I start uploading items, can the mission be running?

This is how it works for PX4: There we have to storage places for missions, one is the current mission potentially being executed, and a second one for an ongoing transfer. The controller only switches over to a new mission if the mission has successfully been fully transferred. Therefore, if anything happens during the transfer like an error or a timeout, the controller won't use the uploaded items ever. For the case of cancellation, the SDK sends a MISSION_ACK_DENIED meaning that the mission transfer has been denied.

  1. Is the update robust? i.e. if I update the mission and then cancel it or stop supplying items, is the mission reverted to the original set, or does it have some of the items from the original set and some from the new set?

Yes, it is (and should be) reverted at what it was. Or an alternative implementation would end up with no mission at that point and just have to loiter.

  1. When a message is finished, is there a state machine that says the mission is no longer running? ie currently our docs talk about missions running to a pause or to completion, but our fail states sometimes talk about a mission being "as if complete". That is fine, except that we don't define what that state means. I assume it means:
    • "mission has been running and has either completed or failed?
    • It is no longer running and needs to be restarted/reset to run again.".

The SDK uses the last "current mission item" and checks it again "total mission items" and if current + 1 == total it usually means we're done. Although it can get tricky for things like automatic RTL after mission. For that case, is the mission finished when RTL is triggered or is RTL then part of the mission.
What I would prefer and what might happen is that we switch to LOITER (or RTL) after a mission is done.

  1. Is a partial mission upload allowed - ie i just send one item to the autopilot?

It's not implemented for PX4 as far as I know.

hamishwillee commented

How does PX4 handle invalid items - ie if a mission item wasn't supported? Would it still be accepted but just skipped?

hamishwillee commented

@julianoes Stop pretending you don't know everything :-)

  • ❤️1
julianoes commented

I don't, I only sometimes know where to look for.

  • 🎉1
hamishwillee commented

:-). Does PX4 fully support the geofence and rally point protocol too? MY understanding is that geofence is supported, but not rally points.

julianoes commented

Ha! I don't know and looking at the code won't give a conclusive answer.

hamishwillee commented

:-)

OK, so re cancellation:

For the case of cancellation, the SDK sends a MISSION_ACK_DENIED meaning that the mission transfer has been denied.

This works for downloading, because PX4 will set system back to idle: https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_mission.cpp#L625 (and do warning)

However for uploading to drone the PX4 understands that an early ACK is a fail case (https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_mission.cpp#L641) and reports a warning, but it doesn't cancel the expected upload. It will (based on inspection) basically wait for a bit and then start resending MISSION_REQUEST_INT for a number of retries.

So is that tested?

hamishwillee commented

Also, I think perhaps we should properly support the cancel case with a cancelled enum value?

julianoes commented

I suppose we should handle it properly on the PX4 side instead of resending, that's indeed a good suggestion.

So is that tested?

It worked but did produce some incorrect error messages on the PX4 side.

hamishwillee commented

Great. I've created mavlink/mavlink#1044 for a proper error report, after which "someone" will be able to fix up PX4.

  • 👍1
hamishwillee commented

Fixed by 1044

julianoes commented

@hamishwillee someone was eventually me: PX4/PX4-Autopilot#14139 😄

  • 😄1