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
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 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
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 adds an extra budget of time per loop when we are not achieving
scheduled tasks at a rate of at least 1/8 of the desired rate. This
fixes an issue where a vehicle can become uncontrollable if the user
asks for a SCHED_LOOP_RATE which is not achievable. As these events
happen we add extra loop budget until we are able to run all tasks. We
drop the extra time when the CPU pressure eases.
this allows a maximum range since first arm to be set in
AFS_MAX_RANGE. This value (in km) will trigger the configured
termination type if the GPS location shows that it has been breached.
This feature, in combination with the @READONLY apj parameter feature,
is intended to be used to meet regulatory restrictions on a vehicles
maximum range
this allows the native i2c lightware driver to work with a wide range
of lidars from LightWare, removing the specific version check, and the
version specific config commands
This formulation of the notch equations lets the user specify the depth of the Notch. The presence of a diveide by A prevents the gain going to zero and therefore achieving a perfect notch. It also provides the risk that a user may attempt to do this and cause a divide by zero error. This change adds the ability to achive a perfect notch and removes the possibility of a divide by zero.
Add Notch Filter parameter checking
This delegates updates to a bank of NotchFilters located at an rpm frequency and harmonics. Center frequency can be updated dynamically. Notch parameters are configurable, including the number of harmonics to filter on. Updates to the filter parameters are optimized across the notch bank. Convert notch bandwidth and frequency to floats.
allow all filter harmonics to be controlled.
add destructor to harmonic notch.
don't allocate sub-filters for harmonic notch if no harmonics set.
The header needs stdint.h which it was only getting because it was
included after stdint.h in the cpp file.
Stop including standard headers before other ArduPilot headers
we need to return the number of bytes that would have been printed if
the buffer was big enough to support use cases such as vasprintf()
which needs to know how many bytes to allocate
If there is another thread holding a lock that the main thread wants to
take while pretending to be the IO thread, we will wait forever as we do
not move SITL time forward while pretending to be the IO thread.
This patch simply allows time to move forward if we've failed to take a
semaphore immediately and need to wait.
this allows for common code between CAN and pin safety switches, as
well as making the code neater as most of the logic is related to
AP_BoardConfig options