The changes since the 3.9.2beta3 release are:
fixed a DShot send bug that could lead to board lockup
fixed RGB LED display on Pixracer under both NuttX and ChibiOS
fixed safety switch option handling bug
Thanks for the bug reports and testing by all users for the 3.9.2beta
series!
Happy flying!
First of all, my X-UAV Clouds (Pixhawk 1), Volantex ASW28 (Matek F405 Wing) and Mini Skywalker (F4 pro bus) fly well with AP 3.9.2 stable.
With a SkyEye from HK, I have flown with Arduplane more then 150 times. Last flights with a 3,9,2 beta version without problems, the crash flight yesterday then with 3.9.2 stable:
I have no idea why the Pixhawk after a short time did not respond to any inputs in FBWA. Only remarkable: very windy and after booting the plane was rocking for several minutes on the ground in the wind until arming. On impact SD card jumped out. However, datas were recorded until shortly before the impact. Unfortunately, I did not switch to manual mode in time. Compared to other flights, I’ve only noticed the difference between the different pitch parameters (AHR2.Pitch / ATT.Pitch) so far.
Faulty ATT.Pitch in FBWA causes the crash ?
@Tridge: Can that be the reason for the failure?
Logfile and paramters: https://www.magentacloud.de/share/vzwintzond
Regards Rolf
Had an issue like that today. Same version. Suddenly no response from my input. The plane fall out of the sky.
@Rolf - what sort of battery system are you using? This graph is extremely unhealthy if you’re using 3S LiPos:
@Mr_Green Got logs?
BAtterys: meanwhile old 3s 5200m Ah, these green ones from HK. At first I had also thought of a voltage dip, but on-board voltage and servo voltage are ok
Thanks for the fixes! One problem I’m running into is that, after updating to 3.9.2, dataflash logs became very small and do not contain much useful information. I’m suspecting it is not starting properly. Any idea why that would happen?
I think the crash was caused by a combination of factors. The log shows quite a few things went wrong.
To start with, the airspeed readings look quite a long way off:
Hi Tridge,
Thanks for the quick response and impressive analysis. The bad compass is a realy bad thing and i also believe its a corner case. But the airspeed reading wasnt bad !!! Sunday and in recent days we have had realy 30-40 km/h (appr. 10 m/s) gusty wind just a few meters above ground ! Basically, arduplane works well also in strong winds. Here is a log 3 days before with the same firmware in heavy wind on the XUAV Clouds (Groundspeed, Airspeed, True Course):
Back to the above flight:
We startet against app. 10 m/s wind. So the difference between groundspeed and airspeed is more then realistic at “Position A” with 10 m/s difference between airspeed and groundspeed on true course 150 against wind:
At “Position C”, again 150° true course, difference was app. 9 m/s. Thats also realistic.
At crosswind “Position B”:
the plane has a true course of about 70 °, so about 80 ° crosswind to the track over ground and a difference of only 5 m/s between groundspeed and airspeed. That is also realistic. Due to the bad compass reading, we dont know magnetic heading. But to perform a true course 80° Crosswind, the WCA (Windcorrectionangle) at 14 m/s airspeed should be 43°. Sinus 43° x 10 m/s = 6,8 ms Airspeed-Difference. Measured Difference was 5-6 m/s at this direction. So I have no reason to assume that the airspeed measurement was very bad.
Possibly nothing would have been happened if I had turned into the tailwind at point A to the left ? Then the groundspeed would have been much higher than the airspeed and EKF would not have been disturbed by the bad compass alone?
In the future, I will definitely make sure that the compass is well calibrated on “normal” airplanes, esp. in very windy conditions.
Rolf
Hi Guys,
I noticed the talk about a bad compass. What are your thoughts on disabling the compass for planes and using just the GPS movement?
Cheers!
Hi Greg,
in my oppinion disabling a compass will not be necessary anymore. The calibration of even big planes is no longer a problem - thanks to Tridge’s work: Testers needed for in-flight compass learning
On my Mini Talon VTOL the compass was calibrated after a minute of flight.
At VTOLS, the compass is important for hovering anyway.
The inflight calibration feature will certainly be available at the next regular update.
Cheers, Rolf
Hi all is the new HERE2 gps can-bus supported in 3.9.2 ?
Here 2 doesn’t yet support canbus, it is a future development. I am too waiting anxiously for it 
Hello Here 2 does support canbus you can buy them now
what wish to know is ardupilot plane 3.9.2 supporting new gps yet
Last time i checked they said it was supported but in future releases, it means it has the hardware but not the software to drive it yet, but maybe they did it in the last month.
regards,
Corrado
Hi Rolf
We had the exect same crashes two times, different plane, different arduplane version, same conditions.
Both flight ended up in high airspeeds.
Planes were a Skywalker EVE 2000 and a Believer twin plane.
Both have a criusing airspeed about 18-20 m/s but both crashed over 30 m/s. Like yours.
Speeding up may be a pilots fault but the planes become uncontrollable is defniately some kind of software bug. Both planes stayed in shape while in the air, so they weren’t a couse of weak airframe os something.
Absolutely same behaviour. Slight roll until reaching mother earth.
I don’t have a nice video like yours but somehow would be able to link our flight log if anybody interested in.
Hi Gabor,
the flightlogs are definitely important to find the cause of the accident. Can you send a link to the flightlogs?
Hi Rolf
Here is a link for my crash log.
I can’t speak for the EVE 2000, but I do have some experience with the Believer 1960. Once you exceed 60mph, or around 25m/s, with a fully loaded airframe, you start to see wing flex problems. Notably, wing torsion makes the ailerons ineffective, and sometimes they even have an opposite effect than what you command. If you don’t know about this, it CAN feel like the plane is out of control, and if it happens in AUTO, the plane will likely crash.
Unfortunately I don’t know enough about using logs to diagnose your issue further, but that is something to look for.
Thank you for your input. We will definately look after airspeeds.
Hi Gabor,
the crash of your believer must have had another reason, because all pitch / roll / yaw estimates match (see ATT.Pitch/Roll/Yaw, NKF1.Pitch/Roll/Yaw, NKF6.Pitch/Roll/Yaw, AHR2.Pitch/Roll/Yaw).
But crucial is what @tridge determines.
