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.
the averaging array was using 16 bit numbers, but we are storing
numbers with 19 significant bits. That caused overflow at high
altitude, and some very interesting altitude graphs!
Thanks to Michael Oborne for spotting this in a log
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.
* Every use of MSK_CH_n changed to _BV(CH_n)
* Easier to read, and will allow CH_n to be parameterized without needing
a separate macro expansion for the MSK value.
Other unrelated changes are:
a) fixed typo in 'esitmate_velocity' to 'estimate_velocity'.
b) moved init_compass from system.pde to sensors.pde which seemed consistent with other sensors.
this moves out all the high level logic from ArduPlane/ArduCopter to
the library. It also adds a "config page", as the last page in the
flash. This is used to check if the flash needs erasing. We only erase
now if the DF_LOGGING_FORMAT has changed.
This patch also adds a public CardInserted() method, which is used to
disable logging on APM2 if a dataflash card is not inserted
this moves all the non-hardware specific code to the parent
DataFlash_Class class, keeping the hw specific code much smaller and
simpler.
This should prevent discrepancies creeping in between APM1 and APM2
support again
Jason Short
Michael Oborne
Andrew Tridgell
Doug Weibel
Mike Smith
Randy Mackay
Pat Hickey