* I mostly went through with grep and added an #include <AP_Param.h> below
every #include <AP_Common.h>. Not all of these example sketches might
strictly need AP_Param.
the new AHRS code doesn't use calculate() and the compass.heading
attribute. Instead it works on the raw magnetometer vector. This
change removes the internal calculate state from the compass object
and instead adds calculate_heading() for use by older code that
doesn't go via AHRS.
This significantly reduces the calculation involved in compass updates
The null offsets enable/disable code is also removed, as it is not
needed now that compass offsets are not linked to the AHRS state.
when this is 1 (which is the default), we will get the declination
automatically via the AP_Declination library
when it is 0 we will use the value configured by the user
This adds a large amount of noise robustness to the compass offset
learning algorithm, at a cost of 120 bytes of memory. The changes are
based on a long discussion with Bill Premerlani.
this seems to work much better than the old algorithm, converging
faster and more accurately. Even better, it has no linkage to DCM, so
no possibility of nasty feedback effects
This will set the declination based on lat/lon if the user has
not yet saved one to the EEPROM, OR if they have specified via the
config parameter that they want it to overwrite the declination every
3D fix.
Signed-off-by: Andrew Tridgell <tridge@samba.org>
these allow you to control if the compass should be used for yaw and
if it should learn its offsets. This is useful for locking in compass
offsets once they are confirmed to be good, and for learning offsets
without using them in flights.
The default is to behave the same as previously, which is
COMPASS_LEARN=1 and COMPASS_USE=1
Since the magnetometer offsets are not available through the MAVLink parameter interface (since they are an AP_Var vector) this little feature allows them to be reset from the CLI. Useful if you somehow get bad offsets or if you change magnetometer. If you have a bad set of large offset values I have seen issues with the nulling algorithm have trouble converging to the proper values. I have never seen it have trouble converging from 0/0/0, so this could be a useful feature from time to time.
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
rmackay9
Andrew Tridgell
Pat Hickey
uncrustify
Adam M Rivera
Doug Weibel
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