This removes a lot of the ArduPlane specific cruft left over from the
initial Rover import from ArduPlane, plus fixes a bunch of serious
bugs. For example, the rover was unable to use either compass or gps
for heading - it used just gyros!
There is still a lot of cruft left, but this at least gives a bit
better basis for future work
Added option (hold roll to full right + SW7 ON/OFF) to init_home during the wp_list reset
Add ROV_SONAR_TRIG (default = 200 cm) - tested by Franco
Restart_nav() added and heading bug correction, tested OK in the field
RTL then stop update - Tested OK in the field
Added SONAR detection for obstacle avoidance
Signed-off-by: Jean-Louis Naudin <jlnaudin@gmail.com>
the 128 byte serial transmit buffer was causing significant problems
with queueing of mavlink messages. With 256 bytes we can fit a lot
more messages out in each pass of the code, which makes telemetry more
efficient
As we discussed on the dev call, we now have enough free ram for this
to be worthwhile
when MANUAL_LEVEL is set to 1, we don't do accelerometer levelling at
startup, and instead used the values saved in the EEPROM. This makes
it easier to do levelling on the bench, or once for a series of
flights for the day
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
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.
Andrew Tridgell
rmackay9
Jean-Louis Naudin
Michael Oborne
Robert Lefebvre
Doug Weibel
Pat Hickey