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'
This patch will boost the target airspeed as necessary to keep the ground speed above a parameter value - param_min_groundspeed. Airspeed is still limited to FBW-max. Setting min_groundspeed to zero (default) disables the feature.
It is fully configurable with the mission planner, there is no need to change
the source code to adapt to your setup.
It needs more testing, but the SIL is not working for me.
Add code to disable throttle if we are on the ground and in FBW_B or higher. We believe we are on the ground if speed < 5 and alt < 5. Also check that we are not trying to perform a takeoff.
priseborough
Andrew Tridgell
tobias
Randy Mackay
Jochen Tuchbreiter
Pat Hickey
uncrustify
Amilcar Lucas
Jason Short
Doug Weibel