Saves 24bytes of RAM
Removing the baro filter leads to noisier Baro Alt appearing in the log
so we should make the inertial nav altitude appear in the CTUN message
- Allows use of hardware floating point on the Cortex-M4.
- Added "f" suffix to floating point literals.
- Call floating point versions of stdlib math functions.
Improved surface tracking by using slewed althold controller
Reduced sonar mode filter to just 3 elements to reduce lag but at the possible consequence of allowing sonar noise to creep through for people with margin sonar set-ups.
Failsafe events changed to errors so they are more obvious.
Errors recorded to dataflash for failure to init compass and optical flow sensor.
Errors recorded for pwm failure.
Resolved a compile error when dataflash logging is disabled.
Merged CopterLEDS and Piezo functions to eliminate pin conflict on APM2. Created new Parameter bit to turn piezo function on and off from MP. Moved GPS and Aux pin assignments to allow commonality between APM1 and 2. Set LED_Mode parameter default to 9 in order to make CopterLEDS completely backwards compatible with old Motor LEDS and Piezo code. Legacy users should see no difference.
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
Fixes compatibility for APM2. Also a significant update to the battery monitoring code: We previously had monitoring modes for individual cell voltages for 3 and 4 cell lipos. These have been removed as they were never really supported (the cell voltages were computed but were not reported or recorded anywhere). Also, some clean-up/prep work was done for supporting monitoring 2 separate battery packs. The CLI battery and current monitoring tests were consolidated into 1 test.
changed
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.
Andrew Tridgell
Randy Mackay
James Bielman
Pat Hickey
uncrustify
Robert Lefebvre
Jason Short
Michael Oborne
Doug Weibel