MAV_CMD_MISSION_START - more explicit about takeoff

[hamishwillee]

MAV_CMD_MISSION_START description was just "start a mission", with start and end points.

This PR adds information about what should happen in the edge cases. Specifically, what if you get the command when you're not flying and the selected start point is in the air. What happens if the first command is to takeoff and you're already flying.

It reflects what ArduPilot and PX4 actually do. However if a flight stack wanted to just reject a mission if it was landed and the selected start point was not a takeoff, that would be OK too under the new wording.

@sfuhrer FYI

[julianoes]

I assume that's all correct but what you're documenting is not really a property of MAV_CMD_MISSION_START but in general of mission. You can also start missions by switching to mission mode.

[hamishwillee]

@julianoes That true. But if this is true it does no harm to put it here. Or perhaps to put it in "Mission MicroService" docs and link to that. Either way, this is a good test of what people think is reasonable expectation on starting a mission.

[hamishwillee]

My plan is to add a Mission Execution section (and possibly mission validation) in the mission microservice doc about here.
This update can then refer to that info.

@julianoes Can you answer/confirm any of the below? Who else might know? My plan is to get as much info as I can, then test on PX4, then confirm with ArduPilot that they have matching implementation. Upshot, no stress if you can't answer anything - but anything you know will save me time.

To do this I need to understand:

• Mission validation: when it happens (on upload, before starting, during execution), what it does (fail upload, reject starting, skip item)
• When a mission ends how it is reset? (i.e. my understanding is that perhaps you have to actually re-arm the vehicle. But perhaps you can just switch in/out of Mission mode?_
• How is state reporting done
  • ie should MISSION_CURRENT be streamed?
  • When paused, or mission finished, how can GCS know that?
• Behaviour on uploading new mission during mission and on ground - in particular what if the mission specifies a current mission point.

Some thoughts/and those same questions below.

1. Missions are comprised of an ordered (numbered) set of mission items (MAV_CMDs).
   1. Q: What does a vehicle do if it doesn't implement a mission item during upload? Store it (and ignore during execution)? Reject whole mission?
   2. Q: What does a vehicle do if a mission item is invalid for the current vehicle type during execution - e.g. VTOL takeoff for a Fixed wing? Or Winch, when no winch present?
2. Mission items are executed in order, but can loop using MAV_CMD_DO_JUMP, MAV_CMD_JUMP_TAG, MAV_CMD_DO_JUMP_TAG (if supported)
3. Mission execution has the concept of "current mission item". This is the item that will be executed when the mission is running (if a waypoint, it is the one we will towards).
   • Note, this concept represents the current mission item number if the mission is running and the start point if it is not.
4. The current mission item is emitted by the flight stack in MISSION_CURRENT
   1. Q: When is this emitted? (streamed? when it changes? When MISSION_SET_CURRENT or MAV_CMD_DO_SET_MISSION_CURRENT is called?)
   2. Q: Does this start at 0?
5. MISSION_SET_CURRENT and MAV_CMD_DO_SET_MISSION_CURRENT can set the current mission item.
   1. Note that this does not start the mission - if the mission is not executing, all it does is reset the start point.
   2. Note that this does not "reset" the mission. Any loops counters etc that have already executed do not get reset.
   3. Q: Is one of these recommended/deprecated? They do the same thing
6. Mission execution can be started in a number of ways:
   1. Switching to mission mode (starts from current mission number, whatever that is)
   2. Calling MAV_CMD_MISSION_START, specifying start and end items.
   3. ? Any others?
7. A running mission can be paused using MAV_CMD_DO_PAUSE_CONTINUE - the current mission item does not change. Vehicle loiters.
   1. Q: How can a GCS know that the mission is paused? - anything emitted? State changes?
8. MAV_CMD_OVERRIDE_GOTO - similar questions. What is the state/how does system know?
9. MAV_CMD_DO_LAST, MAV_CMD_CONDITION_LAST, MAV_CMD_NAV_LAST - what are these for/how are they used?
10. A mission ends when it has met the conditions of the last item in the mission (or the last specified when MAV_CMD_MISSION_START was called).
    1. Q: When it has ended, what does it do? Loiter if flying. Disarm if landed? Does the mission mode change?
    2. Q: How do I reset the mission so I can restart? is this done on arming, or switching in/out of mission mode?
11. Uploading a new mission - what happens?
    1. My understanding is that if executing a mission already the existing item is completed.
       The new mission is executed from once the current mission item completes, starting from the next mission item number.
       • i.e. the mission number is not reset by uploading a new mission.
       • Q: Is that true? What if the mission to be uploaded specifies a mission item as "Current" (which it can)?
12. A mission will start at the current start point (or the specified start point)

    • If needed to start the mission, vehicles should first attempt to arm, switch to mission mode, and takeoff.
      The flight stack may reject the command if it is unable to perform these operations.

      • Note: If the selected start mission item does not start a takeoff operation/sequence, the flight stack may takeoff using the "default takeoff mode" for the vehicle type.
      • Note: A flight stack will ignore valid mission commands that are not appropriate for the current vehicle state. For example, it will ignore a command to takeoff if it is already flying.

[julianoes]

I'll try to answer for PX4 based on what I know without code inspection.

Mission validation: when it happens (on upload, before starting, during execution), what it does (fail upload, reject starting, skip item)

For PX4 it currently happens after upload. However, it should happen on upload instead. The problem with the former is that after an upload, the existing mission is deleted, so then you are left with the new mission which might potentially not be feasible, and so you're left without a mission. In the case of fixedwing, you actually require a mission to do a safe landing, so this is a potential problem.

However, the problem with checking on upload is that you might not have all information yet. For instance, the geofence might not have been uploaded yet by that time. Or you don't know where your home position is if you are planning this beforehand/offline. For that case you still need a check right before taking off.

When a mission ends how it is reset? (i.e. my understanding is that perhaps you have to actually re-arm the vehicle. But perhaps you can just switch in/out of Mission mode?_

I'm not 100% sure. There are points to be made for "on disarm" or on "re-upload", or "reboot".

ie should MISSION_CURRENT be streamed?

I think it is and it should be.

When paused, or mission finished, how can GCS know that?

In my mind "paused" means we switched to Hold/Loiter. "Finished" means the last item has been set as "reached". At that point I would also expect the mode to switch to either RTL or Hold/Loiter based on the fact whether the last mission item was an RTL command, or whether a failsafe triggered after the mission.

Behaviour on uploading new mission during mission and on ground - in particular what if the mission specifies a current mission point.

I don't know if this "current" is respected or just ignored. My hunch is that it is ignored but it's something to verify.

---

1. 1. It should reject the mission. And I'm pretty sure PX4 does that, although not on upload but when trying to start it. (as part of the mission feasibility check).
   2. It should trigger it during mission feasibility checking but I'm not sure if it does.
2. Yes, and I find that a tricky feature. It's convenient but one problem with it is that there is no clear feedback to the user of what the progress is.
4. 1. When it changes and at some rate, e.g. 1 Hz.
   2. I think yes.
5. 1. Right.
   2. Right.
   3. Not sure.
6. 1. Yes
   2. Presumably.
   3. All others involve changing the mode, e.g. RC.
7. 1. I would hope the state changes on that.
8. I did not know that existed (there might be dragons).
9. Again, didn't know they exist.
10. 1. As explained above. For PX4 it goes to Loiter, or in a failsafe mode, e.g. because it was ok to run the mission without RC but it's not ok to loiter (forever) without RC.
    2. In QGC you can click on the first item (or any other) and it will set that to current. Or you can re-upload the mission.
11. 1. No existing item is completed. As soon as the new mission has finished uploading (A/B schema) the drone will switch to the new mission. And it starts from 0. If current is set, I'm not sure if that is taken into account.
12. I think that's correct.

[hamishwillee]

Thanks very much! I'll have a think about this.

FWIW Another case requiring that you check mission validity before execution is after changing airframe.

[julianoes]

Another case requiring that you check mission validity before execution is after changing airframe.

Changing airframe needs a reboot with PX4, so at that point you re-read and re-validate the mission anyway.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.