Looking at the changes from v3.8.4 to v3.8.5, I see a couple interesting possibilities. I’m not sure how to tell from the logs if the Safety button deactivated in flight. The second issue has similar keywords to my incident like “fixed wing flight”, “QSTABILIZE” and “zero throttle”. Again this is simply speculation as I gather data.
Fixed an issue where the external safety button can activate in flight on some boards, causing them to crash. A new parameter BRD_SAFETYOPTION is added which controls the behaviour of the safety button. The default is to de-activate the safety button when armed.
Fixed a bug when switching from fixed wing flight to QSTABILIZE in tailsitters which could cause zero throttle for 2 seconds. Thanks to Marco for reporting this bug.
Sometimes you gotta break some eggs, right? I’m getting slower to react in my old age so I will need to test fly higher next time…the problem is I can’t see that far!
Yes, that’s correct, CH2 is elevator and CH3 is throttle. However, one of the biggest changes in Plane v3.8 is the change from RCn_* parameters to SERVOn_* parameters. In other words, you are logging my transmitter inputs, not the flight controller outputs to the plane. So channel 2 and 3 are showing my instinctive reactions to slam up elevator and throttle down just before the crash. It had no effect.
No problem, keep looking. I think where you are getting hung up is on the definition of the “event”. What you are looking at is my last ditch effort to save the plane…long at the initial cause. If you plot CTUN ThrOut with your graphs, you will see the start of the cause when the forward flight motor is shut down which drops the speed and altitude. In my graph above, the CTUN ThrOut (Red) dropped to zero during FBWA mode which appears to have caused the crash.
In your graph, the change to QSTABILIZE mode dropped the Vservo about 0.1 to 0.15 volts. This was likely due to the crash but I can’t tell the exact time frame. As for the ailerons, once in QSTABILIZE mode, they will get yanked around as the plane tries to level itself.
I think your issue stems from your pitch tuning – you probably need to run an autotune for pitch or there was something wrong with your CG.
Your demanded pitch is near zero and your plane continued to dive. That’s the problem before you attempted a transition to save the plane. I’ll look into it more later.
Thanks for taking a look! I took your graph and added the “event” parameter called CTUN ThrOut. I consider anything after the “yellow” forward flight (FF) motor dropping out as an effect of the event. In other words, when you are flying just fine in FBWA mode and the FF motor stops, it is like a domino effect. Why did my FF motor stop just as I turned into the wind when I needed it the most? Q_ASSIST_SPEED was set to 0 as recommended for the first flight.
I don’t have my graph capability at work so I can’t tell the time difference. I suspect the time is longer. The current spike in QSTABILIZE mode is from the quad motors coming on before the crash. My emergency bailout procedure is to change to QSTABILIZE mode…although I was too slow this time to save it.
The forward throttle goes low when you go into Qstabilize - because that’s a quadplane mode, and it’s expected to hover, not continue in forward flight. There’s nothing wrong with that.
The forward motor did not stop when you were in FBWA. In fact, the throttle staying at 70% is probably what caused the rapid loss in altitude when your pitch got lower and lower. Switching into Qstabilize unfortunately did not recover. That may be for a number of reasons, but most likely because you had a ton of downward velocity and very little time and altitude for qstabilize to add enough throttle to recover. To get full thrust during the qstabilize, you probably should have given even more than 70% throttle. Who knows though if your battery/power module are rated past 100A.
Thanks for the detailed graph. I may have been misreading my initial graphs. I wish we had gotten video of the rapid descending, which happened before I switched to QSTABILIZE mode. I was caught off guard because it was flying quite well. I had pretty much finished the right hand turn, and as it approached the field it went down at about a 45 degree angle. It wasn’t until it was nearing the ground that I reacted to turning the Taranis 6-position knob back to QSTABILIZE mode.
I will try to graph the RC5 (or RC8) input to compare my Taranis knob switch to QSTABILIZE mode with the graphs. Like Paul suggested, maybe it transitioned to QSTABILIZE mode on its own. Even though Q_ASSIST_SPEED was set to 0, I think Q_ASSIST_ANGLE was set to the default 30 degrees, so maybe it caused the quad rotors to kick on in the last turn into the wind…causing the crash.
I matched RCIN C8 to the CTUN ThrOut and they are in sync. So there was no early change to QSTABILIZE mode and this can also be seen in the green section of my Flight 1 kmz image below. So the real issue was pointed out by Nate in his red circle above which happens on the yellow section before the green on my kmz image. After flying almost a full figure-8 pattern, the wing drove into the ground.
