Hello
After many flights without any problem, I was fortunate to have a crash without any consequence for the plane (talon UAV) that was recovered intact at 17km from home location.
After flying 19m had RSSI problems and because of that a successive Short Fail Safe. I engage RTL - as one can see in the log
On the way back in RTL the plane came down from altitude of 600m to 100 programmed into ALT_Hold_RTL, but do not stop there and continued descending until hit the ground.
After checking the plane this has no mechanical problem. The log does not indicate any mechanical problem. I have seen and reviewed several times the LOG but I can not determine the cause of the crash
Not an expert by any measure, but RTL should use a glide slope so you should get a more or less straight line from 600m to 100m. To crash so far away indicates some other issue.
The log shows weird things with your pitch angle and thus desired pitch angle.
At about 19.5 mins the problem starts when the reported pitch angle goes from +5° to +33°(!), there are fluctuations after that and then it settles at around 26° (nose up) and we can presume the plane did not fly with a 26° nose up pitch as it lost height at a fairly consistent rate. So perhaps the FC came loose/moved or it somehow incorrectly estimated the pitch angle?
Thanks for looking at the log.
Yes I see that the pitch go hi by the time the fail safe (short) starts. I can’t find any reason for that. The battery was in the same place and the FC didn’t move.
The other strange thing is that with that angle of attack the speed drops and the Pixhawk don’t try to compensate with the motor.
The log also shows that in the return trip the wind was hi, because after the turn the airspeed raises.
Why the demanded pitch? Why the stall preventing didn’t make the plane dive? Why the AP don’t request more speed?
Your normal airspeed was ~16m/s however during the RTL it went to 25m/s so it WAS going really fast perhaps trying to regain altitude (note only ground speed would increase or decrease with a wind speed change, not airspeed).
It was also holding the nose up to what it sensed was 30°+ trying to gain altitude yet was still descending so I suspect basically it could do no more. It was going fast and it assumed the nose was high so it held that until the crash.
The big question is: why did it think the nose was pitched up when it clearly wasn’t?
I agree with you, it will be difficult to determine the cause.
The thing that I straggling to understand is why the AP don’t accelerate the motor. I know that the air speed and ground speed was ok, but that was only because the plane was losing altitude. I also agreed that the AP was pitching up to gain altitude, the correct thing to do was give more power to gain altitude
Perhaps I need to raise the low ground speed, or the minimum air speed, that will prevent this from appended again.
Your ARSPD_FBW_MAX was set at 22m/s so it was already exceeding that at 26m/s so that’s why no throttle up.
Changing “Low ground speed” (MIN_GNDSPD_CM) will just increase the airspeed when the ground speed drops below the value set, like when flying into a headwind.
Minimum airspeed (ARSPD_FBW_MIN) only affects the plane when it’s flying slowly so neither of those would help in this situation.
How was your FC attached to the plane? It really looks like it came loose but if it didn’t then the autopilot somehow incorrectly estimated your pitch angle, otherwise it did everything else correctly.
BTW, I see ARMING_CHECK is set to 0, this is generally not a good idea as you won’t see any errors before taking off.
You may want to try befriend and contact one of the developers to investigate the cause further, some like Tridge or Paul Riseborough.
Many thanks for your help with this problem.
The FC is fixed with double tape and is still solid attached to the plane. So the pitch was incorrect calculated after 21 minutes of flying.
Once again thanks for your help in this matter it’s helpful to have someone looking at the same things and make as looking to different things.
I know that I have the arming check disable because I don’t understand why I have the the button (the one with the red light) to enable everything and also need to use the ruder to enable the motor and do the check. I only wait for a fixed green light and then let the plane set quite for about 2 minutes and then push the button.
I was hoping that the developers step in in this discussion and guide as, but I know that this is the previous version 3.2.1 and now there’s a new baby 3.3.0
Graham asked me to look at this old report in the 3.5.2 release posting.
The cause of the crash was a sudden change in the Y gyro reading of the first gyro. Presuming this is a Pixhawk, that means the Y gyro of the MPU6000 suddenly changed by 12 degrees/second. The aircraft was at an altitude of 457meters at the time. The 2nd Y gyro reading did not change (the one on the l3gd20 sensor).
The old DCM code which was being used couldn’t handle this sudden gyro error and instead interpreted it as a large pitch error. The new EKF2 code would have no problems as it would have just switched to the backup EKF, and you wouldn’t have even noticed the issue if you had been flying the 3.5.x series of releases.
As to what caused the gyro to do this, the most likely cause is a known hardware fault in the Pixhawk at the time which was caused by a de-panelling error in the factory. The de-panelling process could damage the MPU6000 in a way that only showed up months later.
Cheers, Tridge
