when on landing approach we estimate time to flare based on two noisy
numbers, the vertical speed and height above ground. With noisy
rangefinders this can change rapidly, which resulted in the pitch
limit changing rapidly, leading to a porpoising movement
this limits the rate of change, and also prevents it coming down once
it has nosed up due to pending flare on approach
The calculation of the non-limited airspeed rate demand used the last
non-limited airspeed, whereas it should have used the last adjusted
value. This led to a single frame spike in airspeed demand, which fed
through to a sudden change in pitch integrator.
a short term spike in the derivative of speed demand could cause the
constraint on the pitch integrator to push the pitch integrator to
very low values, causing a sharp nose down which takes a long time to
recover from
See discussion here:
https://github.com/ArduPilot/ardupilot/issues/7331
we were getting some uninitialised variables. While it only showed up in
AP_SbusOut, it means we can't be sure it won't happen on other objects,
so safest to remove the approach
Thanks to assistance from Lucas, Peter and Francisco
this will reduce confusion when searching for FLIGHT_LAND_* and you get a bunch of takeoff related hits. It will also make more sense when the landing library fully manages the FLIGHT_LAND stage entirely because it will not mange FLIGHT_LAND_ABORT
This should fix CID 91386.
Before removing the 'if', I checked the log to confirm that both branch
didn't end-up being equal by mistake in some commit. But it looks like
the file was added in the project this way.
during the first part of a takeoff when we have not yet reached the
target airspeed this forces the throttle to maximum. This fixes a case
where the throttle may drop too low during the first part of takeoff
and lead to a stall.