with the change to cache results inside AP::ahrs().state we no longer need to worry about the backend's attempts to project the last-known-location forwards according to amount of time elapsed since that last-known-location was calculated.
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
this copes with quadplanes with no compass. With a compass we are
better off using EKF when not in fly-forward as it will give better
height control.
This makes QHOVER for takeoff in quadplanes with no compass a lot more
flyable
we need to overwrite _omega with the filtered gyro value, so we get
both the low pass filter and the notch filters. Otherwise we will fly
with very high noise gyro data
this also fixes the accel_ef_blended to use the filtered accel. It is
not blended, and removing "_blended" from the API will be worthwhile
as a followup
We shouldn't be holding the data semaphore while waiting for the samples
- lots of things might be unnecessarily blocked
DCM's update function doesn't need to take the semaphore as it is
already taken by AP_AHRS
this adds the necessary functions to allow for flying a quadplane on
DCM as an emergency fallback. It sets the NavGainScalar to 0.5 to
reduce the VTOL controller gains to allow planes to cope with the
higher lag of DCM
with multiple airspeed sensors and airspeed affinity in EKF3,
it is possible to have switched over to a lane not using the
primary airspeed sensor, so AHRS should know which airspeed
sensor to use, i.e, the one being used by the primary lane.
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
