Kerosene jet with Arduplane crash analysis

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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • Were you using one of the differential pressure air speed sensors?

  • T3

    How is your APM powered? 

  • 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).

  • ...mmm...low altitude, RC real-fuel-powered jets...what could possibly go wrong... :-D


    I'm kidding of course. Hope you find the problem and get back in the air soonest. At 5km, with those white lines in the might have some onboard interference, as you suggest.

  • I thought that once the APM entered RTL because of a bad signal then it latched there until the user changed modes? Why would this have gone in and out of RTL due to poor signal?

    Myself and a friend had a crash a while back with a similar situation - I was (assumed) on the edge of the range and the quad just fell out the sky. When I looked at the logs there were multiple switches to RTL just before it gave up. (batteries etc were all fine).

    My suspicion is, and I think I did a post about this, is that my receiver (Spektrum) did enough of a "jitter" or change on restoration of the signal to make the APM think there was a mode change which then brought the APM out of RTL. 

    On the 3rd or 4th switch it fell like a stone :(

    Sorry for your crash - hope you recovered the plane ok.

  • Developer

    Hi Mark,

    I had a quick look at the log and while it is hard to tell for sure, it is clear that your attitude solution was not good.

    There are a number of sensor anomalies that may explain that:

    • the compass shows the total magnetic field stength varying by a factor of 5x over the flight. Variations of more than 20% are a sign of trouble. I notice you had compass learning off. Could you have had a variable magnetic source in the aircraft?
    • the GPS velocity numbers are don't match the accelerometer readings at some stages of the flight, with a huge discrepancy. This is usually a sign of GPS interference, often from an onboard analog video transmitter

    The DCM code used for attitude on an APM2 is sensitive to both of these errors. Either one of those could have caused the attitude errors and the crash, especially at high speed.

    The EKF code in the 3.0 release of APM:Plane on a Pixhawk is much less sensitive to these sorts of sensor errors, and would be a much better choice for an aircraft like this.

    btw, is there some reason you use 2.74? It is quite old.

    Cheers, Tridge

    • Hi,

      thank you very much for looking into our case. We struggled a lot with the EMF noise induced via ECU and its engine on this airframe. Due to this we turned compass learning off. During the flight we had no radar systems switched on yet, so as far as we can measure, there was no significant outside noise.

      The GPS problems we think are likely due to the shielding on either the GPS or the analog video transmitter coming loose or being damaged.

      The 2.74 FW was the one we based all our previous flights on so we were reluctant to switch to a newer version since previous test flights were positive.

      EZUHF will go further and was switching the RTL purely due to low RSSI which was something we expected and wanted because we did not use high dbi antennas. The telemetry was running on 915MHz and the UHF on 433MHz so there was no interference between the two.

      In summary we need to rethink of ways to spatially separate the compass and GPS from the EMF noise sources plus work on any possible shielding improvements. Since we now need to start from scratch, we also will switch to a Pixhawk with the appropriate firmware.

      Thanks again for helping out anything else you might suggest for our project.

      • On your next build you should investigate low and high pass filters for all your radio gear as well as high gain antennas. Bring out a spectrum analyzer or a scanner to your flying site and listen in on the frequencies you are using to make sure some they aren't used. In the US many 433 systems get swamped by other radio transmitters.

        I'm amazed at how far the telemetry worked on just the stock antennas.The newer gps with combined compass seem to help a lot when get them away from RFI. I almost had a flyaway but turned it back to manual because of the RFI generated by my GoPro. The other thing is to practice taking the plane out of RTL and back into manual/stabilize mode when you have RC signal. Its a lot of prep work to get the proper rf signal but sound like you have a lot of money invested in your systems.

      • Hi, is there any chance the APM might have come loose, simply?

        RSSI indicators are not really reliable. They are more for diagnosis/entertainment; many will indicate "full signal" given a loud burst of noise.  You may want to consider to stop using that, and/or having the plane continue in AUTO even after an RC loss. Once you have a telemetry link that works better (what did you use? RFD900s? They should perform better than that) you can engage RTL that way around if you need to.



  • Sory for you loss. You were able to find the plane? Through the end of the video there were very quick rolls, the plane was also very fast. I think those quick roles and speed damaged one of the control surface of the plane. 

This reply was deleted.