For a project that involves fast, low flying jets, we set up an APM running Arduplane 2.74.
We used EZUHF for the RC link which was programmed to trigger RTL if the RC link got too weak or lost.
What you can see in this video is the Mavlink data using Minim OSD during the auto waypoint flight. At 1:10 the link starts to cut out and the APM switches to RTL. However, the link does come back a few more times, switching between Auto mode and RTL. At 1:50 the pilot invoked RTL via RC link to make the jet fly back home.
At this point however the jet dives and does not recover.
Unfortunately our telemetry link died after 3km, so our recorded logfile is only useful for that part of the flight:
Based on what we can see in the video, we are assuming that the APM might have frozen up since the artificial horizon stopped working as the jet started to dive. But it might as well have been the MinimOSD that was lagging behind the data.
Of course considering the speed at which the jet flies, it is entirely possible we have been on the limit with the APMs processing power but we had multiple RTL runs that went flawlessly before this accident.
If anybody has ideas or suggestions on what might have failed, please post it here or feel free to ask any questions I might be able to answer.
What G-Forces are expected in such planes? I think the current accelerometer setting in the code is 4G, beyond that it will just show 4G that might get the AHRS in trouble. So doing a sustained Acceleration at that brink of the accelerometersetting might cause trouble. Maybe enabling 8G or 16G scale for the acc would be a better thing for your application or having 2 or 3 Acc chips at different resoultion settings to have more precise readings over a broader "G" range without saturation effects (fading out the acc data of the one that's reaching saturation).
How is your APM powered?
Were you using one of the differential pressure air speed sensors?