HI All,
My VTOL (with a 3.5m wingspan) suddenly crashed after 35 minutes of flight. Are there any common reasons for this?
Log file: 00000083
Greeting
It’s really strange; I’m still not able to understand what happened. I’m looking for a developer’s help to find a common cause.
Furthermore, during the mission between 47:10 and 47:20, the plane suddenly loses altitude. The throttle fails to respond to correct this, and the pitch and despitch are in opposition to each other, as you can see in the graph.
Your screenshot looks like a servo failure (or linkage defect) on the pitch axis.
Did the tail survive the crash so you can check?
1 Like
Thank you, YupsUAV, for taking a look at my message.
Yes, the tail is in good condition and the servos are good.
But even if there is a problem, normally the q_assistance should respond to a loss in altitude or speed, right?
Best regards,
Most of the flight the plane was in a loiter circle, and it looks to me like it was a reasonably windy day because the ground speed and bank angles change significantly as it goes around the circle. Generally pitch tuning does not look good. Often a lag between the desired pitch and the actual pitch. This could also be a sign that the center of gravity is off, and given the continually rising i-term, the pitch trim is not correct.
There are wild pitch and airspeed changes through out the flight. About 20 minutes before the crash the plane went through an incident similar to the crash, however it recovered. In both cases the elevator pitch was commanded to full. Q-Assist triggered many times in the flight to try and save the plane.
If the control surfaces are working and you’ve eliminated mechanical problems, I would look at:
- Overall weight - reduce weight.
- Center of Gravity - Verify it’s correct.
- High wind conditions relative to the loiter radius of the flight. Don’t try to loiter in such small circles in high wind conditions. Increase the loiter radius.
- Improve the pitch tune and trim.
It looks to me like the plane stalled. High bank angle, high demanded pitch, low or oscillating airspeed. Ardupilot is great at preventing stalls, however if a stall does happen it cannot stop it and it will actually accelerate the stall. In this case i think the plane was on edge for much of the flight given all the times Q-Assist triggered. A gust of wind at the wrong time may have just been enough to push the limit to a stall that Plane couldn’t stop.
1 Like
Thankyou Allister for your important details,
The weather was good that day, and the wind wasn’t severe.
Furthermore, the frame is an EV350, so it is well-constructed and the CG was checked. This plane also flew very well for about a year. And that’s why I keep the ancient version of the firmware.
Best regards
Is there any way to confirm the FC (Cube Orange+) didn’t reboot unexpectedly?
Your logfile is to huge for me to download but if it is continous over the whole flight the FC didn’t reboot. After rebooting you will see same messages as after the initial booting. Also you will find a gap in the time information.
1 Like
I think @Allister nailed it more or less accurately. A stall is the most likely reason. Can not tell why Qassist didn’t catch it.
Why don’t you have an airspeed sensor? Judging by the GPS Groundspeed, you where flying at approx. 26m/s in average. Windspeed approx. 11m/s, thats a LOT! The wind wasn’t that calm, the plane max speed (per round) changed between 30m/s and 42m/s, min speed was as low as 10m/s.
The max speed was increasing in the last two rounds and even more before the crash.
My guess is: The plane came into a stall when it got the gust from behind, as the effective airspeed became critical (42 m/s groundspeed - 26m/s cruise speed) = 16m/s airspeed. This matches exactly the manufacturers stated stall speed.
I am sorry for your loss! Please use airspeed (dual!) in the future for plane which is this expensive 
Thank you, Juergen-Fahbusch, and YupsUAV for your remarks i’ll take this in consideration.
The graph shows that data logging stopped at 100m altitude and a speed of 21m/s. We suspect a short circuit forced the flight controller to reboot, and by the time it recovered, it was too late to save the plane. Since the FC is now functional, how can we confirm this hypothesis?
Best regards
Your file to download is 00000083.bin and data is recorded including impact. Your graphics show a LOG_82_2025-10-29-20-10-40-32.bin ???
Rolf
Sorry, you are free to have your own hypothesis, but i don’t see any proof for this.
Look how many QAssist saves you had by selecting “MSG” in the MissionPlanner dataview. The screenshot only shows a fraction, i am too lazy to count it as this is at least a medium double digit count.
Immediately before the impact, the plane did a another “successfull” transition. But it relies on synthetic airspeed which is too far off.
And the synthetic airspeed switched back to DCM several times, guess because of QASSIST.
Thank you, Rolf and Yups UAV, for your remarks. You are correct, and I will incorporate your suggestions.
Best regards
On your graph I can’t see a reboot of the FC. Also if the FC reboots, I think, it will start a new logfile.
From my point Rolf’s thesis makes more sence
The log I looked at did not show any sign of a re-boot or shutdown in flight.
Yes, that’s correct. The log was retained until the point of impact.
It’s truly unfortunate, and I hope this situation can be prevented for others.