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>
- 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 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
when enabled this will use the wind estimation code to adjust the
navigation bearing, allowing the navigation code to cope with much
higher levels of wind while using a compass
the new test is that we have passed a "finish line" perpendicular to
the track between the last waypoint and the current waypoint.
The previous tests are also still used, so if we circle a waypoint or
get within the waypoint radius we also consider it completed
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'
priseborough
Andrew Tridgell
tobias
Randy Mackay
Jochen Tuchbreiter
Pat Hickey
uncrustify
Amilcar Lucas
Jason Short
Doug Weibel