AP_Airspeed: Airspeed sensor failure detection and mitigation #4122
Conversation
magicrub
force-pushed
the
mypr/airspeed_self_check
branch
from
9a872f8
to
2fa074c
Compare
|
The comment at the top says removed some NTUN parameters but I don't see that in the code anywhere? |
| if (ahrs.get_variances(trashf,trashf,trashf,trash3f, true_airspeed_variance, trash2f)) { | ||
| airspeed_data_validity = true_airspeed_variance < 1.0f; | ||
| } else { | ||
| const float error_threshold = target_airspeed_cm * 0.002f; // cmd to m conversion * 20% error. |
There was a problem hiding this comment.
This check is far to strict for my aircraft at least. Unless I'm doing my math wrong, is there a way to graph the errors out of some logs? (Curious what it thinks the error is when the plane is fast to do a descent).
There was a problem hiding this comment.
Airspeed logging was committed here: ba5b4e6
|
The NTUN logging was already commited here: 1551b9d I updated the PR description |
magicrub
force-pushed
the
mypr/airspeed_self_check
branch
from
2fa074c
to
32e8fd5
Compare
new param ARSPD_FAIL_ACTN which is a bitfield to perform a couple tasks or behavior upon detecting bad pitot tube.
// @description: When a pitot tube is determined to be generating untrustworthy data, various actions can occur which are set by a bitmask. 0 = do nothing, 1 allows disable and reverts to using internal estimate, 2 allows auto-reenable when airspeed sensor is determined to be trustworthy again (NOT SUPPORTED YET), 4 if ARSPD_USE value changes then save to non-volatile memory
magicrub
force-pushed
the
mypr/airspeed_self_check
branch
from
32e8fd5
to
1b3f18c
Compare
|
@WickedShell Have you flown master lately and have logs with airspeed? I've added airspeed error logging a few weeks ago and EKF2 has always had it, would love to hear yoru feedback about what the logs look like on your plane. You can check NKF4.SVT (which is the one that really matters) and also NTUN.ArspdErr which is a simple target minus actual in case EKF2 blows up |
|
on the dev call we decided the DC wind estimate should run all the time and be referenced. Since the EKF's airspeed est is based on the pitot when enabled, it is potentially corrupted data so we should compare EKF vs DCM estimates when deciding to disable it. This also allows us to check the DCM wind est with pitot still enabled so we can check to turn it back on. |
|
@magicrub Just so you know this failed Semaphore because of Clang packages not being available now. That is fixed in master so if you just rebase it should pass the test. |
|
Thanks. |
|
this needs more work and a huge rebase, closing.. |
I've added some sanity checking to the airspeed and it can now disable itself automatically. A boolean check is made to determine if the airspeed sensor is trustworthy. If EKF1 or EKF2 is used then it looks at the:
airspeed innovation <1 otherwise it reverts to:
abs(target_airspeed - measured_airspeed) < (20% of ARSPD_TRIM)
When in AUTO mode, the new airspeed sanity checking is bypassed during TAKEOFF, PreFlare, Flare, and VTOL stages. In addition, the aircraft must be flying for at least 10 seconds. If failing this test for 3 continuous seconds then the ARSPD_FAIL_ACTN will kick in.
new param: ARSPD_FAIL_ACTN:
// @description: When a pitot tube is determined to be generating untrustworthy data, various actions can occur which are set by a bitmask. 0 = do nothing, bit 1 allows auto-disable and reverts to using internal estimate by setting ARSPD_USE=0, bit 2 allows auto-reenable when airspeed sensor is determined to be trustworthy again (NOT SUPPORTED YET), bit 4 if ARSPD_USE value changes then save to non-volatile memory
// @bitmask: 0:None,1:AutoTurnOffUse,2:AllowResumeUse,4:Save