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.
this changes the calibration code to require at least 5 good reads
from the compass during initialisation. The calibration is taken as
the average of the 5 values.
This also fixes the expected values for the 3 axes for the 5883 to
match reality.
We also save a bit of code space by adding a common rotate_for_5883L()
routine.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@3087 f9c3cf11-9bcb-44bc-f272-b75c42450872
this adds a 50ms delay after setting the compass gains before reading
the compass. Added as paranoia after some strange results on a 5843
git-svn-id: https://arducopter.googlecode.com/svn/trunk@3070 f9c3cf11-9bcb-44bc-f272-b75c42450872
we were looking for the wrong regA value
Thanks to Chris for the debugging help! (and happy birthday!)
git-svn-id: https://arducopter.googlecode.com/svn/trunk@2828 f9c3cf11-9bcb-44bc-f272-b75c42450872
this adds error checking to all operations on the compass, to ensure
that we don't accept invalid data
This also fixes the calibration values for the 5883L to match the
recommended values in the spec
git-svn-id: https://arducopter.googlecode.com/svn/trunk@2815 f9c3cf11-9bcb-44bc-f272-b75c42450872
this fixes a compass initialisation bug where if the first value from
the compass isn't in the right range we would set bad calibration
scaling factors.
This also changes the maximum acceptable calibration values to 2000,
which is needed for the 5883 compass
pair-programmed-with: Randy Mackay
git-svn-id: https://arducopter.googlecode.com/svn/trunk@2718 f9c3cf11-9bcb-44bc-f272-b75c42450872
Most of the compass functionality is now abstracted in a base class, with the various sub-classes implementing just their unique functionality.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1647 f9c3cf11-9bcb-44bc-f272-b75c42450872
Doug Weibel
Andrew Tridgell
James Goppert
unknown
tridge60@gmail.com
jasonshort
rmackay9@yahoo.com
deweibel@gmail.com
james.goppert
james.goppert@gmail.com
mich146@hotmail.com
DrZiplok@gmail.com
deweibel
DrZiplok