the automatic min-alt fence should not auto-enable based on altitude
if the fence has been manually disabled. This is needed to allow for a
manual landing by disabling the fence before descending
the _auto_enable_mask was try to make AUX function overrides disable
the FENCE_AUTOENABLE functionality. This isn't the right bevaviour,
both the aux function and the auto-enable should be edge triggered,
with last function taking effect
control copter floor fence with autoenable
autoenable floor fence with a margin
check for manual recovery only after having checked the fences
make auto-disabling for minimum altitude fence an option
output message when fence floor auto-enabled
re-use fence floor auto-enable/disable from plane
auto-disable on landing
do not update enable parameter when controlling through mavlink
make sure get_enabled_fences() actually returns enabled fences.
make current fences enabled internal state rather than persistent
implement auto options correctly and on copter
add fence names utility
use ExpandingString for constructing fence names
correctly check whether fences are enabled or not and disable min alt for landing in all auto modes
add enable_configured() for use by mavlink and rc
add events for all fence types
make sure that auto fences are no longer candidates after manual updates
add fence debug
make sure rc switch is the ultimate authority on fences
reset auto mask when enabling or disabling fencing
ensure auto-enable on arming works as intended
simplify printing fence notices
reset autofences when auot-enablement is changed
this allows for treating total inclusion area as union of all
inclusion areas. This is useful for:
- circles with corridors between them
- a fence for each flying site all loaded at once
- temporary addition of an extra area to a complex fence
AC_Fence: Add fence floor breach checks and calculations
AC_Fence: Add event logging to enable/disable of fence floor
AC_Fence: Adjust sys_status reporting to look at total fence count
AC_Fence: Make retrieving of the return point accessible
AC_Fence: Check whether fence is enabled or autoenable is set for arming checks
Checks whether the fence is currently enabled OR if the fence is intended to be enabled automatically.
These checks are used to find out enabled fences, or prearm checks
This should resolve a problem in autotest where we don't detect the
fence as being breached as ArduPilot never announces the fact it has
breached - it just changes mode to RTL but the interval on the
FENCE_STATUS message never aligns with the time the vehicle is breached.
AC_Fence: add interface for retrieving exclusion polygons
AC_Fence: add interface to get exlusion polygons to polyfence loader
AC_Fence: add suport for inclusion circles
AC_Fence: add option for compiling-out FENCE_POINT protocol support
AC_Fence: get_exclusion_polygon and get_boundary_points set num_points to zero on failure
AC_Fence: use Debug(...) to hide debug messages
AC_PolyFence_loader: add methods to retrieve all inclusion zones
AC_PolyFence_loader: valid simply returns true if a polygon boundary can be returned
AC_Fence: add get_exclusion_circle
AC_Fence: add get_exclusion_circle_update_ms accessor
AC_Fence: PolyFence_loader gets inclusion circle accessors
AC_PolyFence_loader: add and use semaphore to protect loaded fence
AC_Fence: move fence breach check below fence type checks
This allows us to provide more information to the user about why they
are breached.
For example, if the radius is negative you are considered in breach of
it - but we'd tell you you were breached, not that your radius was
invalid
AC_Fence: clear the fence if we discover the user has set the fence count to zero
There's only one caller to this, who didn't force loading - so remove
the unused parameter.
Also remove the _boundary_loaded boolean; it was only set to true in one
place - just before the sole caller called the function!
See discussion here:
https://github.com/ArduPilot/ardupilot/issues/7331
we were getting some uninitialised variables. While it only showed up in
AP_SbusOut, it means we can't be sure it won't happen on other objects,
so safest to remove the approach
Thanks to assistance from Lucas, Peter and Francisco
Andrew Tridgell
Andy Piper
jackhong12
Iampete1
Peter Barker
James O'Shannessy
Dr.-Ing. Amilcar Do Carmo Lucas
murata
Pierre Kancir
Randy Mackay
chobitsfan
Raouf