// 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)
No vertical whitespace allowed in the structures...
We concatenate all of the LogStructure files; without this we remain in
state_inside and try to parse every line in the concatenation as if it
were a log structure definition
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.
Yash Vadi
Andrew Tridgell
bugobliterator
Peter Barker
Hwurzburg
murata
Dr.-Ing. Amilcar do Carmo Lucas
Andy Piper
Sebastian Quilter
Patrick José Pereira