* 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.