mirror of
https://github.com/ArduPilot/ardupilot.git
synced 2026-10-06 19:00:27 +08:00
Peter BarkerandClaude Fable 5
3d96c165f4
height_above_terrain() falls back to last_current_loc_height when there is no terrain data at the current location and the caller asked for extrapolation. It never checked have_current_loc_height, so before any terrain data has arrived it extrapolated from a value which has never been set - zero - and returned the vehicle's full AMSL altitude as its height above terrain. At CMAC that is 584m of clearance reported for a vehicle sitting on the runway. The other two users of last_current_loc_height, height_terrain_difference_home() and send_terrain_report(), both guard on have_current_loc_height already. Twenty call sites ask for extrapolation and cannot tell the fabricated value from a real one; eleven of them are in ArduPlane, eight in altitude.cpp alone, where the result is used as height above ground for terrain following. Two consumers demonstrate it: - Copter feeds it to RangeFinder::set_estimated_terrain_height(), so a rangefinder with RNGFNDx_PWRRNG set powers itself down on the ground and blocks arming with "PreArm: Rangefinder 1: Powered Down"; - UTM_GLOBAL_POSITION sets RELATIVE_ALTITUDE_AVAILABLE from the return value, so the vehicle advertises a height above ground it does not have. Both are reproducible on a serial run by emptying the vehicle's terrain cache first, and both appear consistently under --parallel, where each worker starts with an empty cache. Note that both of those tests assert the old behaviour and need their own fixes to pass with this applied: they are unrelated to each other and are in separate PRs, and this commit should not land before them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>