Figure: Did I really fly through the ground?

I hoped I wouldn't have to do another Black Box Stories episode, but unfortunately I need help. The good thing is that no planes where harmed during this event.

Here is the backstory:

Today (just like many other days) I was tuning my RCTimer Arduflyer running Arduplane 2.76. It's been an eventful process, laid with unexpected problems. Today was no different.

I had already done a previous flight, tuning the pitch controller. This was on a fresh pair of 3S Zippy 5000mAh, in parallel, and had burned 3000mAh, according to a calibrated (by me) current sensor.

On this flight, I wanted to tune the navigation autopilot and had prepared an orthogonal mission to do so. So I push my Skywalker on the "runway" while on MANUAL mode, go full throttle and:

  1. Climb for 4-5 second on full throttle at about 20m above ground.
  2. Realize that suddenly I don't have power on my motor.
  3. Immediately try to cut throttle and go WOT again, in case there was a motor cut-off. This didn't work.
  4. I accept the fact that I don't have thrust and try to turn around and land. I get a feeling that I don't have precise control of my control surfaces. Nonetheless, I keep turning my plane ungracefully back 180 degrees to align with the runway.
  5. While descending, I hear sounds that suggest that the motor varies its throttle level erratically, always staying on low levels.
  6. This worries me and I instinctively I switch to FBWA mode. This silences the motor permanently as required.
  7. I land the plane without problems in FBWA.

Of course, I found this behaviour very strange so I tried to examine the logs. The take-off is at 30% in the files:

Dataflash Log

Telemetry Log

Google Earth File

Part 1

Let's start with the Google Earth .kmz file. By opening it, you will notice a very worrying sight: Most of the flight is mapped underground!


As I couldn't believe what I was seeing I converted the dataflash onto a Matlab workspace to examine the data more closely. It was even worse!


I have cropped to the section of interest. You can clearly see the take-off moment, when the Throttle input (manual) rises from 0 to 100%.

At that point, while the barometer and accelerometer solution, in the form of Relative Altitude (what is that thing exactly anyway?), recognizes the increase in altitude, the total altitude actually drops below the ground a dozen of meters!

Coincidentally, the number of satellites at this point drops from 10 to 6, which is pretty unusual by my books, a rare occasion.

Another worrying plot is the altitude throughout the whole session, pre-flight and post flight included.

3689558190?profile=originalThe Altitude variable isn't steady at all, even though the aircraft is set still, as the Relative Altitude witnesses.

This is similar to the steadiness I was seeing in the previous flight (with the 2.74 firmware) but notice that today the DC offsets of the two variables mathced.


Part 2

At the same time, I discovered another inexplicable problem.

While playing back the Telemetry Log I realized that at the time the throttle was cut, the plane had returned to RTL mode and stayed there until I switched to FBWA!

I theorize this happened because I had set the Battery Failsafe Voltage level at 11.2V. In retrospect this was a very generous setting and indeed at WOT my batteries dropped at 11.1V right after this flight. But I still cannot explain why the RTL mode was explained.

For starters, the voltage threshold tripping didn't last for more than 10 seconds tops. Graphs verify this. This means that Long Failsafe shouldn't engage yet.

Moreover, I had not the Short Failsafe enabled, even though this would be supposed to switch in CIRCLE mode.

Finally, even the behaviour of the RTL was strange. Instead of returning to the HOME point at 100m above ground as defined, which would mean a hard climb, the motor "kind of purred". I didn't verify if the horizontal navigation part of the RTL worked, as I was navigational inputs the whole time and those factor in during RTL mode (as per the wiki).

Below is a detail of the throttle input and output time series, as extracted by the telemetry log browser:

3689558137?profile=originalYou can see a more detailed version in the Mission Planner Tuning screen, by replaying the mission.

Since I could not find a variable to represent the MODE in the Telemetry Data, I tried showing the engaging of RTL and FBWA through the processor load. The low load is the MANUAL mode. The high load is the RTL mode. The medium load is the FBWA mode.

This is all the info I could gather. I think I'm close but I just can't connect the dots. Any help is greatly appreciated.

E-mail me when people leave their comments –

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

Join diydrones


  • It seems that the problem with the airspeed measurement was indeed the folded silicone tube. I flew yesterday and all seemed to work nicely.

    Automatic calibration pushed the ARSPD_RATIO to 3.891 but the groundspeed and airspeed plot matches nicely, so I'm not changing it.

  • I don't have a hairdryer around, no need for it. As they say: No head, no headache.

    This could be a good reason to buy a hot air gun, tough... ;)

  • Developer

    I also have a hair dryer I sometimes use to test it. I know that my hair dryer produces a reading of around 15m/s.

    Cheers, Tridge

  • Developer

    I cover the pitot tube with a small plastic ziplock back, which has a couple of holes along its body so it's not sealed. This is to protect the tube from winds.

    I hit the PREFLIGHT_CALIBRATION option and wait until Mission Planner returns the control back to me. This usually takes about a second.

    yep, that's a good procedure. I do something similar but with my hand. I then blow into the sensor to check its working.

    Cheers, Tridge

  • I think I found out why the airspeed readings where so off.

    I checked for continuity between the sensor pins and the wire ends going in the APM and found no open circuits there. So I checked my tubing.

    Here is my setup.


    You can see how the differential pressure sensor is connected to the Pitot tube. Notice how short the silicone tubes are, in order to reduce pressure distribution lag as much as possible.


    However, this caused an occasional problem, as a tube could fold, not allowing a free pressure front propagation:


    This can be compensated for by choosing alternate sensor placements:


    I'll test this solution probably on Monday.

  • @ Greg Fletcher,

    I forgot to tell you. The place I fly is the former main airport of Athens, Greece. Since a new one was built outside of the city, some 10 years ago, this one is abandoned.

    Some facilities have been re-purposed and rc hobbyists have a spoken agreement with the authorities, as long as we don't fly beyond our designated area.

  • If I read my .tlog correctly, only twice the ARSPD_AUTOCAL and ARPD_RATIO parameters appear. Both times, ΑRSPD_AUTOCAL is set to 0 and ARSPD_RATIO to 2.987. Is this what you want me to notice?

    This reinforces my belief that I had disabled auto calibration and had set a manual airspeed ratio.

    The airspeed sensor used to work reasonably well before yesterday, but of course, I will do a routine check on all hardware connections.

    In the meantime, could I get some comments on the way I do my PREFLIGHT_CALIBRATION of the airspeed sensor?

    I cover the pitot tube with a small plastic ziplock back, which has a couple of holes along its body so it's not sealed. This is to protect the tube from winds.

    I hit the PREFLIGHT_CALIBRATION option and wait until Mission Planner returns the control back to me. This usually takes about a second.

    I remove the ziplock bag and go about my business.

  • Developer


    Today was the first day my APM ran with the 2.75/6 firmware, which features automatic wind estimation. I had not realized that a new Airspeed Calibration procedure was mounted on the wiki, so I switched ARSPD_AUTOCAL to 1 and let it there, during a 30min session, in which only 7 mins where actually airborne. THIS IS NOT THE CORRECT PROCEDURE and I found out about it later in the day. Indeed, it had sent the ARSPD_RATIO parameter to the thousands!

    I don't think so. The airspeed calibration code limits the ratio to a maximum of 4.0. It also doesn't change the ratio at all unless you are flying (it checks groundspeed, airspeed and attitude). The tlog you sent shows the progress of the airspeed calibration code in the AIRSPEED_AUTOCAL messages and shows the ratio didn't move from 2.98.

    I thing your airspeed sensor setup is broken in some way. The ARSPD_OFFSET is way too high. That value is based on reading the sensor at startup, and not based on the ratio.

    As I said in my last message, I recommend you do your next flight with ARSPD_USE=0 and ARSPD_ENABLE=1 to log your airspeed values and see if they are sane. Something is badly wrong with your airspeed setup. I don't think it has anything to do with the autocal code.

    Cheers, Tridge

  • @ Gerard Toonstra,

    The GPS unit and the ESC have 30cm of separation. Do you think that is adequate? I don't see how I could push the GPS further away from the ESC.

  • If the GPS starts acting really weird when on 100% power, it's possible that the ESC is emitting a lot of noise and radiates into the GPS antenna. Spatially separating them more would help.

    The altitude of GPS indeed isn't very precise, but it does need to be configured correctly. Some have modes where they assume pretty much straight lines on roads. Since on planes the banks are done with sometimes quite a bit of G's, it can confuse the alt readings. It's just another guess.

    If RTL engages, it's an actual mode switch. Nothing happens to the mode, not even say, if you did lose the link and get back in radio range. It only changes when the currently known switch setting changes.

This reply was deleted.