Fix/AS-1603: Land detector overrides a stuck rangefinder after 15 s

[NicolasMichelMatternet]

Summary

A downward rangefinder can report a healthy-but-false distance while the vehicle is on the ground. In NCT-3495 the radar (RNGFND1) reported a steady 6.55 m with status Good for 400+ s after touchdown while the lidar read 0.19 m (below its 20 cm minimum, so OutOfRangeLow and excluded from the vote). The land detector refuses to declare a landing while the only healthy downward rangefinder reads ≥ 2 m, so land_complete never set and every disarm path — automatic and commanded — stayed blocked for 522 s. The same signature appears in NCT-3311 (976 s), NCT-2885 (128 s) and NCT-2781 (471 s).

This adds a secondary path to the land detector: if the throttle, acceleration and descent-rate criteria have all held continuously for LAND_DETECTOR_RNGFND_TIMEOUT_SEC (15 s, reduced from the initial 30 s proposal) while only the rangefinder check fails, a warning is sent and the landing is declared anyway. The primary path (0.5 s trigger, APM_Config.h) and all downstream disarm behaviour are unchanged — the override only sets land_complete; disarm then follows the mode's normal path (ModeLand, ModeAuto::verify_land()).

Note on the 15 s value: this is a proposed value and may be adjusted based on feedback. It is currently a compile-time define (config.h, following the other LAND_DETECTOR_* defines); it could be made a parameter if runtime tuning is preferred.

Change

• ArduCopter/config.h — new LAND_DETECTOR_RNGFND_TIMEOUT_SEC 30.0f.
• ArduCopter/land_detector.cpp — the existing check is factored as inertial_landed = motor_at_lower_limit && accel_stationary && descent_rate_low; the primary path (inertial_landed && rangefinder_check) is untouched. A second counter accumulates while inertial_landed holds regardless of the rangefinder and, on reaching the timeout, sends Land detect: rangefinder overridden (WARNING) and calls set_land_complete(true). Both counters reset in set_land_complete() and in standby.

Design notes:

• The timeout counter does not reset when the rangefinder check briefly passes, so a flickering sensor (as seen in the NCT-3495 log after the Hold) cannot extend the lockout; a normal landing still completes via the primary path at 0.5 s.
• BRAKE/Hold on the ground is still not covered (the throttle-mix-min condition is never met when no descent is demanded) — same limitation as today.
• The WARNING statustext is below INFO severity, so MATE forwards it to the MDL as an operator message; it does not match any of MATE's statustext prefix parsers.
• In-flight false-positive risk: 15 s of throttle-at-lower-limit + mix-min + |vz| < 1 m/s + accel < 1 m/s² while airborne is physically implausible for a multirotor. The realistic non-ground case is being perched on an obstacle, where this disarms after 15 s (stock ArduPilot without a rangefinder would do so after 0.5 s).
• Stock ArduCopter 4.7.0 has the same rangefinder veto as before this change, and would fail the same way; its intended fallback is operator force-disarm (param2 = 21196), which MATE/MDL do not currently issue.

Verification (SITL)

MAVLink rangefinder (RNGFND1_TYPE=10; these runs were made with the original 30 s value — the override timing scales directly with the define) fed by a script that reports true altitude in flight, then a stuck 650 cm Good reading on final approach (the NCT-3495 scenario). Times are from throttle reaching minimum on the ground:

Case	LAND_COMPLETE	Disarm
Unpatched (mttr-rebase-4.0), stuck rangefinder	never (still armed at +90 s)	never
Patched, stuck rangefinder	+30.2 s, with Land detect: rangefinder overridden	+30.7 s
Patched, normal landing	+0.6 s (unchanged)	+1.1 s

This is the before/after figure for these three runs. Applied to the historical logs, the inertial criteria held continuously from touchdown in all four events, so the override would have fired at +15 s in each (vs 128–976 s armed on the ground).

Tickets: https://matternet.atlassian.net/browse/AS-1603 · https://matternet.atlassian.net/browse/NCT-3495 (also NCT-3311, NCT-2885, NCT-2781)

🤖 Generated with Claude Code

[adriennet823]

Logic looks good to me; code still reflects 30s value. Confirmed offline we will go with 15s, but please let me know if you get feedback from others on this and if anything changes.

[NicolasMichelMatternet]

Logic looks good to me; code still reflects 30s value. Confirmed offline we will go with 15s, but please let me know if you get feedback from others on this and if anything changes.

Confirmed; I've pushed the change.