Feature: go-around patterns for missions

[almaaro]

Test data / coverage
Here is one flight with one go-around. In total, I have tested this feature at least over 10 times.
https://logs.px4.io/plot_app?log=4f523186-44dc-439f-8c31-2da5a1d66e86

Describe problem solved by the proposed pull request
To my understanding (please correct me if this is nonsense), the vehicle will always loiter above the landing waypoint after an aborted landing. So it is not possible to add regular waypoints after the LAND
point that the vehicle would follow automatically after the aborted landing.

Describe your preferred solution
If the landing is aborted and a valid waypoint exists after the LAND, just continue to the next item.

Edit. Some explanation of the code that might help (happens within Mission:on_active()):

• Mission::on_active() checks if MissionBlock::is_mission_item_reached() is true
• If true, and if autocontinue is true (seems to be for LAND), then advance_mission() and set_mission_items(). This sets the mission item to the next one.
• check if _mission_item.nav_cmd == NAV_CMD_LAND. It is not true, because the item changed (if the next item isn't also LAND (which would be weird)).
• Because the previous clause wasn't true, don't do do_abort_landing();
• FW position controller will reset the _land_abort flag.

[dagar]

This looks right, I just want to give it a more careful review as the navigator states are becoming more intertwined.

[Antiheavy]

Is this intended to be a VTOL only feature?

[almaaro]

No, the statement is for both NAV_CMD_LAND and NAV_CMD_VTOL_LAND cases.

[Antiheavy]

Does this change impact the various RTL_TYPE options? Specifically RTL_TYPE 1 and 2 where parts of the mission are used during Return Mode?

I'm wondering if there is a use case where some people would want this feature disabled? - I have to think about it some more. If this is the case, maybe the correct place to effectively "disable" this feature would be Mission Feasibility checker. Thoughts?

[almaaro]

I haven't considered if this will interfere with any return modes. A quick investigation showed that:

• landing to the current position seems to be OK (the next waypoint will be set as invalid in navigator/land.cpp).
• A quick look showed that if there is a valid landing point in the mission, it will just jump to NAV_CMD_DO_LAND_START. So no weird behaviour to be expected (navigator/rtl.cpp).
• In case of landing at the home position without a LAND wpt, it could possibly just continue the mission from the point where the RTL was issued if an aborted landing was to happen. I did't see that the next waypoint would have been set to invalid. So this is a problem (navigator/rtl.cpp).

Another thing comes to mind concerning the FW position controller: Maybe it would be better to disable landing aborts under some situations, such as the "low battery immediate landing". I don't know if it is already implemented though.

[Antiheavy]

Maybe it would be better to disable landing aborts under some situations, such as the "low battery immediate landing".

this is an interesting idea and maybe could be discussed in a separate issue post? I might suggest tying it to BAT_EMERGEN_THR with some logic for BAT_EMERGEN_THR where if already in a landing state, stay in the landing state and block the ability to abort?

[TSC21]

@almaaro please rebase. Thanks

[Antiheavy]

If this feature were to move forward, I think it should need to be enabled via parameter, e.g. MIS_DO_GO-AROUND or maybe MIS_ABORT_CONTINUE or something. Actually the term "go-around" doesn't accurately reflect the proposed feature - it is more of an "abort pattern" or "continue after abort" or something.

The current default behavior of aborting to loiter over the landing is generally pretty safe, consistent, and easily understood by the general user. If a user intentionally or accidentally adds waypoints after a Land waypoint, the system should still behave safely. I think a user should be required to enable the feature via a parameter so they have some understanding that the vehicle will go somewhere else (like maybe into some trees/buildings) after an abort.

[dagar]

Please reopen. See #11099 (comment)