Thanks @Rolf !
Do you still have your tiltrotor? I have an important bugfix for tiltrotors that I will put into 3.9.2beta2. I just want to find someone with good experience of tiltrotors to test.
It is related to using Q_ASSIST_SPEED with a tiltrotor quadplane.
@tridge, I just spent some time researching issues, PRs, and the support forum for the general topic of detecting airspeed sensor failure, whether single or dual sensors. I’m a bit confused as to where the code is in master latest with respect to a sensor that is outputting bad data. As you diagnosed in one of my logs last month, a broken pitot resulted in low readings, which caused high speed dives in RTL to build airspeed, which was never possible given broken tube. I see plenty of activity in March of this year on code to detect/disable/reject bad data, but my recent close call somehow wasn’t caught by that code. Given the severe consequences of a pitot failure, I’m now considering dual, whether two MS4525D0’s, or perhaps second one being other than MS4525D0, or possibly second one being analog. There was a post under Plane 3.8 asking about how to calibrate, log, display second pitot, and I didn’t see a response to that post. Curious if you could summarize state of the union with respect to this general topic. (After OBC, of course).
In the meantime, I am thinking I need to train my brain to fly at least one lap RTL following takeoff to verify rational airspeed values relative to GPS speed and known wind directions. Obviously a working airspeed sensor upon takeoff can fail in the air (icing as the most obvious example) but my gut instinct is that >90% of my likely failures would be due to a hard landing / dirty landing which would cause next takeoff to be high risk. Welcome your thoughts. BTW, I still have the broken pitot tube, and would happily saddle it up on a beater foamie to flight test any future PR’s on this topic.
EDIT: lemme know if you would like this moved to a new topic under Plane.
The only handling we have for detecting bad airspeed sensors in flight is if the sensor stops providing data entirely. If that happens we will swap which sensor is priamry, or fall back to no airspeed data flight. There is no sanity checking of the data past that, and there is no method to sanity check the data. I’m in the same boat of really wanting this. I have logs from an airspeed failure in flight where the tubes remained connected, but the sensor offset rapidly shifted by ~120 pascals or so, and made the vehicle believe it was flying way to fast. The vehicle then stalled out and entered a spin. The sensor offset has persisted after the crash, and does not appear to be associated with anything with the pitot probe, tubing, or items having entered the sensor. (TL;DR airspeed sensors can suddenly fail in flight, I have had 2 vehicles go down due to this, as well as had a couple I caught on the ground before flying). I’ve also seen the kick the pitot tube off before throwing the plane during takeoff which doesn’t go well either
Your only options for handling this at the moment is when you see illogical data on the airspeed sensor either set ARSPD_USE 0 or set ARSPD_PRIMARY to the other sensor if you have 2 sensors. There is some blending code in, but it makes some assumptions that are not safe for all vehicles, and does not work well with a high wind day, so at this point I don’t recommend trying it.
This should be a priority for us to fix for an upcoming 3.9.x release, but not 3.9.2. First step will be to log both the synthetic and hardware airspeed readings, so we can compare them and get a feel for how we can use them to detect failures.
I’ve done testing looking at the EKF variance in the past, it does detect failures as long as it isn’t a slow drift. Unfortunately it resets very quickly, so you have to set a very short timeout on using the EKF airspeed variance to swap sensors. (I’ve even done flight testing that used EKF airspeed variance to disable the sensor. It worked well on large step errors, but will drift with any slow input of error was insufficient. And the log data I have from the failed sensors is showing me that it wouldn’t have helped on any of the inflight sensor failures I’ve had)
I’ve been looking at the difference between an airspeed estimate from solving the wind triangle airspeed_vec = groundspeed_vec + wind_vec
I think looking at discrepancies between that and the airspeed sensor may be a useful addition to EKF innovations.
@tridge Unfortunately in my experience the wind estimator is to slow (and error prone) to generally trust it quickly, if you put a long enough time requirement on it it will work out, but then what happens (and can be seen in the logs I have) is the wind estimate has adjusted to try and compensate for the error in indicated airspeed. (I’d love to see this fixed though)
I have numerous logs with different airspeed sensors during different wind conditions and want to do more test flights with two sensors. Therefore, some questions, suggestions and remarks on the investigation of airspeed sensor failures:
Where can i find the estimated airspeed and EKF innovation in the logfiles ?
For further testflights with two airspeedsensores i would find it helpful if the data of the second airspeed sensor could also be transmitted by mavlink telemetry.
Taranis/Frsky users not always want to take a Mavlink GCS to the airfield just to know the airspeed. For these pilots, security would be increased if the airspeed(s) could be transmitted via AP_Frsky Passthrugh Telemetry and preflight-calibration could be triggered by RC.
A few thoughts on fault detection of airspeed sensors while in auto-mode:
Three airspeed sensors in model flight are not realistic, but two sensors are possible at arduplane - thanks to tridge .
I propose to thought about known power setting (throttle) in auto mode level flight as a third “virtual” sensor ?
Combining knowledge of throttle (with a current sensor) is actually the best addition, because it’s required to differentiate between the failed motor vs failed airspeed sensor. From airspeed alone the two can be indistinguishable.
The other problem to keep in mind with the wind estimate is that when flying long straight legs (IE 1km or more) the wind estimate isn’t meaningfully updated and it can be very stale/mask errors. (I’ve seen this on one case where the vehicle did crash due to airspeed problems)
Is anybody aware that the camera trigger (type relay) does not work with Chibi OS? Tried 3.9.1 and latest beta, no chance! Works after “downgrade” to Nuttx release without changing any parameters.
I am using AUX1 on a Pixhawk 1 (original 3DR) with an attached optocoupler to trigger my Sony NEX (with hacked trigger button).