when we are in the final stages of a landing (less than 2 seconds from
landing waypoint, or less than 3m above landing altitude) we switch
the navigation to use a fixed course. The code previously used the
crosstrack_bearing for this, but this can lead to a large nav_roll in
this final stage of the approach, which can put a wing into the
runway. In autotest we were seeing a nav_roll value of -45 degrees as
we crossed the transition point for the landing, which often led to a
crash.
This changes the code to use the current yaw_sensor value instead,
which is much less likely to lead to large rolls in the final landing
stages.
hold_course is either -1 (for disabled) or a course to hold for
takeoff/landing. This makes the code a bit clearer.
It also resets hold_course in all non-auto modes, to ensure it isn't
used
If you include airspeed, throttle or groundspeed changes in a mission
then those should not be saved to EEPROM, as otherwise if you restart
and re-fly the mission you will be starting with different parameters
to the ones you used for the first flight.
This is particularly important for setting the target airspeed when
coming in for a landing. You typically set a low target, but if you
fly again the next day I think it would be a real surprise to find
that your loiter airspeed has then changed to the value from the
landing part of your last mission.
This one can be argued either way, but I think that not saving these
changes is the more conservative choice, and better fits the
'principal of least surprise'
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
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.
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.
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.
we now pass all channels through at 50Hz if the main loop stops
running, regardless of why. This gives us a reasonable failsafe, as
long as the low level RC library is still working, and interrupts
don't get completely disabled.
This is useful for switching back to the mode indicated by the control
switch after a failsafe or fence breach. I was just changing modes
each time, but it is far more elegant to have a spring loaded switch
for "I am ready to take control again", rather than continually
changing modes.
if you disable fencing with the fence channel switch while still in
GUIDED mode to the return point, then reset the control mode back to
the transmitter control mode
* Wire.begin removed from AP_Baro_BMP085::init()
* SPI.begin removed from AP_Baro_MS5611::init()
* SPI.begin removed from AP_InertialSensor_MPU6000::hardware_init()
* Both Wire.begin and SPI.begin added very early in init_ardupilot in
ArduCopter/system.pde and ArduPlane/system.pde
Andrew Tridgell
Phil
Sandro Benigno
Pat Hickey
Michael Oborne
analoguedevices
Doug Weibel
Jason Short