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.

Views: 2132

Reply to This

Replies to This Discussion

the apm was still responding, as the alt,roll and pitch where all responding, you can see this via the osd.


but it does look like the attitude solution was messed up.

watch the pitch, its at +38 degrees even though its pointing at the water.

Yes, AHRS got messed in the end.
Wonder of gforces could have played a trick here.
Speed does not influence cpu usage.
Was GPS sane until the end ?
Any chance of recovering .log from APM ?

Could you please share with us the context of your project involving autonomous high-speed low-level flight of turbine-powered aircraft? Thanks! 

It's for testing a radar prototype for our university. The flying area is a dedicated area for this purpose and there are failsafes for the motor Ecu that are triggered should there be any indication of a fly away.

First the video was painful to watch. Were you able to recover anything?

Looks like perhaps the magnetic compass was off. Here are a couple  screenshots of your telemetry. Is there a chance that APM came loose or something caused magnetic inference?  With the compass being off the APM may have tried to correct. The red line is the magnetic heading and the black line is the gps heading

Also what antennas are you using for the EZUHF? You should have gotten better range with EZUHF. Out were you were flying you should easily get 10-15 km if not 20km. Also did you have any other equipment running like RADAR? Also which frequencies are you using for telemetry? I wouldn't use 433mhz telemtry with EZUHF.

I would investigate things that can interfere with the gps and magnetic compass. I would also use a spectrum analyzer to see what devices cause rf noise such as the Jet Engine computer. 

Another cause could be the plane lost elevator control somehow. Hard to tell from the limited telemetry data.

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. 

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

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.


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.

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.



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.

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

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service