I recently built my first RC plane, a Nano Goblin that’s very heavy for its size (460 g, while most builds are around half the weight). I threw it in the air in FBWA mode, and maxed out the throttle. It flew fine for the first few seconds, accelerated to 80+ mph, then rolled rapidly to the left and kept on spinning until it crashed several seconds later. Looking at the log, I see that Ardupilot did try to correct the roll, but it wasn’t enough. The question is, what caused the roll in the first place, and why was Ardupilot unable to correct it? Is there an asymmetry in the airframe that causes a torque that the elevons aren’t strong enough to correct at high airspeeds, such that there’s nothing Ardupilot can do? Or are there parameters I could change that would have avoided the crash? Here is the log file: 2024-08-11 16-16-34.bin - Google Drive
EDIT: The potential cause discussed in this post is not likely the actual root cause. Likely a case of seeing what I wanted to see based on very limited data. Leaving the text intact, as it does discuss a common user error. See continued discussion below.
If we zoom to the moment of divergence, we can see evidence that you likely have a problem with RC channel reversal vs servo reversal:
Desired roll goes almost exactly opposite actual roll until things are out of control, which likely indicates that you misconfigured your RC channels vs elevon servo output. I see you have the pitch channel reversed, which is a good indicator that things may be a little out of kilter (reversing the RC pitch channel on ArduPlane is usually not required).
This link describes a preflight safety check that will catch that kind of error. It’s a common mistake for those with an RC-only (no autopilot) background to simply visually make things work in manual mode without double checking that the autopilot is “aware” of the proper control surface direction.
My analysis could be incorrect, as the log is brief. It would be quite telling if you did not complete the checks described in the link I shared.
Control authority would’ve been ever-increasing, as speed continues to build until its demise, so there was no stall entry/subsequent dive. At some point, control surface loading may overcome servo authority/torque as speed increases, but I don’t think that’s causal here.
FURTHER EDIT:
Actually, aerodynamic force did likely play a role in control surface authority, but not in the way that I described above. More likely (as you’ll see below), the high speed contributed to a control reversal due to wing flex as a consequence of foam construction.
did you its maiden in manual mode first ?
I performed the preflight safety check many times, and the control surfaces move the right way in FBWA mode when I move the plane.
I thought I had an answer a moment ago, but I’m still a bit stumped, and I suspect my initial analysis was not correct. I wonder if a control surface jammed (physical jam, servo failure, servo power loss, etc)?
@yak-54 asks a valid question about the maiden flight - jumping right in with FBWA may not be the best course of action. However, the log seems to show a total lack of response to both autopilot and RC input at the point where the left roll begins, and that may well have occurred regardless of flight mode if a physical issue was present.
Here’s some more data that deepens the mystery: I flew the plane again today, and the same thing happened again after 4 minutes of successful flight. I took off in FBWA mode, did a successful autotune, and then put it in RTL mode. The plane came back to me, but then the autopilot inexplicably decided to max out the throttle, even though the airspeed was already 23 m/s and I had AIRSPEED_MAX set at 22 m/s. The plane entered an uncontrolled leftward roll (same direction as on the maiden flight). I put it in FBWA mode and reduced throttle to see if it could recover, but no luck; it quickly smashed into the ground. Next time, I’ll need to set THR_MAX to 75% instead of 100%. Log file of the 4 minute flight: long_flight.bin - Google Drive
Here’s what the plane looked like after the crash. I couldn’t find the missing vertical stabilizer or elevon piece, and I don’t know how they came off. Initially I thought they came off in the air and caused the crash, but after looking at the log and noticing how this accident seems so similar to the maiden flight, I think they probably came off during the crash. I was also thought that the GPS unit on the right breaks the symmetry of the wings and might cause a roll, but shouldn’t the added weight and reduced lift cause a rightward roll rather than a leftward roll?
@yak-54 No, I never tried manual mode. I read in the documentation that FBWA is best for inexperienced pilots, and I had precisely zero experience. Do you recommend manual mode first?
Your log shows a very steady pilot commanded throttle with some output oscillation as the issues begin to occur. I see no autopilot “decision” to saturate the throttle, and the speed only really increases as the dive begins.
I don’t have any firm conclusions, but bad wiring would explain the inexplicable. Maybe a bad ground? Check your soldering and wire condition.
I see that CTUN.ThO went to 94% at the same time the leftward roll began (time 07:41.8). The plane was in RTL mode, so I thought the throttle is automatically controlled? I certainly wouldn’t have maxed out the throttle manually after what happened on the maiden flight, especially because it was already flying really fast (ground speed of 30 m/s, which is what I was looking at while flying).
I think the throttle modulation is a consequence of the extreme attitudes, not a cause. I’m still betting on some physical anomaly, possibly electrical.
@Allister is fairly adept at analyzing Plane logs, and I wonder if he’d take a look.
Both crashes were caused by inappropriate parameterisation of the fast little aircraft.
During the first flight, you gave full throttle all the time, with the result that the little thing soon accelerated to 30 m/s ground speed without you having carried out an autotune beforehand.
I suspect that the first crash resulted from a control reversal due to excessive speed of the flexible control surfaces in connection with the bad PID tuning that has not yet taken place.
Unfortunately, you did not perform a successful autotune on the second flight, even if the autopilot reported this. But AIRSPEED_CRUISE was parameterised to 12 m/s, TRIM_THROTTLE to 45% and SCALING_SPEED to 15 m/s. You were then significantly faster than 15 m/s during autotune, and it also misses systematic rudder deflections from you in FBWA. See: Automatic Tuning with AUTOTUNE — Plane documentation. It would have been useful if YOU had flown a few laps with the settings first to test whether the aircraft reacts spontaneously to strong control surface deflections. Then YOU would have realised that the settings were simply bad (and could not have been due to the incorrect adjustment of the speed parameters)
You then immediately switched to RTL, i.e. a mode with autothrottle, with completely unadjusted TECS values, power and speed parameters, poor PID values, which in the end led to a crash due to accumulating P values.
I hope that not too much has been broken so that you can start again with the WIKI above
Rolf
I recommend a more suitable plane. The goblin is going to be way too fast for someone who hasn’t flown fixedwing before. Flying wings like this are very sensitive to center of gravity position, and control throws. They go from flyable to rubbish in only a few mm, and with little warning. The best flight controller in the world can’t correct a plane that is not mechanically setup well.
Looking at the second log I am going to agree with @Rolf , the plane was not sufficently tuned. The plane was out of control, probably a result of an elevon failure
I suspect that the first crash resulted from a control reversal due to excessive speed of the flexible control surfaces in connection with the bad PID tuning that has not yet taken place.
That’s my best guess too. Can PID tuning prevent control reversal from causing a crash, or is limiting airspeed the only option?
What do you suggest I do for the next flight? I assume that I should set AIRSPEED_CRUISE to 15 m/s, SCALING_SPEED to 20 m/s, and THR_MAX to 75% (to avoid control reversal at excessive speed)? In my defense, the autotune documentation never mentions AIRSPEED_CRUISE or TRIM_THROTTLE, and the name SCALING_SPEED made me think it was just a normalization factor.
It would have been useful if YOU had flown a few laps with the settings first to test whether the aircraft reacts spontaneously to strong control surface deflections. Then YOU would have realised that the settings were simply bad (and could not have been due to the incorrect adjustment of the speed parameters)
The PID parameters stopped changing at 06:06, and I only switched on RTL mode at 06:42. So I did fly it myself a bit, and it felt very sluggish, but I had no idea whether that was normal or not because I’ve never flown a RC plane before. I’ve put in quite a few hours in a flight simulator (PhoenixRC), but should I expect FBWA mode on a real plane to fly like a completely different plane in manual mode in Phoenix? I had no idea, so I had no idea whether the parameters were good or bad.
You then immediately switched to RTL, i.e. a mode with autothrottle, with completely unadjusted TECS values, power and speed parameters, poor PID values, which in the end led to a crash due to accumulating P values.
Could you explain this a bit more? What are all the TECS, power, and speed parameters I should be adjusting? What are accumulating P values? Thanks for your help.
when autotune finished you must land without changing any flight mode or anything and you must disarm your plane and new PIDs will be saved. So you switched to RTL after autotune and everything you did in autotue was deleted. They meant it.
Landing with autotune still active only applies to Copters.
Thank you very much @rolf and @Allister for weighing in where my knowledge is weak. I suspected a simple root cause, and it seems there is one, but I clearly missed the boat!
Of course not, it is due to mechanical insufficiencies of the foamies with pliable control surfaces under air flow and G loads.
As @Allister mentioned:
And familiarise yourself more with the really very good and profound wiki.
Yes, an aircraft reacts completely differently in FBWA mode and in manual mode. It’s all in the Wiki, don’t you have a friend who has model flying experience and can help you with the first few steps?
Arduplane can do a lot, but unfortunately does not yet have a flight instructor mode 
…
A large Trainer.
Check out this guy’s youtube channel: https://www.youtube.com/@bonafidepirate
If you’ve never flown a plane before then look for something slower than a goblin. The simulator is a good start but you still don’t go from the sim straight to the rocket ship without some practice. Some of the twins like the Swordfish might be a better choice. Planes don’t slow like quads. You can fly a fast quad slowly and take time to get used to it, but fast plane needs to fly fast. If you try to fly it slowly it will either stall or become so unstable it’s going to be difficult to control. FBWA will try to stabilized the plane, and prevent stalls, (and when tuned it can do a really great job of it!) but if the plane does stall FBWA will actually make the situation worse and almost impossible to correct if you’re not experienced with flying fixed wing.
I have crashed my go-fast wing more times than I can count. But it’s a Crash Test Hobby Wing and built for that. Things happen fast on those.
Of course not, it is due to mechanical insufficiencies of the foamies with pliable control surfaces under air flow and G loads.
Sorry, then I’m still confused. If the first flight crashed because of control reversal, why wouldn’t the same thing have happened on the second flight when the airspeed reached similar values? And what’s the relevance of bad PID parameters, if good PID parameters couldn’t have done anything about control reversal? Also, why did the autopilot decide to fly so fast, if my AIRSPEED_CRUISE was lower than it should be (12 m/s) rather than higher?
From the wiki:
In the automatic throttle controlled modes, AIRSPEED_CRUISE is used for the target airspeed if an airspeed sensor is being used, while TRIM_THROTTLE will be set for the average throttle value if no sensor is used.
ARSPD_USE is set to 0, so that means the plane is going to run the trim throttle setting, in this case 45. Basically, that AIRSPEED_CRUISE parameter doesn’t do anything in this configuration. You need to set your trim throttle by testing and tuning the airplane.
I notice that you have set 9 to 22 m/s for min and max. I’m not really sure a goblin would fly that slow, unless it’s in Alpha. And looking at the log, 22 looks a little too slow.
When you switched to RTL the plane is going to try to climb to 100m and turn towards the home location. Both will cause an increase throttle setting (without calibrated airspeed) as a means to reduce stall risk, as risk of stall increases naturally in a turn. All totally do-able functions, however again, without proper tuning of the plane there’s no guarantee the plane will do it.