I crashed my VTOL plane today on its maiden VTOL flight, unfortunately it never made it back. I’d really appreciate help understanding what went wrong.
The airframe is a 3D-printed Stingray VTOL with (X-frame 4 motors). I’ve already done 4–5 successful flights in copter mode only, and everything seemed OK (Qstab, Qhover and Qloiter). I ran Quick Tune, set up notch filters, and the elevons were checked and responding correctly.
Today I wanted to test forward flight for the first time.
I took off and started in QHOVER–>switched to FBWB for forward flight–>then, as the plane started getting further away and I’m still quite new to FBWB, I decided to switch back to QHOVER.
From that point on, I was not able to bring it back. A few seconds later it hit the ground.
Looking at the log, I can see that throttle failsafe was triggered several times, but I don’t understand exactly when this is triggered and why it was activated in this flight. There were also multiple switches to QRTL, but the plane never actually returned. Also see some rc failsafe too
I’m struggling to understand what finally caused the crash. Was it related to the throttle failsafe? A mode transition issue (FBWB ↔ QHOVER/QRTL)?, VTOL motor fail? or something in my configuration?
Firmware: ArduPlane 4.6.3
Flight controller: Matek F743 wing
the .BIN log file is here 2025-12-20 15-48-01.bin
Any insight into the failsafe triggers, mode changes, and why QRTL didn’t bring it back would be very helpful.
Thanks in advance for your time!
Hi Christos,
I’m also unsure what caused the crash, but perhaps we can figure it out together.
First, I’d like to comment on your approach to a maiden transition to fixed-wing flight:
It is highly recommended to try out and adjust QStabilize, QHover, and QLoiter first. Very good!
This was not a good idea for a fixed-wing maiden flight because FBWB already controls the speed and climb/descent rate, even though neither the attitude controller was tuned (which is a precondition for the TECS system to function properly) nor the TECS parameters themselves (for maintaining the specified speed and altitude) had been tuned. The maiden transition to fixed-wing mode should be therfore performed in FBWA mode, followed by autotune. Once the aircraft is flying well in FBWA, you should turn your attention to the TECS parameters.
Your RC protocol is SBUS. The reason why the connection breaks after a few meters and the SBUS failsafe flag is triggered has nothing to do with Arduplane. When testing in copter mode, you were probably always close by. You need to find out the cause of the short range before your next flight and fix it.
This is the result of several settings that you did not think through:
1.) You have set Q_ASSIST_ALT to 40 meters. Q_Assist is activated as soon as you fly below 40 meters. However, you start the transition at 38 meters, which FBWB then tries to maintain, with the result that Q_Assist keeps switching on whenever you actually wanted to fly in fixed-wing mode but below 40 meters.
After each failsafe, the system immediately switches to QRTL until the failsafe is terminated: The reason for this is that Q_ASSIST_ALT puts you in VTOL mode below 40 meters, and FS_SHORT_ACTION 0 in VTOL mode immediately switches to QLAND, unless, as you have parameterized, Q_OPTIONS bit 5 is activated, in which case it immediately switches to QRTL.
With hover engines activated by Q_ASSIST_ALT, the aircraft cannot perform reasonable level flight. I can’t say for sure what ultimately caused the crash, but I suspect it was a lack of tuning of the fixed-wing PID and TECS parameters in a flight phase where both were required.
The battery voltage was really getting drawn down during the attempts. I haven’t dug too far, but at those voltages it’s possible in any Q mode there wasn’t enough power to maintain flight. Looking at the commands to the motors, they are at max while the voltage is plummeting.
Thank you very much for your feedback @Rolf and @Allister.
I am off for a few days for Christmas and without a laptop, but when I am back, I will follow your points and dig further into the log. I am a bit concerned about whether the T-motor 4-in-1 pro-II ESC shut off or reduced the current of any of the hover motors, since the ESC temperature reached pretty high values—above 110 degrees Celsius last seconds before the crash and rpm of 2 of the motors seems that goes low and again high too.
Thanks, I see your point. The reason I tried FBWB was that I was afraid the aircraft might stall in FBWA, since I didn’t know how much throttle to apply. I thought FBWB would offer more safety, as the plane would maintain its current altitude and a speed above stall. I had set the minimum speed above stall speed (expected around 16m/s) and the maximum speed to 28, so I assumed that mid-throttle would result in a speed somewhere in between and above stall speed based on how FBWB mode works. I expected the default TECS values to handle that reasonably well. But apparently, this approach is risky.
That’s also a very good point. I indeed flew in copter modes always quite close and never had any RC signal issues. Apparently, when I switched to FBWB, the VTOL flew further away and the issue appeared. I think I’ve figured out why the signal was poor: I had the two monopole antennas mounted almost parallel to the horizontal plane (along the fuselage) to streamline the flow around them and reduce aerodynamic drag, while the receiver’s 2 monopole antennas were oriented almost vertically to the ground. After reading more about this, I realize that this is a very bad idea, since such an orientation between the TX and RX antennas results in minimal signal exchange most of the time. This is definitely something I’ll update in the new build. I’ll also test the copter mode at greater distances first to ensure the signal is stable. Perhaps this could be added as a hint on the ArduPilot page under initial test recommendations?
Yes, I thought that having Q_Assist enabled during the first seconds of FBWB (since I activated FBWB at 38 m and Q_Assist alt was set to 40 m) could be beneficial until the plane, with my pitch‑stick input, climbed above 40 m and Q_Assist turned off. But as you mentioned, with the hover engines running the aircraft cannot perform reasonable level flight, which I didn’t take into account. On top of that, the current draw becomes even higher, and judging from the battery voltage drop, it seems the battery couldn’t supply such high currents, which made the situation worse and ultimately contributed to the crash.
Additionally, the hover motors never disengaged, which not only drew excessive current but also caused the 4‑in‑1 ESC to reach high temperatures. I suspect that this, combined with the other issues, led to the crash.
Right, that’s also a good point. I will add a small fan to the 4‑in‑1 ESC, since it seems to have survived the crash and still works, at least until I replace it. Below is a screenshot of the ESC temperatures, with values reaching up to 110 °C, which is also a bad sign.
Indeed, I had set it this way (with Q_OPTIONS bit 5 activated) to switch to QRTL instead of QLAND, but apparently this was not a good idea. Perhaps if QLAND had been used on the first trigger instead, the VTOL might have survived with only minor scratches in the field during land far away rather than the crash I ended up with.
I used a 6S2P Li‑ion pack with a total capacity of 9000 mAh and a maximum nominal current of around 50 A, which seems to have been exceeded during the flight. So yes, the Li‑ion cells were stressed a lot as well.
Thank you again. I will dig further into the log to learn from it as much as possible and avoid similar issues on the next maiden flight. Meanwhile I started 3D printing a new frame, and I hope that reducing its weight a bit will also help overall.
Looking further into the log, I’m struggling to understand what happened during the last 10 seconds before the crash (around 15:50:08 and onwards). Based on QTUN.AST.in_assisted_flight, the hover motor assist was active. When I check the motor outputs RCOU.C5 to C8 (which correspond to the four hover motors), I see that the flight controller was sending low PWM commands to motors 4B and 1A, while the other two motors were receiving much higher PWM values. These motors are located on the right side when viewed from above in a typical quad-X configuration. So I would expect the aircraft to start banking to the right.
However, ATT.Roll shows negative values, which would indicate a left bank instead. I can’t reconcile these two observations. Am I missing something here?
For reference:
RCOU.C5 = motor 4B (ESC 4)
RCOU.C6 = 2C (ESC 5)
RCOU.C7 = 3D (ESC 6)
RCOU.C8 = 1A (ESC 7).
The ESCs and motors were following the FC’s PWM commands correctly, as confirmed by the motor RPM logs. The RPMs match the behavior of RCOU.C5 to C8, so there is no indication of an ESC or motor failure e.g. due to high current and/or high temp.
A few seconds before the crash, the pitch gradually also becomes negative, meaning the nose was dropping, which aligns with the negative pitch values in the log.
Unfortunately, I don’t have video footage to confirm the aircraft’s actual orientation in the final moments, and it was far away to visually determine which corner dropped first. However, based on the crash the damage mainly occured on the front-right side, so I would expect that the aircraft banked to the right and pitched nose-down into the ground.
Any additional insights or corrections would be greatly appreciated.
Comparing the target roll with the actual roll (e.g. ATT.DesRoll and ATT.Roll) shows that the left quad motors are controlled more strongly than the right ones the more the roll deviates to the left from the target roll. So completely logical.
