omega_I applied continuously. _ki larger. Stop integrating when _omega.length()>20
The key change was the scaling of ge to ensure the error is not
quadratic
This makes 3 major changes:
1) fixes the scaling of the yaw drift correction term to fix the time
constant
2) don't integrate the mag vector over multiple readings
3) accumulate omega_I changes over 15 seconds before applying, to try
to prevent omega_I picking up short term responses
When using GPS for yaw correction we need to apply the x and y omegaI
corrections from the _omega_I_sum in the period before we get to the
minimum ground speed for GPS yaw correction. Otherwise we get a large
sudden omega_I change on takeoff.
this buffers up _omega_I changes in _omega_I_sum over a period of 10
seconds, applying the slope limit only when _omega_I_sum is
transferred to _omega_I.
The result is a huge improvement in the ability of _omega_I to track
gyro drift over the long term.
the 'drop z' method reduced the impact of noise on omegaI, but it also
made us more sensitive to errors in accelerometer calibration and
scaling, as demonstated by the logs from Gabor here:
http://diydrones.com/xn/detail/705844:Comment:834373
Simulation testing shows that the other noise suppression methods
applied in the DCM code, in particular the slope limiting on omegaI
the removal of the weighting and the upcoming use of a _omega_I_sum
buffer have reduced the impact of noise enough that we can now safely
include z in the acceleration calculation.
when a user first connects with USB, and later switches to the
telemetry port without restarting we were getting zero for error_yaw
in the logs, as AHRS.get_error_yaw() was being called twice.
This ensures we give the last value after the counter is reset
this cleans up the separation of drift rates and proportional
correction from yaw source and accelerometers, allow the yaw
to run at a different rate to the accel correction
in_motion is not a good name now it is also used for the compass
The error_course and heading component values don't need to be part of
the DCM object, they can be on the stack to reduce the memory usage a bit
When we first get a compass reading or we first start motion we need
to setup the DCM matrix with the right yaw. This uses
rotation_matrix_from_euler() to get a DCM matrix corresponding to our
current roll/pitch, but with the correct yaw
when we get a bad DCM error we can recover a matrix corresponding to
the current attitude, making it more likely that the aircraft will be
able to recover
The asin() in the pitch calculation can only take values between -1
and 1. This change ensures that the value is in range, and if it isn't
then we force a normalization. If that fails we reset the matrix
The sqrt() costs about 44usec on a 2560, which is small enough for us
not to worry about the speed.
This also changes the range of values where we declare a blowup to
much less likely, which means we can cope with larger delta_t glitches
This is a fix for an interesting bug when a DCM matrix reset was added to the ground start. This bug only showed up if (A) a ground start were performed after an air start or due to use of the "Calibrate Gryo" action, (B) if the current orientation were sufficiently different from 0/0/0, and (C.) if the particular magnetometer had sufficiently large offsets. Why did resetting the DCM matrix to 0/0/0 pitch/roll/yaw at ground start cause a bug? The magnetometer offset nulling determines the proper offsets for the magnetometer by comparing the observed change in the magnetic field vector with the expected change due to rotation as calculated from the rotation in the DCM matrix. This comparison is made at 10Hz, and then filtered with a weight based on the amount of rotation to estimate the offsets. Normally it would take considerable time at normal in-flight rotation rates for the offset estimate to converge.
If a DCM matrix reset occurs when the offset nulling algorithm is up and running, the algorithm sees the DCM reset as a instantaneous rotation, however the magnetic field vector did not change at all. Under certain conditions the algorithm would interpret this as indicating that the offset(s) should be very large. Since the "rotation" could also have been large the filter weighting would be large and it was possible for a large erroneous estimate of the offset(s) to be made based on this single (bad) data point.
To fix this bug methods were added to the compass object to start and stop the offset nulling algorithm. Further, when the algorithm is started, it is set up to get fresh samples. The DCM matrix reset method now calls these new methods to stop the offset nulling before resetting the matrix, and resume after the matrix has been reset.
Andrew Tridgell
Jonathan Challinger
Adam M Rivera
Doug Weibel
Wenyao Xie
Jason Short