Plane overturned and crashed when switched to loiter

I need some help understanding the cause of this crash.

Setup - Arduplane 3.5.2, Pixhawk 1, X-UAV Talon, 3dr airspeed sensor and compass/GPS

Description of Crash - Plane was flying well previously on the same day. I disabled ARSPD_ENABLE to see how the aircraft flies without an airspeed sensor. I changed the parameter and launched the aircraft in FBWA. The aircraft flew fine, I climbed to about 100m and switched to loiter mode from my transmitter. The plane rolled right and continued to roll beyond the limits (LIM_ROLL_C = 4500).

As it approached close to 90(all within a few seconds), I switched back to FBWA to try and recover the aircraft. By this time, the aircraft had rolled over and was inverted. It had also pitched down during this process and was heading towards earth fast. All attempts to recovery failed and the plane crashed head first into the ground.

My analysis from the logs:

  • It seemed that the Pitch tuning in the aircraft was off. I flew a grid and did several low pass manoeuvres. When I looked at the logs, I saw that the ATT.DesPitch was very high and never followed the actual ATT.pitch. It was as high as 45 degrees during the auto grid. The plane flew the grid well, I found no issues during the flight. What could be the possible reasons for this? My CG was properly positioned. The aircraft had been previously tuned. I had flown just a couple of days earlier and the pitch response in the logs was as expected.

  • When I switched to loiter, The aircraft rolled beyond the limiting roll angle. What could be the cause for this? I also noticed that the pitch was negative.

  • The throttle output was high during loiter. The plane demanded 100% throttle. Is this normal behaviour?

  • Synthetic Airspeed as estimated by arduplane seemed natural. How does using the airspeed sensor affect the flight behaviour? It is worth noting that ARSPD_USE was still set to 1, only ARSPD_ENABLE was set to 0 during the last leg of the flight.

I would love to hear your thougts on this crash.

Edit : forgot to attach the dataflash log. Here it is


Did anyone have a look at this? Any help will be much appreciated!

There are probably plenty that have had a look at your logs but like me, they cannot clearly see any particular cause.
I am still finding my way around plane logs so all I can suggest is that manual mode might have produced better results.
Sorry, I know that’s not helpful.
Did you do a tuning flight in manual mode then re-calibrate the radio?
I too noted the large variance between Des and real
This is just a close up of what I am assuming is the moment of the planes demise.
Not sure of the significance of this but all the PM log entries stop at 2865000??

Thanks for the reply, Mike!

The reason there’s a short period when the mode switches to manual mode is because of the transmitter. I have configured a three-way switch and a two-way switch to provide 6 flight mode toggles. Whenever I change the mode, it switches to manual (probably because of the way the PWM outputs are mixed) for a very short time before switching to the desired mode. This has not caused any issues so far.

But in this flight,I did notice this -

The autopilot tries to correct for the excess roll during loiter. CH1 output is steadily decreasing. When switched to manual, the output was in the opposite direction for a short while which added to the already excess roll. What I don’t understand is why it rolled beyond the limits in the first place.

Did you do a tuning flight in manual mode then re-calibrate the radio?

The plane was tuned long before this flight. I hadn’t recalibrated the radio since.

Not sure of the significance of this but all the PM log entries stop at 2865000??

I noticed that the PM log entries are logged at a much lower frequency than other entries. Here you can see that the plane had crashed before the next entry could be logged. Not sure what the PM log entries correspond to though.

Hi Nihal,
It is propably too late to reply to your post, but I have found it now struggling to explain several crashs like yours. In my case, switching to RTL put the plane once with a 90º roll (well above the maximum allowed of 45º)and entered an spiral of death at full throtle to the ground. After a lot of research in these forum, I have found that there is a bug in some versions of Arduplane (including current stable 3.7.1) that reset the integral part of the PID controls of pitch and roll on mode changes, and this put the PID loop control in a wrong state that could result in total loss of control. Looking at your logs, It is clear that the integrator is reset to zero on mode changes:

What it is not clear for me is the effect of the brief time on manual mode that is “inserted” between the mode changes due to your transmitter configuration.

I have installed current beta (Arduplane 3.8beta5) that have the bug fixed and everything is fine now, I can change to any mode (RTL, Loiter, …) and the transition is as smooth as it should be). There is several other posts in this web with simmilar problems attributed to this bug, but I am not sure if it could be already present in Arduplane 3.5.2.


1 Like


Thanks for looking into this. Seems I’ll have to switch to 3.8 beta. I don’t understand how this reset affected my flight just this once and never before. I had flown the same plane with the same params and firmware for a little under a year for now.

The mode switch anomaly from my transmitter was due to an incorrect setup during the logical switches to create 6 modes which added a delay. I have fixed that issue now. Admittedly, this delay in switching did not help things in the crash.

I hope some of the devs can shed some more light on this issue. eg. Why this reset causes crashes only sometimes?