this disables the compass in DCM if MAG_ENABLE is changed in
flight. Without this we would use a fixed yaw once the compass is
disabled
This also makes sure we don't pass the compass to DCM till we have
done a read. This ensures we have a good compass fix for the initial
DCM heading
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
after discussion with Randy, we don't want ArduCopter to fall back to
GPS for yaw when the compass becomes unhealthy. So we shouldn't pass
the gps object to the DCM code at all.
We would like to be able to use Vector3f as a parameter while exposing
the individual elements of the vector as MAVLink parameters. This
change to AP_Param makes that possible, by giving AP_Vector3f a dual
personality
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
add NaN checking/error message
add config page shortcuts - F5, ctl-s and ctl-o
add +++ passthrough on terminal
add longer delay to log download
modify param receive process.
modify connecting and param receive process - re Andrew
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
