this adds parameters that can be setup by an external script for
compensating for temperature variation in gyros and accels using a 3rd
order polynomial
use regulated time for frequency noise to avoid spurious harmonics
SITL sensors must be true separate instances
don't compile in FFT structures if DSP disabled
FFT windows can be dynamically allocated
add harmonic notch dynamic tracking mode
unwind gyro window allocation in the case of failure
allow access to harmonic notch harmonics
this we ensures we get new data for all active IMUs on each loop,
rather than sometimes returning with some IMUs not having data.
This matters as not having a sample on an IMU for a single loop can
cause an EKF IMU failover, which will degrade the learned bias
variances
The issue is usually only seen under high load, such as requesting a
loop rate beyond what the hardware is capable of
https://github.com/ArduPilot/ardupilot/issues/11346
Allocate a notch filter per-IMU.
Update the notch filters in the backend at the sensor sample rate.
Allow raw logging of post-filtered gyro and accel values.
AP_InertialSensor: add parameters for push-to-log interval and count
AP_InertialSensor: rename BAT_RAW to BAT_OPT
This becomes a bitmask of options for the BatchSampler
AP_InertialSensor: rename 'fast sample' to 'sensorrate sample'
AP_InertialSensor: const sensor-rate filter method
AP_InertialSampler: remove hard-coding of sample rate multiplier
AP_InertialSensor: use parameter to enable/disable sensor-rate logging
AP_InertialSensor: use a parameter to control sensor-rate logging
AP_InertialSensor: allow backends to override sensor data multiplier
e.g. some accelerometers are sensitive over wider ranges than the default 16G
AP_Inertialsensor: correct sample rate multiplier
this allows for only a specified subset of IMUs to be probed, so you
can disable IMUs that aren't needed.
The back corresponds to bits in the order the IMUs are normally probed
on the board
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
Andrew Tridgell
Peter Barker
Michael du Breuil
Andy Piper
Siddharth Purohit
Tom Pittenger
Jacob Walser