Black Box Stories: The mysterious deal between Altitude and RTL

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.

The 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:

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

Views: 2041

Comment by Georacer on November 9, 2013 at 2:02am

Thank you all for your answers. I will address them in order of appearance.

@Greg Fletcher,

I have an AR600 Spektrum receiver on board. I have set its signal failsafe separately, in order for it to output 930ms pulses when the transmitter signal is lost. I have verified its operation. The reason I don't believe that it wasn't an RC but a battery one is the dataflash log. Go to line 14358 where a battery warning message appears and right after that RTL engages. It is not a conclusive relation, but pretty indicative. On the other hand, no RC failsafe message appears in the log.

You probably are correct when you say that I don't plot the right altitudes. Frankly, I'd love to have some fleshed out explanations on what information each dataflash message type carries. Thisis outdated and lacking.

I will address the airspeed issue along with Tridge's answer.

@ Andrew Tridgell,

It seems that you pretty much nailed and explained everything and it makes sense! Thank you!

I was aware that there was something wrong with airspeed, but since I was interested mostly in finding why RTL engaged I decided not to mention it. Here is what was wrong with it.

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!

While on the field and before the flight at hand I had noticed that the auto-calibration procedure wasn't quite right. So I disabled the ARSPD_AUTOCAL parameter and returned ARSPD_RATIO to a previous known good value of about 2.9. I believe that I also did the Preflight_Calibration action from the Data Flight tab of the Mission Planner, but this didn't seem to correct all of the problematic parameters the automatic airspeed calibration had created. I will try to trace all of the related parameters and re-set them by hand.

In the end, you all helped me trace the causes of the incident. Consider me a happy DIYDroner! Thanks!

Comment by Gerard Toonstra on November 9, 2013 at 2:58am

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.

Comment by Georacer on November 9, 2013 at 3:18am

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


Developer
Comment by Andrew Tridgell on November 9, 2013 at 4:08am

@Georacer,

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

Comment by Georacer on November 9, 2013 at 4:31am

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.

Comment by Georacer on November 9, 2013 at 4:51am

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

Comment by Georacer on November 9, 2013 at 7:51am

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.


Developer
Comment by Andrew Tridgell on November 10, 2013 at 12:21am

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


Developer
Comment by Andrew Tridgell on November 10, 2013 at 12:22am

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

Comment by Georacer on November 10, 2013 at 12:29am

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

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service