MC Land Detector: try to make simpler to tune and less likely to detect early takeoffs, plus improve logging

[sfuhrer]

Describe problem solved by this pull request

1. vertical speed threshold for land detection very low, plus complex to tune. The threshold is currently:
   min(0.9 * max (MPC_LAND_CRWL, 0.1) * 0.5, LNDMC_Z_VEL_MAX), which with the default values is 0.9x0.5x0.3m/s = 0.135m/s, so about 4 times lower than LNDMC_Z_VEL_MAX and means that LNDMC_Z_VEL_MAX` is not at all considered (breaking the documentation of the land detector .
   

2. rotational movement (that is checked for land detection) not logged

3. pre-emptive "takeoff" detection during auto takeoff due to motor spool up triggering rotational movement to be above threshold
   

Describe your solution

1. MC LandDetector: remove dependency on MPC_LAND_SPEED and MPC_LAND_CRWL
   Don't consider these params for vertical speed threshold, and instead increase the default for LNDMC_Z_VEL_MAX and use solely that one. Makes the land detector outcome more predictable and its internal logic simpler, while the new default tuning is increasing the vz threshold from 0.135m/s to 0.25m/s.
   For setting the in_descend flag I added a constant (0.3m/s) instead of using the crawl speed for that.

2. add a rotational_movement to land_detector_status message.

3. Increase threshold for rotational and vertical movement not only during the first 2s after a landing, but always if maybe_landed is true (so during takeoff as well as after a landing was detected. That makes it harder to trigger a "not maybe landed" due to rotational or vertical movement during propeller spool up, as well as it keeps it consistent after landing, not just in the first 2s. Also makes the land detector logic a bit simpler and more predictable by removing this extra internal state.

Describe possible alternatives

• Instead of 7b6e2d4 we could just keep d687fcb (this keeps the 2s window after takeoff for higher thresholds, but I don't think it's needed).

Test data / coverage

Minimal SITL testing.

Additional context

It used to be that the threshold widening was done after arming instead of after landing, but this was changed in #7772. Don't fully understand why.
The vz threshold was changed (linked to crawl speed) in #19126, it used to be considerably higher before as not the crawl speed but the land speed setpoint was taken into account.

In SITL I sometimes see a thrust spike during an auto takeoff just before the thrust ramp start. This then triggers a pre-emtptive takeoff detection, but I didn't get to the root cause yet. Not sure if reproducible on real vehicles.

[MaEtUgR]

@sfuhrer I rebased on latest main (#20428) and added my suggestions. I'm not 100% sure there's no corner case and the thresholds are far enough apart with different configurations but that's a base we could test to have improvement before doing further simplification and improvement steps.

I'm happy to discuss and revise my suggestions in case they miss the point of your pr.

The hard part is currently to cover slow landings without negative side effects. One thing I noticed is that without my commits the default crawl speed is 0.3m/s and the hardcoded threshold for in descend is 0.3m/s and since with a distance sensor the speed is never above the threshold it would never consider being in a descent. This is less harmful than if the land detection threshold would be raised above the hardcoded DESCENT_TRAJECTORY_VZ_THRESHOLD because then normal slow downwards velocity tracking would be recognized as false positive we want to go down but are not moving hence we must be on the ground.

[MaEtUgR]

I rebased this on main. Working on it.

[MaEtUgR]

@sfuhrer First of all thanks a lot for looking into this, saved me quite some time that you already made these useful suggestions!

In my eyes, this pr solves the issues you described and I've also seen multiple times before on other platforms. You did testing and it didn't break without serious misconfiguration and I did tests without any issues. So I suggest we merge this and follow up with further improvements. I have a draft to simplify the maybe landed logic and hence also solve the rotational movement not updating because of early returns but it needs separate testing and I suggest using a separate pr instead of just delaying this one.