Hi guys, I’d appreciate any help in investigating today’s crash with my main ‘FPV cruiser’ which descended into a field for no obvious reason. Previous flights had no issues, and the plane has flown for years. Using AP 4.3.7.
Log: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Things I already noticed:
-
POS Messages become incorrect (jumpy) during flight and are possibly the reason for speed readings going crazy. Ground speed, air speed and wind speed are all showing rather absurd values (up to 300km/h). GPS defective maybe?
-
When I noticed this I decided to abort and turn around. The plane went inverted, then corrected itself, then inverted again → crash into field. Maybe I should have tried switching to manual, but it all happened too fast and I wasn’t prepared for this. Roll and desired roll deviate of course when the inversion occurs, but I have no idea why. Most of all, I couldn’t think of anything that could link this to the POS problem?
It’s unclear if this plane will fly again (pretty beaten up and replacement parts probably no longer available), but I doubt I’ll be flying any plane at all before getting to the bottom of this. Rescuing it from the field was no fun at all, not interested in repeating this anytime soon. 
Thanks for any hints!
please provide a valid logfile (.bin)
Sorry, MP anon log function only creates .log. The file is readable for me in MP log review though. (These days I always check as last year the anon log function was temporarily broken.)
Oh sorry, I use an older MP version (1.3.77) that can not read anon logs
Maybe that version is from when the feature was broken. In any case, why not update it?
Ah ok, I see. Well, in the meantime here’s an image from the KML which shows the deviation between POS messages and the flight path. What strikes me is that the flight path is correct but those POS messages (something I had never heard of before) are off:
I’m wondering if the flight path being recorded correctly actually speaks against GPS malfunction - and if it was other sensors that could have triggered the yellow line deviation?
With a newer version of MP I can see the log. You have enough sats and the reading of gps speed is correct, it seems that your gps module is ok. I can see several drops in EKF3 (yellow). But I don’t know a reason for these drops.
Here’s something similar using plot.ardupilot.org:
There certainly are ‘innovations’ in the area of position but it’s beyond my knowledge to determine where they come from.
Ok, from what I’ve read in the meantime, POS is calculated from 2 sensors: GPS and accelerometers, with GPS (of course) having the most influence on position estimation.
Is it correct that - since GPS data was apparently correct the whole time - the “jumpy” POS reading can therefore only result from accelerometer data? If yes, I’m wondering how a sensor that has only minor influence can cause POS to deviate in such an extreme manner - shouldn’t something like this be caught by these so-called ‘sanity checks’?
It looks like a rather sudden acceleration up to 300km/h and an airspeed of 150km/h were deemed plausible, while the smooth, jump-free GPS position data was discarded.
What would have happened if I had switched to a mode with auto throttle in this situation - probably a sudden stall?
From my (totally non-expert) point of view this looks a bit worrying, so I’d really appreciate some hints on how to explain/prevent this.
Then there is still the second part of the flight, after the turnaround - POS went back to normal, but the plane rolled over and remained like that without correcting itself, then went back to normal, then inverted again. I checked the plane in the meantime and everything except one camera was still working. No mechanical failures, no loose linkages. So I’m really at a loss here how to explain this…
