With this change we will continue to tell the user their interlock is
enabled, but we will not fail the pre-arm checks.
This will mean that the blinking-LED indicators will show the vehicle as
armable (flashing green / flashing blue), even if the interlock would
prevent arming.
This has the advantage that you don't need your vehicle in the
"dangerous" state to work out whether arming will work when you attempt
to arm it.
Note that we repeat the interlock switch check in the arming checks, and
it WILL fail if the interlock switch is enabled.
If a the mount instances (gimbal) does not support yaw/pan control, the
copter needs to yaw in response to a DO_MOUNT_CONTROL command in
missions. Checking if the mount has pan control, and if not, yawing the
copter was missing from the mission commands logic. As such, a
MOUNT_CONTROL command would control pitch but not yaw/pan. This patch
impliments checking for pan control, and initiating copter yaw as
required.
If the mount instance does not support yaw/pan, the copter needs to yaw in
response to MSG_MOUNT_CONTROL and MAV_COMMAND_DO_MOUNT_CONTROL commands from
a GCS or co-computer. There was no checking for mount pan in the GCS_Mavlink
logic. As such, no yaw takes place when a mount control command calls for it.
This patch impliments copter yaw control for both MSG_MOUNT_CONTROL and
MAV_COMMAND_DO_MOUNT_CONTROL in copter GCS_Mavlink.
See discussion here:
https://github.com/ArduPilot/ardupilot/issues/7331
we were getting some uninitialised variables. While it only showed up in
AP_SbusOut, it means we can't be sure it won't happen on other objects,
so safest to remove the approach
Thanks to assistance from Lucas, Peter and Francisco
init() may have changed all sorts of things about the
vehicle - wp navigation, position controllers, attitude controllers...
Do the heli check before doing any of that so we don't change state and
then fail to change mode
Calling update_simple_mode_bearing calls get-heading
rather than the other way around
This will have the advantage of not calculating home bearing
when we stop calling update_simple_mode_bearing unnecesarily
Move responsibility for calculating wp bearing/distance
into the FlightMode object doing the navigation
Calculating these variables was being done at 50Hz where they
were used at 10Hz max.
This moves static variables into the autotune flightmode object.
It also adjusts namespacing on everything to take advantage of
having everything encapsulated in the AutoTune object
Peter Barker
Matt
Randy Mackay
Andrew Tridgell
khancyr