The Flare Trap: Why ArduPlane 4.7 (Beta) is a "No-Fly" for Autoland

The mantra of autonomous flight is simple: trust the code. We build our stacks, tune our PIDs, and eventually, we let the software take the controls for that final, critical tenth of a second—the flare.

But right now, for anyone testing the ArduPlane 4.7 Beta with a rangefinder, that trust is a liability.

The Regression: A Race to the Ground

There is a confirmed, critical regression currently tracked in GitHub Issue #31011. When a fixed-wing airframe equipped with a rangefinder attempts an autonomous landing on the 4.7 Beta branch, the transition from the glide slope to the flare creates a logic conflict between the EKF3 and the TECS controller.

Instead of a smooth rotation to bleed off energy and settle onto the runway, the system can demand an "infinitely negative" sink rate. In plain English: the plane decides the ground is actually several meters lower than it is and commands a "lawn dart" maneuver into the numbers.

Under the Hood: Where the Logic Breaks

The failure happens within the AP_TECS library—the part of the ArduPilot code responsible for managing the plane's energy by balancing throttle and pitch.

In the 4.7 Beta, a logic disconnect occurs during the "Flare" stage. The Total Energy Control System (TECS) calculates a Sink Rate Demand based on how far the plane is from its target glide path.

float flare_sink_rate = target_sink_rate + (hgt_error * flare_gain);

sink_rate_dem = constrain_float(flare_sink_rate, 0.0f, maximum_sink_rate);

The "Step" Error

The problem is the hgt_error (height error). When the plane is high up, it relies on Barometric or GPS altitude. But as it nears the ground, the Rangefinder takes over.

If the Rangefinder suddenly reports that the ground is 1 meter closer than the Baro estimated, the code perceives this as a massive, instantaneous hgt_error. Because the flare_gain in 4.7 is currently too aggressive or improperly dampened, the TECS reacts by commanding a massive increase in sink rate to "correct" the height.

Instead of a gentle rotation, the plane pitches down to meet the ground at the speed the math demands—which, in this case, is a crash.

The EKF3 Disconnect

Additionally, the EKF3 (the filter that merges all sensor data) in 4.7 Beta can sometimes struggle to "fuse" the rangefinder data quickly enough during the high-stress transition to flare. If the EKF's vertical position estimate and the raw Rangefinder data disagree, the sink_rate_dem oscillates, leading to the erratic behavior reported in Issue #31011.

Why Baro Autoland Isn't the Answer

The common suggestion for those stuck on 4.7 is to disable the rangefinder and rely on barometric altitude. This is potentially problematic: Standard atmospheric pressure can shift by 1 mbar in a matter of minutes—that’s a drift of roughly 8 meters (26 feet). If the pressure drops while you’re in the air, your "zero" altitude might be 30 feet underground by the time you return. Combine this with the high-pressure "ground effect" bubble that messes with static ports during the flare, and you’re flying blind at the most dangerous moment of the flight.

The Good Practice: Always save your .param!

If you’ve updated to the 4.7 Beta and—like myself—didn’t version-control your 4.6.3 .param files before the jump, you are effectively a hostage to the next merge.

We are tracking the ArduPlane master branch and hoping for the fix to be backported to a stable 4.7 release candidate. Until then, if your fixed wing is equipped with a rangefinder, be careful on the flare phase of the Autoland or keep the plane on the bench. The weather here in Ireland is horrible anyway; there’s no sense in adding a crashed airframe to your collection.

Colophon

This report was compiled while monitoring the ArduPilot master branch. I have immense respect for Tridge, Paul, and the Ardupilot dev team—this is why projects like Ardupilot have Beta cycles. Stay safe, and always backup your parameters.