Add post-landed behavior setting for NAV_LAND command

[junwoo091400]

Context

With a recent PR in PX4-Autopilot, which introduced the possibility to plan a mission where the vehicle lands & takes off and continues to the next mission item, whereas previously the vehicle would've disarmed and wouldn't continue the mission, the following behavioral change was introduced:

GIF from the PR

Use case that was affected

Let's imagine you are a operator of a simple package delivery service in Hawaii.

You want to plan a mission of package delivery from the bottom of the mountain, to the top, land, and then make it return to launch. The mission flow until now has been something like this:

1. Operator triggers the start of the mission
2. Drone reaches the top of the mountain, lands
3. Drone disarms itself
4. Operator takes the package out of the drone
5. Operator triggers 'mission continue'
6. Drone comes back to the launch

However, with the new change, it would look like this (only step 3 ~ 5 affected)
3. Drone doesn't disarm and idles (keeps spinning the propeller)
4. Operator is suprised as to why the drone didn't disarm
5. Drone takes-off, then flies back to the launch

Solution

The fact that vehicle disarms after landing has been useful in a lot of cases including the example but as well as doing a battery hot-swap (for long-range missions). And until now that was a reasonable assumption. However, with the use cases like package delivery (where the vehicle lands, places the package, then resumes the mission automatically), this assumption doesn't always hold true.

So I would like to propose specifying the "Post Land" behavior in the NAV_LAND command as the Mission item. With this change, without exclusively setting the Bit 1 to indicate "Don't disarm", the vehicle automatically disarming after landing behavior would be preserved.

And if the bit is set, the auto-continue in the middle of the mission would be supported as well (which would make the land-amid-mission PR more feature-complete).

Other

Thank you 😉 Open for feedbacks!

[ThomasDebrunner]

I think this is the most sensible option for achieving the desired behaviour, while also keeping it backwards compatible

[auturgy]

I'm not opposed to this, however would point out that in ArduPilot this functionality is already achievable via mission items and appropriate parameter settings (see https://ardupilot.org/copter/docs/common-continue-mission.html).
Before merging, we need to confirm that the issue is not just a param/configuration problem, and that changing the mission command is a better / less disruptive change than potential alternative solutions (such as a configuration parameter in PX4).

[hamishwillee]

This video shows how to setup a mission in which a landing occurs, disarms, waits, re-arms and then re-takeoff and continue the mission.

@ThomasDebrunner @auturgy Note that ArduPilot may achieve the desired behaviour, but that is not demonstrated by the video.

The video shows disarming and then rearming and continuing. That to me is logical behaviour, but the PR here is to land WITHOUT disarming and then continue.

I asked in the meeting why disarming is "undesirable" and you all seemed to think this was a valid use case. I still don't see it, so perhaps someone could explain? It is dangerous to not disarm but it is never dangerous to disarm. At most it might cost you a little time.

Assuming this use case makes sense the other things I didn't fully understand.

• How is it going to be safe for someone to be near the vehicle.
• Can you use autocontinue for the trigger?

In summary

• If this can be done by ArduPilot, waiting on @auturgy for more info.
• If this use case makes sense, then I am not sure I see a better way than being explicit that this is what you want in the land command.

[ThomasDebrunner]

@hamishwillee The problem is not really arming / disarming, it is more about autocontinue after land
@auturgy The way I understand it is that there is a param in Ardupilot that controls if missions automatically continue on land? So that would solve the issue for PX4 as well in this case.

Except, in case you'd want a mission where some lands you want to automatically continue (e.g. package delivery) and on other lands you'd want to battery hot-swap (disarm, wait for operator to manually continue).
For this case, it would have to be specified by the land item.

I believe global params do not capture the complexity here and it is really about the specific mission. IMO, this needs to be either captured in the autocontinue flag, or with this param (as defined here).

[auturgy]

In ArduPilot you can turn off auto disarm in a parameter. You can then disarm/arm via mission items and continue mission if you want (or not disarm, add a delay, wait for a condition, run a lua script, etc, as you choose). Either way there’s an additional step in designing a multi stage mission: either managing the command enum or adding a mission item.

…

On 21 Jul 2022, at 6:41 pm, Thomas Debrunner ***@***.***> wrote:  @hamishwillee The problem is not really arming / disarming, it is more about autocontinue after land @auturgy The way I understand it is that there is a param in Ardupilot that controls if missions automatically continue on land? So that would solve the issue for PX4 as well in this case. Except, in case you'd want a mission where some lands you want to automatically continue (e.g. package delivery) and on other lands you'd want to battery hot-swap (disarm, wait for operator to manually continue). For this case, it would have to be specified by the land item. I believe global params do not capture the complexity here and it is really about the specific mission. IMO, this needs to be either captured in the autocontinue flag, or with this param (as defined here). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[hamishwillee]

@auturgy How (specifically) are you arming/disarming in a mission item? Are you using https://mavlink.io/en/messages/common.html#MAV_CMD_COMPONENT_ARM_DISARM ?
@ThomasDebrunner is this a viable option.

Yes, either way you need some method of choosing the delay.

I would have said that if autocontinue is not set the system should pause waiting for a manual instruction to continue. If it is set then the vehicle should continue to the next item as soon as it has "completed" the last one.
If the last item resulted in the vehicle being disarmed and the vehicle needs to be armed to do the next step then the behaviour is no different than starting a mission when the vehicle is not armed.

• So on an MC I would expect that the vehicle would arm and takeoff again.
• On an FW I would expect it to not be able to start unless the next item was a takeoff item - and that should auto-arm.
• Not sure about VTOL, but same theory follows.

What am I missing?

[hamishwillee]

What am I missing ...

Possibly the fact that, while not strictly specified, generally disarming resets a mission. We would perhaps need to be clear that disarming only resets a completed mission. We would probably need to provide a mechanism to manually reset a mission too - that has been requested before.

[hamishwillee]

@auturgy Were you able to get any more information about how how it is being disarmed? The video shows landing but not disarming.
Disarming/arming is what resets a mission (at least in PX4, and I thought also in ArduPilot) so I am not sure how this could work.

If there is no need to arm/disarm when landing then setting the vehicle to not disarm on land via a parameter should work (along with appropriate delays etc.).

If there is a need to disarm (and probably in general this is a good idea) then we would need to tell the flight stack not to reset the mission for this case. I am not sure how to specify that though.

The obvious way to do this is to say that the mission should not reset following arm/disarm while the mission is not complete (i.e. is running or paused and still has items).
In that case the vehicle can land, disarm and continue based on the remainder of the mission items - so you might need a disarm/arm item and a delay and a takeoff item to make it all work.

The trick is making sure that the mission will still reset on arm/disarm for other cases - say emergency land, or after a mission abort, or if it is still landed and disarmed when the mission reaches the last item (say if mission landed, disarmed, released gripper, and finished).

[hamishwillee]

PS The above thinking makes me dislike the PR more as it allows the "land and don't disarm case" but not the "land, disarm, rearm, takeoff case". The don't disarm is simply to avoid the mission resetting, so you might reasonably consider changing this to "land but don't reset mission on disarm".

[auturgy]

"Were you able to get any more information about how how it is being disarmed? The video shows landing but not disarming."
Disarm/arm is via DO_AUX_FUNCTION mission items, calling the "auxiliary function" for arm and disarm.
https://ardupilot.org/copter/docs/parameters.html#auto-options-auto-mode-options
https://ardupilot.org/copter/docs/parameters.html#mis-options-mission-options-bitmask
This scenario/combination is POSSIBLE but not EASY - opinions will vary, but it was a conscious decision. The defaults are all safe and easy. Changing the defaults to enable unattended re-arm / continue mission / not auto disarm etc - which are absolutely critical to some use cases, but undesirable and dangerous if used by the inexperienced - is a bit hidden.

[hamishwillee]

Thanks @auturgy

So @ThomasDebrunner it turns out ArduPilot do pretty much what I suggested would needed - the use a parameter to configure resetting the mission on disarm/arm and to continue the mission on land.

With that feature you can configure the mission however you like and it won't prematurely end.

I'm not sure I would do it exactly like ArduPilot did.

• I would use MAV_CMD_COMPONENT_ARM_DISARM for arming/disarming as it is in common.
• I think the continue after land should depend on the autocontinue flag in the land mission item
• We would need to configure not resetting the mission on arm/disarm, but I'd rather do that transparently based on the mission itself - i.e. if the mission goes on after disarm, then the auto-mission-reset should automatically turn off.

IMO this is better than the proposal in the PR, which does not address the preference to disarm, and ignores the autocontinue flag which is intended for this purpose.

Thoughts?

[junwoo091400]

After discussing with @MaEtUgR as well, it seems like there are following options and the pros/cons:

Using autocontinue

This was not clearly defined from the standard, and there is #1868 regarding this effort, but still we don't have a solid foundation.
Also, it raises the question : "Shouldn't the mission items continue execution anyways? Why do we even have this flag?"
Also, it would be hard for the operator to figure out why the vehicle disarms or not, without a proper documentation. And currently the QGC doesn't really set this flag correctly (defaults to true I believe).

Using parameter to set this behavior

Is this parameter really necessary? Do we really want to make it configurable when we can already achieve this by adding 'disarm' mission item in the plan?

New Suggestion: Don't change anything, but make documentation better

And he suggested (and I think it makes sense) that if an operator wants such hot-swap mission (land amid mission & disarm), it should be planned like : "Land -> Disarm -> Next Waypoint", with a "Disarm" mission item in the middle. Otherwise, we shouldn't expect the drone to disarm on it's own.

This would of course break the previous use-cases (which I am not sure if is still relevant) of having land mission item in the middle to deliver a package manually by the operator, but I think having a verbosely planned mission makes way more sense anyways 👍

So the action item would be to include this "Land amid Mission" related documentation. Any thoughts on this? @hamishwillee @auturgy

[hamishwillee]

It can't be fixed in the docs.

The problem is that a mission resets when the vehicle arms/disarms.
It doesn't matter if you disarm via a mission item or automatically: once you reset the mission it will stop. That's not something that MAVLink says or that you can fix in docs - it is what both PX4 and ArduPilot do by default.

So either you can't disarm on landing, which is dangerous, or you need to somehow tell the flight stack that disarming does not trigger a reset of the mission.
ArduPilot use a parameter to say "don't reset the mission". We could do the same, but as I said above, you might instead have rule that you don't reset the mission even on disarm if there are further items at the point disarming is triggered.
[but then you probably still want to trigger reset after the mission completes if you are landed].

Once you've solved that problem then you can construct a landing that lands, disarms, takes off again etc. There are mission items to delay for a set time on the ground while you unload, but if you want to have a user-defined wait time you need to either use autocontinue=false OR you need to make MAV_CMD_NAV_LOITER_UNLIM work on the ground.

Hope that all makes sense.

---

In response to the specifics

1. autocontinue is well defined but not well documented or commonly used. The only question in Mission item - document values for autocontinue #1868 is how the pause should be restarted and is more about SET_MISSION_CURRENT than autocontinue
   • it represents a open ended wait for user input, which is a useful thing. Consider I want to make sure I unloaded my cargo bay before the thing flies off.
   • If flying you can use MAV_CMD_NAV_LOITER_UNLIM instead. You could use this to wait when landed until the user says "time to go again" but I suspect it might not work right now on the ground - in particular because it would take off again to loiter height.

• IMO the autocontinue isn't needed for anything in the air, but it is the only way currently to indicate an endless pause on the ground.

2. Is this parameter really necessary? Do we really want to make it configurable when we can already achieve this by adding 'disarm' mission item in the plan?

   Disarm does not do what you need. You don't need to use a parameter, but you do need to manage how mission resetting takes place.

   Using a parameter is very explicit and might be the simplest way to isolate this use case. It is not to my taste though - I think if you define a mission that goes past landing then it should be evaluated by the flight stack for sanity and executed if it can be.

3. New Suggestion: Don't change anything, but make documentation better

   See above.

[hamishwillee]

• When this all resolves need to add a section in docs on the mission semantics and states. These broadly match on PX4 and ArduPilot, but is not documented. Stuff like auto-disarm and its impact on missions. What pausing means. Etc.

[hamishwillee]

@ThomasDebrunner As discussed in MAV call, the "core" thing to make this work is some mechanism to ensure that after landing a disarm does not reset the mission. With that in place, you can define a mission however you like with takeoff/land etc. Without it does not matter what you do as your mission will disarm and then end on PX4.

ArduPilot handles this case with a param "do not reset mission on arm/disarm when landed. Not clear how they then tell the system when it should reset. With an implementation we can now do that manually with MAV_CMD_DO_SET_MISSION_CURRENT but you might instead do something like "mission doesn't disarm when landed until after all mission items are complete".