Old behaviour is that anything that wasn't claimed (or failed to
allocate) would become a SITL RPM sensor. This meant we always had at
least one RPM sensor which was allocated but never provided valid data.
New behaviour is that if you want a SITL RPM sensor you have to set type
to 10.
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.
this fixes an issue found by Henry. If level transition is set when
transitioning to FBWA from a Q mode, and the pilot pulls back on the
pitch stick to demand pitch up then the plane would go into a
high-alpha flight state with low vertical throttle so it would not
climb, resulting in it never getting past airspeed wait state
this fixes the coordinated turn calculation for yaw rate in tilt
quadplanes, and also only applies it if demanding at least 10 degrees
roll.
this fixes an issue when the pilot has a small roll demand in FBWA
from slightly off roll RC trim
thanks to Henry for helping diagnose this!
// 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)
Peter Barker
Rishabh
Andrew Tridgell
Andy Piper
Iampete1
Paul Riseborough
nkruzan
Yash Vadi
bugobliterator