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.
remove any discrepancy which has crept in over the last few seconds
this also ensures that relative_altitude is updated, and copes with
the EKF refusing the resetHeightDatum call
clang reports this could be a problem when compiling under some EABIs. Remove it from most places as it is just noise, replace with class where we want to avoid including Location.h
Brings us in-line with other classes in ArduPilot.
Removes ambiguity with AP_HAL::OpticalFlow which can cause compilation errors as we start to make code more portable across targets
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
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.