MissionProtocol: Partial upload/download

[hamishwillee]

This updates the sections for partial upload/download of missions. PX4 does not implement this so what I have done is inferred sensible operation from the normal upload/download and reviewed ArduPilot implementation.

Would be good if I can get some confirmation that the proposal is sensible even though it might not perfectly match what ArduPilot does @WickedShell, @auturgy . Rendered version is here: https://hamishwillee.gitbooks.io/ham_mavdevguide/content/v/mission_ap/en/services/mission.html#upload_partial

What I have said is

1. Partial upload is JUST LIKE full upload except it is triggered by MISSION_WRITE_PARTIAL_LIST instead of a MISSION_COUNT
   • I have stated that this has to be robust like a full update (ie update succeeds completely or fails and original state restored). Is this OK? [NOTE, ArduPilot just overwrites the existing item]
2. Partial download does not have a clear mapping to full download.
   • After MISSION_REQUEST_PARTIAL_LIST is sent there is no obvious ACK to tell GCS that it should now request items (for full download drone returns MISSION_COUNT).
   • What I think happens is that after MISSION_REQUEST_PARTIAL_LIST is sent the GCS just starts requesting mission items. The drone can be set up to always return any particular item on request with out any problem. Is that reasonable?

[hamishwillee]

Note, this is PX4 but not ArduPilot implementation for full mission upload. I have assumed the same for partial update. Will clarify for ArduPilot in the implemetation section.

[WickedShell]

Partial download does not have a clear mapping to full download.

• After MISSION_REQUEST_PARTIAL_LIST is sent there is no obvious ACK to tell GCS that it should now request items (for full download drone returns MISSION_COUNT).
• What I think happens is that after MISSION_REQUEST_PARTIAL_LIST is sent the GCS just starts requesting mission items. The drone can be set up to always return any particular item on request with out any problem. Is that reasonable?

ArduPilot doesn't implement that message at all that I can find. If you think about it the GCS should be able to just request whatever it wants (ArduPilot is fine with this anyways) in which case this isn't needed. If we ever had proper transactions exposed over MAVLink then this message would have utility, but till then I think it's mostly a noop/not worth implementing anywhere.

• I have stated that this has to be robust like a full update (ie update succeeds completely or fails and original state restored). Is this OK? [NOTE, ArduPilot just overwrites the existing item]

ArduPilot won't do this as missions aren't transactional there (nor is there a proper MAVLink way to tell if they are/aren't/who is coordinating a transaction).

[WickedShell]

The download seems confusing because functionally I can't tell what the aircraft is supposed to do with the start/end messages.

[hamishwillee]

@LorenzMeier @WickedShell Can we change the implied sequence for partial mission download which is documented here - which is used by neither ArduPilot or PX4?

What I'd like is that the GCS can query for any mission item if it is not in another operation (e.g. idle), and get either the item or an ACK with an error.

My reasoning is that MISSION_REQUEST_PARTIAL_LIST appears to be intended to tell the drone to prepare for download. However their is no acknowledgement or real need for this if you accept that when in idle the mission should be in a stable state (ie ready to read or empty). Or to put it as@WickedShell did

"ArduPilot won't do this as missions aren't transactional there (nor is there a proper MAVLink way to tell if they are/aren't/who is coordinating a transaction)."

Note, this PR is nearly ready for re-review following integration of feedback from @WickedShell - but I would like to resolve this issue first.

[hamishwillee]

@LorenzMeier @WickedShell This is a new section. It is irrelevant to ArduPilot, which does not allow cancellation or treat errors as unrecoverable.
There will also need to be fixes to PX4/QGC to allow mission cancellation during uploading.

[hamishwillee]

This needs review. Specifically, the assumption is that a mission is cancelled by responding to an ACK with MAV_MISSION_OPERATION_CANCELLED - and that is reasonable. But

1. you could argue that a separate message is required for this to enable cancelling at any point - not just after receiving a message.
2. If the ack with cancellation does not arrive then the request will be re-sent. The cancelling system will now be in idle getting an out of sequence message, so will respond with a different error. I think that is OK/good response - ie no need to cache the ack until you're sure the other system got it.

[hamishwillee]

@LorenzMeier This is updated as we discussed so should now be ready to merge - you OK with that? Specifically it now states that partial updates must be robust in the same way as full updates are.

[LorenzMeier]

Clearly an improvement over the previous spec, merging.

[hamishwillee]

Thanks @LorenzMeier . This was definitely a doc improvement.

FYI It was not merged because it had info about partial mission upload/download that was unresolved when I wrote this. That since has been agree in our discussion to not be part of the current service specification. I removed those bits of this in #231