the nav_roll_cd and nav_pitch_cd were not being set in the VTOL
takeoff code when disarmed. This led to small increments accumulating
in the stick mixing code, leading to large control surface movements
before arming
this fixes a bug where a change of home altitude would cause a sudden
height demand change. This copes with 3 situations:
- flying with AMSL alt demand. Changing home altitude makes for no change
- flying with AGL alt demand. Changing home altitude requires update of next_WP_loc
- flying with home relative alt demand. Changing home altitude changes demand at end of current navigation leg
in the case it wasn't compiled in the return code would be correct.
in the case that the parameter was invalid we would return FAILED, which is wrong, it should be DENIED
we have code which tries to handle commands coming in as command long as command int.
Change to rely on that code working, rather than handling both command-long and command-int variants
this fixes a bug where TECS maintains its slow integrator while in a
VTOL hover mode in AUTO or GUIDED.
Among other things this affects PAYLOAD_PLACE and
DO_VTOL_TRANSITION. In those states the height can change while
hovering outside the control of TECS. When TECS regains control in a
fwd transition then can lead to a very large height loss or gain until
the TECS integrator can catch up
this sets up the vwd integrator more reasonably when we are in
POSITION1 stage of VTOL landing. We need to have enough throttle to
cope with a headwind, but want it lower when we are at or above our
target closing speed so can minimise the amount of pitch up
This also makes the landing_desired_closing_velocity() consistent with
the landing speed used in approach, using average of airspeed min and
cruise speed if TECS_LAND_ARSPD is not set
The target airspeed for TECS during airbraking is now set to
ARSPD_FBW_MIN, on the basis we are trying to slow down to min speed,
and we have VTOL support which should prevent a stall.
To cope with a high headwind where ARSPD_FBW_MIN is below the headwind
we now check for too low achieved closing speed and switch to
POSITION1 which can use vfwd to get to the landing location
The code had a bug where if GPS fix was lost, the demanded airspeed would be set to the measured or estimated airspeed causing unpredictable variations in the demanded airspeed.
This patch prevents the minimum ground speed protection speed up from running if the ground speed undershoot cannot be calculated.
This patch extends the range of conditions over which the minimum ground speed functionality can be used by enabling the ground speed undershoot to be calculated when the navigation system is able to estimate velocity.
The check for the aircraft being lined up for a tangent exit has an early breakout condition if the next waypoint is too close to the loiter circle which can prevent the required ground course to waypoint ever being achieved. This check was using the WP_LOITER_RAD parameter value, not the actual radius being used which can be set differently by the mission plan. If a large value for WP_LOITER_RAD was set and being over-written by the mission plan with a smaller value compatible with the distance to the next waypoint, the aircraft would still exit early.
This is very useful with an aircraft that is expected to be autonomously
operating in auto from takeoff to landing. It is convient to have a GCS
connected or RC, but the loss of either isn't considered a reason to
terminate the mission.
this prevents a case where we can demand unlimited vectored yaw,
leading to loss of control
this was particularly noticible before the fix in #23023 - if you
armed for a 2nd time in QHOVER after moving the throttle above 10% so
throttle_wait was cleared then the motors would try to tilt fully so
one motor is in fwd flight position. This would cause a prop strike
while on the ground
