if the user hasn't set TECS_LAND_ARSPD then we can use an airspeed
between ARSPD_FBW_MIN and TRIM_ARSPD_CM when on approach
this also fixes landing_desired_closing_velocity() to never go above
the landing target speed, so we don't try to speed up if we are
starting the landing sequence too early
ensure we are lined up, or we are at less than 0.5 of radius before we
switch to QRTL. This fixes the case where the stopping distance is
greater than the radius, prevening us from switching to QRTL while not
lined up with the landing point
allow for delayed takeoff, and takeoff at a particular time (for swarm
takeoff)
also check for takeoff command in landing sequence arming check
this allows for takeoff->land->disarm->delay->arm->takeoff->land
missions
when a user sets a passby distance we should calculate the turn point
based on the extrapolated distance, not the original waypoint
also simplify the passby logic using offset_bearing()
this is equivalent to copters WP_NAVALT_MIN parameter for takeoff. Not
implemented for land yet
this is useful for vehicles with significant GPS velocity noise on
takeoff, preventing dragging the landing gear
this fixes a case where we can get false positive on the landing
detector for quadplanes.
The issue happens if we cross the LAND_DESCEND to LAND_FINAL threshold
while pilot repositioning is active, with stale information in
landing_detect.lower_limit_start_ms as we don't run should_relax() in
LAND_DESCEND
when we arm in guided mode then enter a special guided_wait_takeoff
state. We keep motors suppressed until one of the following happens
1) disarm
2) guided takeoff command
3) change to AUTO with a takeoff waypoint as first nav waypoint
4) change to another mode
while in this state we don't go to throttle unlimited, and will refuse
a change to AUTO mode if the first waypoint is not a takeoff. If we
try to switch to RTL then we will instead use QLAND
This state is needed to cope with the takeoff sequence used by QGC on
common controllers such as the MX16, which do this on a "takeoff"
swipe:
- changes mode to GUIDED
- arms
- changes mode to AUTO
when RC_OPTIONS has been changed to not check throttle for arming then
treat this like a sprung throttle for quadplane throttle suppression
in auto-throttle modes, and only unsuppress when throttle goes above
trim+dz
this helps when the aircraft has gone into a landing sequence due to a
failsafe before it is armed. Arming while in the landing sequence is
very unlikely to be what the user wants
We decided to remove this after 4.2 was out in favour of
MAV_CMD_DO_SET_HOME which has been available since 2015.
The gcs-maintainers list was notified in Feburary.
AP_Logger.h is a nexus of includes; while this is being improved over
time, there's no reason for the library headers to include AP_Logger.h
as the logger itself is access by singleton and the structures are in
LogStructure.h
This necessitated moving The PID_Info structure out of AP_Logger's
namespace. This cleans up a pretty nasty bit - that structure is
definitely not simply used for logging, but also used to pass pid
information around to controllers!
There are a lot of patches in here because AP_Logger.h, acting as a
nexus, was providing transitive header file inclusion in many (some
unlikely!) places.
when rudder disarm is disabled we should allow full yaw control
regardless of throttle level. We should also only disable left yaw
when throttle is at zero, as right yaw does not indicate pilot may be
trying to disarm
when a quadplane touches down in an auto throttle mode the pilot may
use rudder to disarm. The check for rudder disarm was only active in
modes without auto-throttle. This expands it to all modes if the
throttle has hit the lower limit
So instead of updating plane.guided_WP_loc and then calling
set_guided_WP(void) to copy that state into plane.next_WP_loc we pass
the new location in the call to set_guided_WP(const Location &loc).
avoidance was the only place which was not entirely over-writing
plane.guided_WP_loc. However, plane.next_WP_loc was updated to be the
current location when we entered guided mode. If we update the
horizontal/vertical avoidance now it is relative to the current
location, not the guided wp location, which could be quite important.
