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 allows control over whether ArduPlane tries to hold heading
during auto takeoff. For hand launches it can be better to hold the
wings level and not attempt to hold heading during takeoff to prevent
the possibility of a stall during the climb out.
Thanks to Chris Miser from Falcon UAV for the feedback that led to
this option.
- libraries/AP_Common/AP_Common.h: Use bit 2 of Location.options to store
loiter direction
- ArduPlane/defines.h: New bitmask MASK_OPTIONS_LOITER_DIRECTION for struct
Location bit 2
- ArduPlane/ArduPlane.pde: New variable loiter_direction
- ArduPlane/GCS_Mavlink.pde: For mavlink loiter-commands use sign of param3 to
detemine direction. Set Location.option flag accordingly
- ArduPlane/commands.pde: Make sure loiter-directions get saved into EEPROM
correctly
- ArduPlane/commands_logic.pde: Set loiter_direction on all loiter-actions
as well as RTL/instant loiter
- ArduPlane/navigation.pde: Yield loiter_direction in update_loiter
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
* I mostly went through with grep and added an #include <AP_Param.h> below
every #include <AP_Common.h>. Not all of these example sketches might
strictly need AP_Param.
Updated ArduCopter, ArduPlane and example sketches in AP_InertialSensor, AP_IMU and AP_AHRS libraries because they no longer need to pass in cs_pin to the constructor
this drives the speed of the 50Hz loop by the number of samples
accumulated in the IMU. This should give much more consistent timing
in DCM.
Thanks to Randy for introducing this scheme in ArduCopter!
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
With this change we average over 100 mag readings per compass.read()
call, which means we are reading the compass at over 1kHz instead of
10Hz. The noise reduction is huge.
this allows a user to setup the OBC failsafe system to forcibly crash
the plane (surfaces at limits, zero throttle) when the failsafe system
triggers. This is to allow APM to be used in the Outback Challenge. In
the OBC an external failsafe board also does this using the heartbeat
control pin, so this is an extra safety mechanism.
To prevent users accidentially triggering a crash, this code only
activates if FS_TERM_ACTION is set to to the magic value 42.
this allows you to select different altitude control algorithms. The
current choices are for the default (automatic based on if airspeed is
available), or to force a non-airspeed algorithm
The idea is to make it possible to use airspeed for some things (like
wind speed, speed scaling) but not for alt control
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!
