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


Moderator
Comment by Nathaniel Caner on November 8, 2013 at 3:42pm

WRT your altitude issue...you do have ALT_MIX set to 1 (100% barometric), this is good as GPS can be very unreliable for altitude estimation. Do you have an enclosure for your board? Is the barometric sensor on the board shielded from having changing air-currents blowing directly on the sensor? (as is shown here) This could explain the erratic altitude reporting if you don't have it protected from changing air currents over the sensor.

Regards,

Nathaniel ~KD2DEY

Comment by Georacer on November 8, 2013 at 3:48pm

I have used a (not very dense) piece of foam, as seem here, to protect my barometer from light and gusts. I do not believe that glue reached the sensor, I tried to prevent it. The board doesn't have an enclosure, it sits screwed as you see it, inside my Skywalker 2013. There is no extra wind intakes in the fuselage so, no, I don't expect airflow or light to be an issue in this case.

This belief is reinforced by the fact that the Relative Altitude, a measurement that combines accelerometer and barometer, seems to track the climb well.

Comment by Jared Reabow on November 8, 2013 at 4:43pm

my first though is, you are getting low pressure inside the model, this can happen if you have a hole that is flat and near the rear of the model that causes air to get sucked out.

the solution is to make a air intake somewhere with an extruding scoop to counter the negative pressure that will vary with speed.

if not that i would suggest an enclosure for the board as thin foam doesn't work to well from experience.

but if the board is internally mounted then air currents aren't an issue.

in truth i have always had issues with the barometer on my apms, i have had over 10 and every single one has had Baro issues.

i think if anything needs an external component its the barometer.

what i would suggest doing is disable the voltage RTL and invest in a small balance lead alarm.

Comment by Georacer on November 8, 2013 at 4:50pm

I am confused by both of your comments. You both point out at the barometer. Are you seeing something that I don't?

The relative altitude seems like the only reasonable response that the logs returned so far. What makes you start the investigation from the barometer?

Comment by Jared Reabow on November 8, 2013 at 4:57pm

as the other guys says, you are set to use 100% barometer for altitude, so the barometer is giving all the altitude info, i usually leave at default of about 70baro 30 gps because the gps helps verify height,

the problem with 100%baro is that it is reporting incorrect altitude.

relative altitude is calculated using the baro data

Comment by Georacer on November 8, 2013 at 5:13pm

I had not realized that the GPS does not play any role in the altitude solution until you pointed me to the ALT_MIX parameter. Thanks.

This indeed pulls the blame from the GPS.

Here it is stated that Alt is the GPS altitude which is NOT used by the flight controller and that RelAlt is the acceleromtere+barometer altitude solution. However, this page is written for arducopter and I'm not convinced this is the case for Arduplane as well.

As a piece of evidence, notice that the .kmz files which are supposed to represent the actual position of the aircraft in the air, follow my Altitude variable very closely, instead of the Relative Altitude. This is true for all of my flights.

Can you please check if this is the same for you as well?

But if the GPS doesn't play any role in the altitude solution, does anyone know exactly what is the difference between Altitude and Relative Altitude or have a reference that explains it?

Comment by Jared Reabow on November 8, 2013 at 5:29pm

just set to use both and it should fix it, i believe relative altitude means to the ground and real ALT means to sea level

Comment by Greg Fletcher on November 8, 2013 at 8:47pm

Did you set your fail safe on your receiver ? Did you test the failsafe action with you prop off on the ground ?

As for the altitude, arduplane only uses one altitude. It is a mix of gps and baro. Verify that "ALT-MIX" is set to 1. This is 100% baro and is the default setting.

The relative altitude is the distance obove the ground, specificaly the current altitude(above sea level) minus the home altitude(asl) on start up. That doesn't explain the divergence in alt/rel_alt. I think you are plotting gps alt and

reletive alt. I looked at the code and gps & reletive_alt are the only altitudes sent on mavlink.

I will look at your telem log and get back here.

Comment by Greg Fletcher on November 8, 2013 at 10:03pm

OK, here is my diagnosis. Your plane is underpowered and you only gave half throttle for ~ 2.7 sec and you then gave full throttle and climbed a little. When you were ~ 250 meters away, you lost your RC link and went into RTL. Ardupilot saved your ass(or your plane's) and did it's best to get home.

Also, are you using an airspeed sensor? It is not correct.

That abandon air base is a great place to fly. Did the turn it into a park ?


Developer
Comment by Andrew Tridgell on November 9, 2013 at 12:16am

Hi Georacer,

I've looked over your tlog, and there are certainly lots of issues there, but I haven't yet seen anything that APM did wrong. I'll try to cover your questions below.

First off your question about the generated path in google earth. The path is generated using GPS altitudes, and GPS is notoriously bad for altitudes. The actual APM flight uses the barometer so is unaffected by this, but it does look strange in the kmz file.

Next, the RTL. The switch to RTL was indeed caused by low battery voltage. At the time it switched to RTL your battery voltage had been below the minimum voltage you had set of 11.2V for 10 seconds:

For a battery voltage failsafe the time threshold is 10s, so when it had been below for 10s it triggered RTL. I've updated the docs to make it clearer that the 10s threshold applies, not the long failsafe time.

Finally, you wanted to know why it used low throttle in RTL. That is because your airspeed readings are crazy:

I don't know what type of SkyWalker you have (they make a lot of different models), but I don't think any of them can do 48 m/s (172 km/h). The ARSPD_FBW_MAX was set to 22 so the APM thought you were way overspeed, so it lowered the throttle to prevent your plane disintegrating from flying far too fast.

Your ARSPD_OFFSET was 2425, which is far higher than normal. Are you sure you have your airspeed sensor attached to the right pin? What sort of airspeed sensor do you have?I'd suggest you do your next flight with ARSPD_ENABLE=1 and ARSPD_USE=0, which will log your airspeed but not use it for controlling the flight. Then check the logs later to make sure it is sane.

Cheers, Tridge

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