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.
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.
