these wait busy loops can take a very long time, and end up causing
interrupts to be lost elsewhere in the system, causing lost bytes on
UARTs
We should not have while loops waiting on peripharals like this. If we
do need to wait for a flag to clear then it needs to be done in a low
priority thread, or we need to check for completion in a timer
CAN still seems to work with this change, but needs flight testing
now that we persist logging for 15s after disarm we need to also delay
the log rotation if LOG_FILE_DSRMROT=1. Otherwise we will put the log
data into the next log, which defeats the purpose of the 15s
persistance
this provides a common location for static intermediate variables in
EK2 and EK3. This has a few benefits:
- the compiler can determine the address of the frequently accessed
variables at compile time, making them faster
- by sharing between EK2 and EK3 we save a lot of memory if both EK2
and EK3 are enabled
- we can fill all these with NaN in SITL on every loop, which allows
us to catch cases where the variables are ever re-used between
loops, which guarantees we aren't mixing data between EKF lanes or
between EK2 and EK3
when we have corrupt input due to loss of bytes on a UART we can end
up with a u-blox packet with zero payload bytes. When that happens we
need to bypass payload reading as otherwise we will end up keeping
reading bytes until the driver resets at 4 seconds, causing a GPS
outage.
This was causing GPS outages every few hours in copters running 3.6.7,
and was also reproduced in SITL using SIM_GPS_BYTELOSS.
this frees up DMA for USART1_RX, which gives DMA for input over the
SERIAL5 WiFi port, which is important for applications where a
pixracer is being fed vision data over WiFi
AP_OABendyRuler: support exclusion polygons
AP_OADijkstra: support exclusion polygons
AC_Avoid: adjust_velocity supports exclusion polygons
AC_Avoidance: handle fence::get_boundary_points returning nullptr instead of setting num_points to zero
AC_Avoidance: Dijkstra's works with only exclusion polygons
AC_Avoidance: Dijkstra: check for fence counts instead of polyfence validity
We really only care whether fences can be returned - and they won't be
returned unless they are valid
AC_Avoidance: BendyRuler: just try to get inclusion fence rather than checking validity
AC_Avoidance: BendyRuler supports exclusion circles
AC_Avoid: Dijkstra support for exclusion circles
AC_Avoid: BendyRuler support for inclusion circles
AC_Avoid: stop an inclusion/exclusion circular fences
AC_Avoid: stop at inclusion/exclusion circular fences
AC_Avoid: fixes to Dijkstra's use of inclusion/exclusion circles and polygons
AP_Avoidance: take semaphores when interacting with AHRS and polyfence
AC_Avoid: Dijkstra's fix for some_fences_enabled inclusion circles
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
Michel Pastor
Randy Mackay
Peter Barker
Henry Wurzburg
Andrew Tridgell
vierfuffzig
Tatsuya Yamaguchi
IamPete1
Mark Whitehorn
mhefny