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.

Hello everyone,

I have finally completed the build of my UAV platform. I'm talking just the plane here; the autopilot issue is a very different one and I'm still experimenting on it.

I always like to give back to DIYDrones, which conveys very valuable information to me daily, so here you have it.

Here is photo gallery. If anyone needs a parts list I'll be happy to provide one.

Side View

Under-Side PaintJob

Direct USB Connection Port

GPS and Receiver Installation

Battery and Differential Pressure Sensor Placement

USB Port Hatch

The Carrying Case

Made out of PVC tubing

Inside its Belly

Thanks for watching!

Hello everybody,

Yesterday I successfully supported my diploma thesis on the development of a UAS. It was an all-around research, from navigation algorithms to hardware development. In all, the nature of the thesis was an experimental one.

The .pdf can be found on this Dropbox link, as I had problems with uploading the .pdf on the diydrones servers. If a mod could help me on this I would be grateful.

EDIT: Here is the permanent link for my thesis, in the library server.

If you care to open it, make sure you read the Acknowledgment. The body of the text is in English, don't be put off by the Greek first few pages.

The level of the thesis was quite basic, but the adventure continues onto my PhD.

This might be a common knowledge, but in the last months I haven't seen a similar post. Maybe someone new to barometers might be interested in this data.

The GPS receivers return altitude data, but this is inaccurate. The error margin depends on the satellite constellation geometry and whether or not you have SBAS DGPS on. I was under the impression that the error was 5-10 meters, but as it turned out, I was wrong.

Recently, I embedded a BMP085 barometer in my autopilot board and operated it with this library: http://code.google.com/p/bmp085driver/

Barometers can be and are effectively used to calculate altitude, once initialized and zeroed.

So the figure above displays a short manual flight whose altitude is measured both by a barometer and a GPS. The barometer is zeroed upon power-up. The GPS altitude is zeroed, based on the altitude returned before taxiing. It is the time between 20 and 30 seconds. The plane lands at 150 seconds in the exact same place it took off. However, the GPS altitude measurement has already drifted 16m away.

This goes to show that GPS should not be used for altitude measurement, unless a very coarse albeit offset-free measurement is required.

A barometer is a much more accurate and fast device to extract altitude, when operated correctly.

Last Wednesday I went out to the field for some flight tests and gains trimming. Other people where flying their model planes there too. We usually follow a counter-clockwise pattern while flying to avoid collisions. That day I was flying especially slow, so when I took the turn, I did so on the spot and ended on the wrong lane. By the time I realized that, someone rammed me out of the air.

If I remember the even correctly, and the flight replay (LOG00212.kmz), the collision should be head-on. However, the reason I fell, was because the other plane's propeller clipped my left aileron. I managed to crash-land while doing semi-controlled spirals, losing a wing, the propeller and a wheel.

Afterwards, I tried to do some black-box analysis, with interesting results:

Firstly, here is a graph of the altitude, and the magnitude of the acceleration vector and angular speed vector:

The collision occurs at about the 120th second. I estimate the moment at 120.5s. Strangely, no acceleration or angular motion peak is noticed at that moment. Only after I try to pull up at 124s is acceleration recorded, and, of course, at the crash. The IMU is supposed to be set at +-8g limit.

The roll, pitch and yaw plots are a bit more indicative of the situation:

Roll goes crazy after I pick the plane up from the tail and carry it back to the car. It's expected.

In the last two graphs, a violent change in direction is noticed, in contrast with the first plot.

To sum up, I didn't find the accelerometers a good source of information, in order to detect a mid-air collision. Instead, angular velocities are more reliable, with proper thresholding.

Hello everybody,

This is my first, of hopefully a series, DIYDrone blog post.

The Hill Cruiser is the topic of my university thesis, which is to build an autopilot for an RC model plane.

Of course, I was inspired by the ArduPlane and the UAVDevBoard/MatrixPilot. Many thanks to you people for letting me see what I am capable of.

Consequently, I 'd like to start giving back to the site. I 'll start by posting a short presentation of the system I built, that I will be presenting at an EE student conferenece tomorrow. It's not very detailed, it's supposed to last 15 minutes.

I hope that I 'll be able to post the detailed multi-paged thesis document by the end of July.

This is the presentation .pdf:

Hill Cruiser - Conference Presentation

 Some things I 'd like to note:

1. I 'm waiting for a PCB from China for the main board. It will house the barometer and the pitot tube sensor and thus these are not implemented yet in the control system.

2. I know that my PID gains are off. I haven't had the time to tune them to perfection but the system operates, albeit the oscillations.

Feel free to post your questions.

Cheers!