The DCM drift correction code uses the current attitude to calculate
error values to update its gyro drift correction. If we were using EKF
then without this patch the DCM code running as an alternative AHRS
source would be using the EKF attitude for calculating the error
value, leading to very bad gyro drift estimation
use_compass() and reset() are common to AP_AHRS_DCM and
AP_AHRS_NavEKF. As AP_AHRS_NavEKF is a child of AP_AHRS_DCM, when we
call use_compass() from within AP_AHRS_DCM we actually end up calling
AP_AHRS_NavEKF::use_compass().
This has the effect of disabling the compass in DCM when EKF is active
and EKF has decided not to use the compass. That means that the DCM
yaw (and in fact the whole attitude) can get badly off while EKF is
enabled, making DCM an ineffective fallback if EKF fails.
The fix is to call the specific class versions of use_compass() and
reset()
this prevents a floating point error caused by using an uninitialised
vector3 when switching between DCM and EKF control in AP_InertialNav
Pair-Programmed-With: Randy Mackay <rmackay9@yahoo.com>
limit.throttle_lower flag becomes true when the throttle passed into the
motors lib (which is in the 0 ~ 1000 range) is below _min throttle.
This makes the interpretation of the THR_MIN parameter consistent
between the main code (which uses 0 ~ 1000 range) and the motors lib
(which previously used the RC3_MIN ~ RC3_MAX range).
The remaining problem however is that the output of the motors continues
to use THR_MIN as if it were a pwm. I don't believe this is a dangerous
problem however.
The GPS glitch offset was being zeroed during position resets. This caused the filter to reject subsequent GPS measurements if the GPS error persisted long enough to invoke a timeout and a position reset.
This shifts the origin to the vehicle's current position and should be
called just before take-off to ensure there are no sudden roll or pitch
moves on takeoff.
The uncertainty in acceleration is currently only scaled using horizontal accelerations, however during vertical plane aerobatics and high g pullups, misalignment in angles can cause significant horizontal acceleration error.
The scaling now uses the 3D acceleration vector length to better work during vertical plane high g maneouvres.
This error was found during flight testing with 8g pullups
If the inertial solution velocity or position needs to be reset to the GPS or baro, the stored state history for the corresponding states should also be reset.
Otherwise the next GPS or baro measurement will be compared to an invalid previous state and will be rejected. This is particularly a problem if IMU saturation or timeout has occurred because the previous states could be out by a large amount
The position state should be reset to a GPS position corrected for velocity and measurement latency. This will make a noticeable difference for high speed flight vehicles, eg 11m at 50m/s.
GPS measurement variance is doubled if only 5 satellites, and quadrupled if 4 or less.
The GPS glitch rejection thresholds remain the same
This will reduce the impact of GPS glitches on attitude.
Flying aerobatics with Trad Heli has shown that the divergence check can be false triggered when large magnetometer errors and GPS dropouts are present.
This can also happen with multi rotors if large yaw rates are present.
This was an unintended consequence of the ekfsmoothing patch which improved filter stability during high rate manoeuvres, but made the divergence test more sensitive.
This patch reduces the level of 5Hz and 10Hz 'pulsing' heard in motors due to GPS and altimeter fusion which cause a small 5Hz and 10Hz ripple on the output under some conditions. Attitude, velocity and position state corrections from GPS, altimeter and magnetometer measurements are applied incrementally in the interval from receiving the measurement to the predicted time of receipt of the next measurement. Averaging of attitude state corrections is not performed during periods of rapid rotation.
Time stamps are now explicitly initialised to the current IMU time to avoid unwanted activation of timeout logic on filter start and various calls to the hal.scheduler->millis() object have been consolidated.
Andrew Tridgell
Jonathan Challinger
Randy Mackay
priseborough
Emile Castelnuovo
Robert Lefebvre