Hi all, I’m looking for help diagnosing a crash in TAKEOFF mode.
Airframe: AtomRC Swordfish (1200 mm), V-tail. With 4S 21700 Bat. FW: ArduPilot Plane 4.6.3 Launch: then TAKEOFF/AUTO TAKEOFF enabled with a hand throw, . Throttle ramps to full as expected.
What happened:
After enabling TAKEOFF mode and throwing the plane, motor spools and the plane climbs normally to about ~8 meters.
Then it then goes nose-down and crashes.
If I don’t use AUTO TAKEOFF and instead launch in FBWA, I can manually pull up and climb normally (so basic control direction and thrust seem OK).
What I’ve checked:
Control surface directions in FBWB/FBWA are correct (surfaces move against aircraft motion).
V-tail setup appears correct.
No obvious stall behavior during normal manual flight;
First of all, thank you very much for taking the time to dig into the log — I really appreciate it.
As requested, I’m attaching a second log from a flight two days before the crash.
In that flight:
I also launched using TAKEOFF mode at Time Since Boot = 05:15.000
The plane again did not climb properly in TAKEOFF mode
I immediately switched to Manual to avoid a crash
After that I tested FBWA / FBWB / RTL, and the plane responded normally in all those modes
So this behavior (poor climb in TAKEOFF) already existed before the crash flight — the only difference is that in the second flight I didn’t switch modes in time.
Additional details
In this flight, TKOFF_DIST = 0, so I expect it to loiter over the launch position after takeoff.
During launch, it does loiter near the launch point laterally.
However, altitude only climbs slightly and then stops increasing — similar to the crash log.
I had to switch to Manual because it was not maintaining climb.
Observations from both logs
In both logs, during TAKEOFF mode:
ATT.Pitch never reaches ATT.DesPitch
The aircraft does not seem to track the demanded pitch during TKOF
Later, when I switch to FBWA/FBWB, ATT.Pitch tracks ATT.DesPitch normally
So it seems the issue is specific to TAKEOFF mode behavior, not general control authority.
Sensors onboard
Airspeed sensor installed and calibrated
Rangefinder installed (6 m max distance)
If there are specific fields you’d like me to graph (TECS, NKF, pitch limits, throttle demand, etc.), I’m happy to provide screenshots.
Just an idea after looking to your second log.
During Auto Takeoff Mode our throttle goes to maximum, after you switched to manual and later the throttle never reach this high value. So it could be that your props goes simple to stall during your launch, so it don’t produce forward force, on switching to manual the throttle goes down and the prop comes out of stall than you rises throttle slow but not never to maximum
The reason you couldn’t fly without crashing during takeoff is because the SCALING_SPEED (15 m/s) was much lower than the actual flying speed (up to 40 m/s). The speed parameters also do not reflect the actual performance (AIRSPEED_CRUISE,18 AIRSPEED_MAX,22 AIRSPEED_MIN,12) .
In the second log file, you have even lower values (AIRSPEED_CRUISE,12 AIRSPEED_MIN,9).In autothrottle modes such as FBWB and RTL at low cruising speeds, the throw of the control surfaces has been strong enough.
Adjust the speeds, especially the SCALING_SPEED and fly another autotune. If you prefer lower cruising speeds, you can set TKOFF_OPTIONS bit 1 since you have an airspeed sensor: this will cause TECS to take over throttle control in takeoff mode or increase TKOFF_LVL_PITCH or decrease TKOFF_THR_MAX.
Thanks for your kindness and for taking the time to look into my logs — I really appreciate it.
I also want to explain why I’m asking again: I spent some time thinking about this overnight, and I’m mainly trying to be sure I won’t repeat the same crash on the next launch. So I’d like to understand the mechanism a bit deeper before I fly again.
I agree with your point that my SCALING_SPEED looks too low and my AIRSPEED_* values are likely not correct for this airframe (the Swordfish can accelerate quickly in TKOF).
One detail about my setup/log interpretation:
This is a V-tail. In my configuration, when C6 < 1500us and C5 > 1500us at the same time, that combination corresponds to “ELEVATOR UP” (nose-up). I confirmed this with a successful flight log and by observing the surface motion.
During TAKEOFF:
Airspeed ramps from near 0 up to ~35–40 m/s, so it crosses SCALING_SPEED and also spans the AIRSPEED_MIN/CRUISE/MAX region.
From my understanding of the ArduPlane code, the speed scaler (based on SCALING_SPEED / airspeed, with limits) affects the PID controller scaling. When airspeed is below SCALING_SPEED, the scaler is > 1, so the controller response should be stronger (more surface movement) to compensate for low dynamic pressure; when speed is high, it should reduce response to avoid oscillation.
However, what I’m seeing in the TKOF logs/charts is:
For essentially the entire TKOF segment, ATT.Pitch stays below ATT.DesPitch (never reaches the demanded pitch).
But the elevator outputs (C5/C6) go from “down / weak” toward only a slight “up” as speed increases (C6 only gradually moves below 1500us).
I expected the opposite behavior: at the very start (low speed + large pitch error), the elevator should command a relatively strong nose-up (especially if the scaler > 1 when below SCALING_SPEED), then back off as speed increases. I draw on the chart with red line by hand to show what I expect C6 output
I know. Just to be clear, I only showed C6 to illustrate the amplitude of the deflections.
Correct.
That’s incorrect. After you threw it, the plane did indeed correct for pitch deviations from desired pitch. See the red circle in the graphic.But only while the plane was flying slowly.
Did you set the PID yourself or use autotune? Since there were no more rapid pitchchanges, the slow integral component is now mainly responsible for the control. This indicates a poor PID setting. (If you had thrown the plane from a tall tower, it would have shot up into the sky for a moment and then, being far too sluggish, would have nosedived again)
One more question: Did you change the mixer (MIXING_OFFSET,-70) in favor of the rudder or elevator function?
As I said, I would fly Autotune with appropriate speed parameters. I would have a colleague throw the plane for me on the next flight to be on the safe side until the settings are correct. The TECS parameters should be set after Autotune. For functions with autonavigation, such as RTL and also TAKEOFF at the end of the loiter circle, the radii (e.g., WP_LOITER_RAD) should be appropriate for the speed. You have a WP_LOITER_RAD of 60 meters. At 40 m/s, you would have needed a bank angle of almost 70 degrees with a radius of 60 meters to be able to fly such a tight radius. Arduplane would not have flown the turn so tightly but would have tried to keep the radius to a maximum bank angle of ROLL_LIMIT_DEG 45. General note: In windy conditions or with poorly adjusted PID values, an angle of 50° or more can quickly occur at the peak, which is particularly problematic for wings without rudders if the radius is increased by the navigation logic.
