Navigator: Failsafe: Add descend mode as a failsafe.

[AlexisTM]

The land mode supposes we have a GPS causing issues when flying with a local position (such as mocap or vision)
This adds the alternative to use the descend mode.

Solved Problem

When working on local position systems such as a vision localization, the land mode doesn't fit the need when the localization is failing as we want a way to land safely. The only alternative is terminate.

Furthermore, the current Land mode supposes the use of GPS which is not present using vision/flow/mocap, making the drone try to land at (0,0) with a heading of 0°, which is not the expectation.

Fixes #23773
Fixes #21524
Fixed by #23845

Solution

• Add the use of Descend mode for all failsafe actions

Changelog Entry

For release notes:

Feature: Failsafe modes now include the descend mode

Testing

Tested in simulation

Alternatives

Crashlanding with terminate

[sfuhrer]

I think #23580 already fixes your issue. There I changed the state machine logic such that "Land" failsafe action is always triggered, even if the mode requirements for "Land" are not met. It then instantly falls-back to Descend.

[AlexisTM]

Unlike the bug you fixed where you couldn't enter land mode, we actually enter but want the Descent behavior instead.

There are two other problems we encounter:

• The land mode succeeds as we do have a proper local position, but it tries to go to (0,0) instead of landing in position. That is likely a bug.
• Even when the land mode works properly, and we have a valid local position, that local position could be unstable due to vision input, especially when developing said vision software. So we do not want to rely on the position at all for the emergencies.

[sfuhrer]

we actually enter but want the Descent behavior instead.

Descent mode is intended to be a fall-back mode only, not intended to be a mode that a user can actively switch into. With this PR you would change that, so let's make sure that we really need it before rushing it in.

The land mode succeeds as we do have a proper local position, but it tries to go to (0,0) instead of landing in position. That is likely a bug.

That definitely sounds like a bug. I think I was able to reproduce it by triggering RC loss failsafe to Land with gazebo classic iris_opt_flow. Let's focus on fixing that. Could you look into it?

Even when the land mode works properly, and we have a valid local position, that local position could be unstable due to vision input, especially when developing said vision software. So we do not want to rely on the position at all for the emergencies.

But unstable local position estimation poses a big safety hazard not only in the failsafe modes but also in normal modes such as Position and Hold, no? Shouldn't we focus on improving the rejection on bad position estimates? If we have a reliable way of detecting bad position/velocity estimates we can leave the failsafe actions at Land, and only fall back to Descend in emergencies.

[AlexisTM]

I will try to reproduce it in simulation.

I agree an unstable local position is a very bad problem that has to be fixed, but it is sadly a fact we have to work with during the development for vision systems.

Descent mode is intended to be a fall-back mode only, not intended to be a mode that a user can actively switch into. With this PR you would change that, so let's make sure that we really need it before rushing it in.

Those are the failsafe and not an actively switched to task. In any case where we work on the localization system, this is way safer than the Land mode.

[AlexisTM]

@sfuhrer It is reproducible in simulation. I do not have Gazebo classic, but managed it with Gazebo with minor fixes. (the gazebo models default parameters are not yet valid)

https://review.px4.io/plot_app?log=af6f8332-e2ee-4dd1-91cb-f5cd1ba02099

Reproduce with make px4_sitl gz_x500_vision

• Change the parameters (with QGC, as the defaults not valid in the model)

NAV_RCL_ACT Land Mode
SENS_EN_SIMGPS 0
EKF2_EV_DELAY 5
EKF2_EV_CTRL 15 (select all)
EKF2_HGT_REF 3 (select vision)
EKF2_GPS_CTRL 0 

• Restart simulation
• Takeoff with QGC
• Move away from (0,0) with the virtual joysticks
• Quit QGC to trigger landing

[sfuhrer]

@AlexisTM can you check out #23845?

[AlexisTM]

@AlexisTM can you check out #23845?

This solves the land mode with a proper local position but no global position.

Is there a reason for which we wouldn't want the descend mode in the failsafe?

[sfuhrer]

Is there a reason for which we wouldn't want the descend mode in the failsafe?

We don't like adding features to mainline PX4 that are only in extreme corner cases. Plus as I mentioned above, "Descend" is not intended to be a flight mode that the user can actively switch into, it's only meant to go to this mode as a fall-back if "Land" is not available.

I agree an unstable local position is a very bad problem that has to be fixed, but it is sadly a fact we have to work with during the development for vision systems.

But during development you certainly have also manual control capabilities no? Or what do you do when you test an auto mode and the Navigation gets unstable? You switch to a manual mode no?
I would focus on making the detection of "bad local position estimation" more reliable. If local position is declared invalid while in "Land", the system already automatically switches to Descend. Do you have a specific log file where the local position wasn't estimated accurately enough to land in Land mode, but was not declared invalid?

[AlexisTM]

The current way has been to use the manual mode. Yet, people working on the computer vision part are not pilots. As this is flying indoor, there is a very small margin of error to recover the drone.
I do not have a log for a failure to detect invalidity in the data from the land mode as the land mode was unusable indoor until your last PR.

We will keep this local for our fork for now.