I had multiple success flights, but last one went wrong. I launched plane using auto takeoff mode, landed it and then launched using auto takeoff again. This time plane climbed about 13m and then suddenly pitched down and crashed into the ground.
Plane is rebuilt now, but before flying again, I would like to understand reasons and how to avoid this from happening again.
What I was able to found is that AHR2 is indicating positive pitch angle during the dive, while pitch was actually negative (thus the dive). Another parameter which correlates with start of the dive is NKF4.GPS number which increases right at the moment when altitude starts to drop. I also noticed some strange behaviour while plane is sitting still on the desk: virtual horizon which indicates plane attitude starts to move around at the moment when there are few GPS sats found, but not enough to get a full lock. Virtual Horizon stops moving when it finds more sats.
Ardupilot version was 4.0.7
Omnibus F4 V3 Pro FC
Here is the log. Second activation of TAKEOFF mode indicates flight where this dive happened. Altitude cruve shows the rest.
I would appreciate any advice on why this happened and what changes can I do on my configuration to avoid this faulty indication of attitude.
Battery voltage sags to below 10.5 (<3.5V/cell). Suggests poor battery condition and that you probably weren’t getting full thrust.
Looking at the first flight, there is a great deal of pitch oscillation and the elevator spends most of the time at ~1600us (higher than normal). Since all the servo trim values are default I’m assuming the plane hasn’t been trimmed or tuned yet, and/or the longitudinal C of G isn’t correct. I would verify the C of G is correct, and also spend some time with the PID tuning.
During your second takeoff the plane was attempting to climb at a high angle, when there is a sudden nose up pitch movement, then the airspeed drops and the plane stalls. You know the rest. Because the change is so dramatic and sudden my guess is either something shifted, perhaps the battery moved back or something in the airframe let go like the elevator or elevator servo.
The battery sagged on both takeoff’s in a very similar way. The battery could be better but should not crash the plane.
One major difference between the first and the second (unsuccessful) takeoff is the unintended(?) deployment of the flap (AETR.Flap).
Hope this helps.
I’m sorry, I think you misunderstood my comment. I wasn’t suggesting the battery caused the crash, but I wanted to point out it wasn’t making things better. I’m more interested in the sudden 10 degree pitch up, followed by the stall.
You bring up an interesting point about the flaperons. They were engaged during the first landing, and never changed state. The right flaperon (Servo4) is at full deflection leaving most of the roll control up to the left flaperon. The small amount of additional lift may not be enough to overcome the additional drag.
I am really appreciate your responses!
Battery is 18650 (samsung 30q; 3x11mOm IR) so sag is expected, but I believe its within acceptable range.
Indeed I left flaperons on. But they have no significant impact on controls, also it would caused a problem at very begin of the climb I believe.
CG might not be perfect, I actually just learning to read logs and do trimming/adjustments accordingly, but it could not be the reason for the crash as I do multiple climbs in same configuration before.
One important detail which I missed is that I was not looking at the plane the moment it changed its attitude to nose down. But I saw the moment when I goes down with nose down.
AHR2 readings in comparison with altitude implies that plane got down with its nose up, which was really not the case. Nose was looking down. This makes me believe that something caused incorrect attitude indication (like GPS which I mentioned). Do you have any comments regarding this idea?
Also, plane has high almost 1 to 1 thrust to mass ratio. I doubt it would stall even at 50deg pitch up.
Edit: actually after properly scaling graphs I started to see what @Allister refers too. I see now that Elevon output (C2) actually was trying to correct the angle, so my ideas about incorrect attitude readings are incorrect. Thank you for pointing me to right direction!
so after failing to find any other hardware issues, I just improved battery holder, which MAYBE in certain circumstances would allow battery to move. And after that I made few successful flights
But there is still one question which actually made me talk about GPS being the reason. Can you tell me if that is normal behavior?
The plane is sitting still. While there are 0 GPS sats locked, horizon is steady. Then, when few sats gets locked, horizon starts to move around, while plane is still sitting still. Then, once GPS is fully locked, the message something like “ekf2 imu1 is using gps” appears and then horizon gets steady again.
The main question is what would happen if GPS signal would degrade to such level during the flight?
This is the normal behavior. Just dont try to start before the
Usually the arming checks avoid this.
To your main question:
Normallty the GPS signal doesn’t degrade so bad in flight. In case of total loss of the GPS the EKF will go on with “dead reckoning”.