[wip] landdetector mc: widen acceptance threshold after landing

[Stifael]

Related to the issue here: #7768.

Instead of widen acceptance threshold right after arming, the threshold has been widened right after landed was detected.

@sanderux, can you please retest?

[sanderux]

Looks good, i will test this soon.
The issue that remains unresolved is the strange behavior if an initial landing detected does not persist. This worries me a little as this is a possible scenario on a vtol.

@dagar do you have any idea what could be causing the strange system behavior?

• uorb topics no longer publishing
• mag timeout
• gps fix loss

From previous experience the LPWORK process spiked to 35% cpu related to the land detector and exhibited the same behavior.

[sanderux]

Tested, works: https://logs.px4.io/plot_app?log=bd8740e0-f43b-418b-8f10-f27f50e9f989

[sanderux]

@Stifael can you rebase for a new CI check?
If you are content i think we can get this in.

[AndreasAntener]

@Stifael why would you remove the less strict detection on arming?

[Stifael]

@AndreasAntener, I assume you ask because you encountered a problem?
Why is it necessary to increase the threshold (= make it easier to detect landed) right after arming for vertical movement and rotation? Does your vehicle move/rotate when you arm?

[AndreasAntener]

The prop spin up. You even left the comment in the code:

// so that motor spool-up and other effects do not trigger false negatives.

Extreme example is our octocopter with 24in folding props. But any vehicle can be affected by this. Some of our larger VTOLs create quite some airflow under the wing while arming which moves it around quite a bit.

[Stifael]

@AndreasAntener, I was more interested in knowing if there was a problem with this change?
I did this PR because of vtol, where the large minimum thrust caused issue. The increase in threshold after landing could have been done independent of reverting the arming, but despite the description I did not understand what

spool-up and other effect do not trigger false negatives

exactly means. That said, I called it WIP because I did not test it myself and because I was not sure if this change will cause issues and if it does, make the threshold increase for landing independent. Therefore, I assume you encountered a problem with your vehicles?

Can you list the sequence of execution that you expect to happen with the increase in threshold right after arming?

Here is the sequence how I understand it:

1. we are disarmed -> always landed
2. we arm -> as long as vehicle is not moving the vehicle stays in landed state, where the props rotate in idle. This is because the position controller set thrust to 0 when landed.

The threshold increase after arming only effects vertical movement here and rotation here. This has nothing to do with the thrust threshold. In addition, the threshold for movement are already quite large (for vertical movement the threshold is at 0.5m/s). Consequently, as long as the vehicle does not move during arming, there should not be any change (that is at least what I concluded from the code). So please correct me if I missed something.

[Stifael]

@AndreasAntener did you have a chance to test it with one of your vehicles? If yes and things worked well, I will do a pr that changes the description to finalize this pr.

[AndreasAntener]

Sorry for not getting back to you earlier.. I understand the change you did for the landing case and I'm not arguing about that.

I agree, vertical movement is unlikely to trigger, but the rotation is. I'm not saying we need support for drones with completely unstable landing gear. But the props during spin-up can easily disturb a large vehicle enough so that the rotation threshold is crossed. Once the props are idling properly, the vehicle comes to a rest. At least that is the assumption I'm going with here. It might be wrong.

What I was getting at is that functionality was removed which has been added for a reason, and we should first prove that the reason for adding it was invalid. Which is why it should be re-added IMHO. It will actually be impossible to prove that it's not needed ;)