This code is less relevent with the new L1 navigation, and could cause
issues with the pilot not having control after a long dive.
Thanks to Soren for pointing out the issues
See issue #305
this switches ArduPlane over to use the L1 navigation controller, via
a generic nav_controller object pointer.
Note that the nav_controller controls all types of navigation now,
including level flight and heading hold. This provides a cleaner
abstraction than the old method of special case navigation handling
Pair-Programmed-With: Paul Riseborough <p_riseborough@live.com.au>
this makes FBWB much less sensitive to airframe tuning. When the
elevator stick first goes neutral it locks in the current altitude as
the target altitude. When the elevator stick is off neutral, it moves
the target altitude in proportion to the elevator, at a rate goverened
by the new FBWB_CLIMB_RATE parameter
This prevents the aircraft from slowly drifting in altitude in FBWB,
and gives a more intuitive control mechanism for altitude.
Thanks to Chris Miser from Falcon UAV for help in designing this
change
this mode gives manual control when the roll or pitch is within the
set limits (the same limits as FBW mode), and prevents the pilot from
flying beyond those limits, essentially a "attitude limited manual"
mode
this fixes using GPS_PROTOCOL to specify a specific GPS with a GPS
that takes a few updates before it works (eg. needing baud rate
changes).
This makes it easier to use an APM1-1280 with more features enabled
this removes the throttle suppression when any of the conditions are
met once, as otherwise flying slow below 10m could zero the throttle.
It also removes the use of airspeed for disabling throttle
supression. Otherwise a strong gust of wind can cause ArduPlane to
try to takeoff!
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
Randy Mackay
Pat Hickey
Michael Oborne
uncrustify
Doug Weibel