The is the first beta release of the plane 3.9.2 stable release. It contains a number of important bug fixes.
fixed a quadplane bug that could cause large attitude instability during takeoff if the aircraft does not have enough power to climb to its target height. Thanks to Leonard for the fix.
fixed a bug that prevented dead-reckoning working on GPS loss.
fixed an ADC bug that prevented some boards from using all of their analog input. Thanks to vierfuffzig for reporting!
fixed a bug in advanced failsafe support that left RC input to throttle active after termination. Thanks to Michael Thomas for finding this bug.
fixed use of OLED displays on the first I2C bus on systems with two I2C buses
Thanks to everyone who has contributed, and please report all test results with this beta.
Works perfectly ( Mini Talon Quadplane with 2MB Pixhawk 1). Todays flight: QStabilze, QHover,FBWA, transitions)
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.
Yes sure @tridge
Q_ASSIST_SPEED for tiltrotors ? We will test it.
I’ve just released Plane 3.9.2beta2. The is the second beta release of the plane 3.9.2 stable release. It contains a number of important bug fixes.
implement failsafe PWM in IOMCU, for AFS failsafe when FMU dies
handle reversed channels correctly in AFS failsafe
fixed twin motor plane handling in AFS failsafe
fixed a bug in Q_ASSIST_SPEED support for tiltrotors that could lead to zero throttle when assistance triggers.
lower default PTCH2SRV_D to 0.04 after reports of oscillation on small flying wings
added speed scaler reduction in Q modes when at low airspeed
fixed synthetic airspeed estimation to be along +ve X axis
fixed relaxing of VTOL attitude controller on transition (thanks to Leonard Hall)
default COMPASS_AUTO_ROT to 2 on all boards
fixed UART speed rounding bug that caused failure at high board rates
fixed a short glitch in position control on quadplane transition (many thanks to Leonard for lots of help with this)
fixed RSSI voltage from IOMCU
Thanks to everyone who has contributed, and please report all test results with this beta.
@Rolf please test it with 3.9.2beta2, which I have just released. It should make Q_ASSIST_SPEED work properly. Thanks!
Q_ASSIST_SPEED works perfectly on tiltrotor (Q_ASSIST_SPEED = 9, a little bit below ARSPD_FBW_MIN =10).
Great, thanks @Rolf! I really appreciate you testing this.
I’ve just released 3.9.2beta3. The is the third beta release of the plane 3.9.2 stable release. It contains a small number of fixes:
I expect this will be the last beta release before 3.9.2
@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.
Agree. Standing by with faulty pitot tube and disposable foamie to help flight test.
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:
For the reliable identification of a faulty airspeed sensor, actually three airspeed sensors would be required.
(In human failure, three sensors unfortunately were not enough in every case: https://en.wikipedia.org/wiki/Birgenair_Flight_301 )
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).
Check your BRD_PWM_Count and set it = 0. NuttX had a bug where using the relay would override the pwm controller even though the parameters conflicted. The relay trigger does work in Chibi OS.