I had a catastrophic crash with my Mini Talon today. She had flown beautifully many times before. Before this flight, I changed the autotune parameter from 6 to 7 as I wanted to get a bit more responsiveness out of it. I also set SERVO_AUTO_TRIM to 1 as it was disabled. My plan for this flight was to get a new tune and observe the auto trim parameter behavior. As you can see in the video it appeared to takeoff just fine but then after my turn it just nosed down. I could not regain control once it pitched down. I see in the HUD that I lost the airspeed reading shortly after takeoff. I do not have an airspeed sensor and have flown successfully with the synthetic calculation many times. ARSPD_TYPE is set to 0 in my parameters. I have the log if anyone has the expertise to analyze. I was using a Pixhawk 4 Mini running Arduplane 3.9.9.
Here is the log: https://www.dropbox.com/s/vxnm1twd2j7azwn/00000020.log?dl=0
Like I mentioned on facebook, I am by no means a plane expert but I know a lot about copter.
First thing I noticed is that during the decent(blue is altitude), your elevator servo is being told to oscillate to full throws at a very fast rate (green). Perhaps this was enough to overload your servo rail? It’s tough to tell, but perhaps why you had no control as you were going down.
Your RC link appears good, so I don’t think that’s the issue.
Using your altitude again as a reference(tan line), you can see here where the CTUN.NavPitch is flat and then CTUN.Pitch starts oscillating around it. This tells me that the autopilot wanted to maintain your course, but could not. This makes me think it is a tune or mechanical problem.
It looks like you also had quite a bit of low frequency oscillations in Z accelerometer data during the descent. Maybe this is from the elevator servo moving back and forth so quickly? Or perhaps the flight controller came decoupled from the plane during flight? I do remember a friend of mine having a plane crash in a very similar manner to yours because they were flying low to the ground when the flight controller became decoupled, and he didn’t have enough time to switch to manual to recover.
Hopefully these leads help!
Thanks a lot for taking a look I really appreciate it. I really want to know what went wrong so that I can ensure it doesn’t happen again. So with the first graph you’re saying it looks like my elevator servo is oscillating from one extreme to the other? That is strange. I don’t remember giving those commands. To the best of my knowledge (it all happened so fast), I was making a turn to head back to myself and had a side-profile view of the plane. I noticed it pitching downward at about 15-20deg. I was giving up elevator and not seeing it pitch upwards. I believe I tried to give more throttle in case it was a stall situation. A second or 2 after that it was too low and out of sight and I heard the crash.
I’m wondering if using the altitude as a reference might be throwing you off. The plane struck a tree at about 60-80ft altitude. Perhaps these oscillations were at the time of impact when the wings were torn off? When I found the plane, the battery was still connected and the FC was still powered on so the whole crash was recorded.
The flight controller was still secured to its mounting plate inside the plane when I recovered. The 3M tape was holding it good. I am going to take a closer look at the log. I think the issue first begins right after I make a left turn as shown in the video. That is where I noticed the downward pitch. From that point on I only had about 4 seconds before it hit the tree.
Hi Ed,
Arming check only checks gps (ARMING_CHECK,8). I am not sure if it has anything to do with your crash, but CTUN.Pitch differs significantly from AHRS.Pitch (EKF) from the dive:
From my own bad experience, I would definitely set ARMING_CHECK to 1. See my example-crash: Crash after "EKF2 IMU0 is using GPS" and different AHR2 and ATT Attitude Estimationes
Rolf
Thank you for the response. Are you thinking that EKF was not fully initialized?
That goes beyond my horizon. At the beginning, both AHRS are still measuring identically.probably @Tridge could give the answer.