wp_start provides next_dest_loc
send next_destination to wp_nav instead of setting fast_waypoint
fixup zigzag for S-curve changes
fixup guided
auto spline fixes
smart rtl rename of next_point to dest_NED
loc_from_cmd accepts default location
auto mode stops before starting land command
auto do_next_wp accepts default location
rename do_next_wp to set_next_wp
also rename get_spline_from_cmd argument
also improve failure to set next waypoint due to missing terrain data
also fixup comment in set_next_wp
also auto stops when moving from straight to spline segments
also auto mode spline fix
also auto mode calls AC_WPNav::set_spline_destination_next
Copter: AutoYaw provides rate from WPNav
- This should improve pointing at ROI and replaces #11172
- Remove unused member variable as per review suggestion
- declare Mode::AutoYaw::roi_yaw() as const
There is a race with the cleanup thread. While thin, it only has to
happen once. After this patch the race would have to happen... a lot.
Co-authored-by: jasclarke308 <jasclarke308@gmail.com>
This allows you to arm the copter without any extra GCS commands while
in auto, and can be done from both the GCS, or the RC Tx. This is useful
for creating a simpler workflow.
This also allows you to set the auto_armed flag internally, which
bypasses the need to raise the throttle stick for the copter to start a
takeoff.
This exposed a problem where we would start running the controllers
before the EKF was at all initialized, if you switched into auto to
early. This now has a check that prevents us from running the mission
state machine until after the origin has been set. This was a suggestion
from @rmackay9.
When combined these options allow you to have the vehicle on the ground,
disarmed in auto with a takeoff waypoint loaded, then just arm the
aircraft and watch it takeoff. This is a feature we've had on quadplanes
for quite awhile now, and it has proven to be very nice for operators.
In the case that you:
- have previously done a successful SmartRTL flight
- get a mid-air gcs failsafe and enter SmartRTL
- recover from that gcs failsafe but remain in SmartRTL
- get another mid-air failsafe
then without this patch you will enter LAND mode.
When determining our failsafe action, we were looking at whether we
should just continue landing. To do that, we ask the current mode if we
are landing. Problem is that SmartRTL was handing back the wrong answer
- it was handing back ModeRTL's answer rather than its own, and
ModeRTL's answer was "yes, I'm landing", as that's the last state that
step 1 in the above list leaves that mode in.
This patch simply hands back the correct answer for, "am I landing"
