Blogs

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.