this fixes a bug where if the terrain database cache does not have the
tile for the location of a rally point then RTL to the rally point
with TERRAIN_FOLLOW=1 will not track terrain
The underlying issue is that Location::loc.change_alt_frame() will
return false if the location is not in the terrain memory cache. We
can't just extrapolate as the rally point could be in a totally
different terrain area to the current location. So instead we set it
as terrain_following_pending and fix it as soon as the terrain cache
is filled.
fixes https://github.com/ArduPilot/ardupilot/issues/25157
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.
Andrew Tridgell
Paul Riseborough
Tom Pittenger
Iampete1
Peter Barker
Henry Wurzburg
khanasif786
yaapu
Joshua Henderson