The gpsAccuracyGood flag should not be used because it will go false if GPS innovations become high due to bad yaw which is when the EKFGSF is required. to keep running.
// because MISSION_SET_CURRENT is a message not a command,
// there is not ACK associated with us successfully changing
// our waypoint. Some GCSs use the fact we return exactly the
// same mission sequence number in this packet as an ACK - so
// if they send a MISSION_SET_CURRENT with seq number of 4
// then they expect to receive a MISSION_CURRENT message with
// exactly that sequence number in it, even if ArduPilot never
// actually holds that as a sequence number (e.g. packet.seq==0).
if a a message send fails to IOMCU then we were discarding all
currently pending non-recurring events. This means that states like
oneshot enable would be lost if the IOMCU reset.
We now re-trigger all events that have not yet been handled
this works around a bug in the ICM-20602 that can cause the Y facttory
offset register to change unexpectedly. We don't know what triggers
this.
The fix is to save the factory offset at boot and restore it if it
changes. We log a message describing the change, but don't mark the
IMU unhealthy as this happens too often and we don't want to fallback
to a 2nd less good quality IMU (eg. MPU6000 on MatekH743)
In the case you only have a forward-pointing LIDAR we'd send messages
for each of the other orientations from proximty's horizontal-distances
array, chewing up bandwidth and processing time.
In the case you only have a forward-pointing LIDAR we'd send messages
for each of the other orientations from proximty's horizontal-distances
array, chewing up bandwidth and processing time.
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.
this takes better advantage of the new UART code. Log download over
USB gets to 730 kbyte/s. For comparison, with the 4.0 code on the same
H7 we get about 300 kbyte/s
this gains about 20k of RAM, and has almost no impact on log download
speed at 921600 on a F427. The improved threading means we can afford
to have smaller buffers
refactor rcout into separate thread and process all dshot requests there
move uart DMA completion to event model
process dshot locks in strick reverse order when unlocking
convert Shared_DMA to use mutexes
move UART transmit to a thread-per-uart
do blocking UART DMA transactions
do blocking dshot DMA transactions
trim stack sizes
cancel dma transactions on dshot when timeout occurs
support contention stats on blocking locking
move thread supression into chibios_hwdef.py
invalidate DMA bounce buffer correctly
separate UART initialisation into two halves
cleanup UART transaction timeouts
add @SYS/uarts.txt
move half-duplex handling to TX thread
correct thread statistics after use of ExpandingString
set unbuffered TX thread priority owner + 1
correctly unlock serial_led_send()
don't share IMU RX on KakuteF7Mini
observe dshot pulse time more accurately.
set TRBUFF bit for UART DMA transfers
deal with UART DMA timeouts correctly
don't deadlock on reverse ordered DMA locks
change PORT_INT_REQUIRED_STACK to 128
calculate DMAR pulse times correctly
ensure 50us pulse separation for LED
make sure the LEDs are signalled for output
only allow LED length to be set once
treat VTX frequency as a first class citizen, match band/channel to frequency
update CRSF to use new VTX configuration
use a 6-position switch to control VTX power
add support for VTX GCS announcement
announce VTX updates on CRSF
support pitmode-until-arm and pitmode-on-disarm
Co-authored-by: luis.martinez.exts <luis.martinez@juntadeandalucia.es>
set the VTX parameters to what was actually configured by the VTX
use change band/change frequency when appropriate
set power levels appropriately for protocol version.
Co-authored-by: luis.martinez.exts <luis.martinez@juntadeandalucia.es>
When hw flow control is enabled check the CTS pin before we grab the
DMA channel to prevent a long timeout trying to send to a blocked port
from holding a DMA channel against another device
this fixes issue #16587
we don't want to use real dates here as that would mean we don't get
consistent builds. Being able to reproduce the exact build at a later
date is a valuable property of the code
The git hash should be enough
