Servers by jDrones

Plane 3.9.2 stable release

(tridge) #1

The ArduPilot development team are delighted to announce the 3.9.2 stable release of the ArduPilot plane code. This release includes a number of small but important fixes over 3.9.1.

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

Happy flying!

(Rolf) #2

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:

Regards Rolf

(TG) #3

Had an issue like that today. Same version. Suddenly no response from my input. The plane fall out of the sky.

(peterbarker) #4

@Rolf - what sort of battery system are you using? This graph is extremely unhealthy if you’re using 3S LiPos:

@Mr_Green Got logs?

(Rolf) #5

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

(Yutao) #6

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?

(tridge) #7

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:

the POWR log shows the power on the server rail sometimes went outside the backup power limits:

when POWR.flags goes to 33 it means servo voltage is outside acceptable range to act as a backup supply.
the big problem was the pitch estimate, which was clearly way off:

the question is why is it so far off? The accels and gyros match between the two IMUs.
One clue may be the bad compass:

a bad compass can affect attitude in some cases
the EKF and DCM disagree strongly about yaw:

that yaw disparity will cause the EKF to apply the GPS velocity corrections incorrectly, which can badly affect attitude estimates.
Right at the end the EKF did give up, and control was handed over to DCM. It was too late to save the plane though:

Overall I think the crash was caused by a combination of bad compass and bad airspeed. The EKF relies on looking at consistency of inputs. Both airspeed and compass were badly off, and that got the EKF state badly out of wack with reality.
I don’t think it’s a bug, it is just a corner case that a statistical filter like the EKF can’t handle (ie. it got bad sensor data, and it misinterpreted it).
I’d also note that you shouldn’t really have arming checks off. I don’t think that made a difference in this case, but it certainly does in a lot of cases.
Cheers, Tridge