Rob & I have been working on the plane today, which has had some interesting developments and problems. At the onset of dusk we made a last minute dash to a nearby park to get in a flight, given that the wind had finally settled down enough, and although autopilot wasn’t working properly, we figured we could get some more film and some more data. We did that, and the flight went well – despite Rob’s attempt to crash the plane into me on landing (which I have on film as proof :D ). However, once we got the MMC out of the plane and quickly into my computer, we discovered a horribly thing – we had almost no data. Dejected, we returned home.
After dinner I imaged the card and set about analysing it to gather any clue as to why we had exactly – and no more than – 3116 bytes of data, from a fifteen minute flight. I’m very thankful that I long ago discovered and installed bvi, a very handy (albeit simple) raw file editor. Unfortunately, we hadn’t expected this problem so we’d plugged the MMC straight into my computer, which promptly wrote it’s .Trashes and .DS_Store and other garbage to it. So we immediately vandalised the card, before we could get any sort of snapshot. Thus, there’s no way to be sure what went wrong. After a bit of analysis I concluded that there was no obvious corruption, that there had been more data written to the card (3116 is a few bytes short of six sectors’ worth, and those few bytes contained the start of the next bit of valid data) but that the FAT hadn’t been updated… so for some reason, the AVR died about a minute into the flight, without having saved the working FAT block to the card. And my computer then overwrote the end of the file, so we don’t know exactly when it died, or have any logs or measurements at that time that might indicate what happened.
So, we’re at a bit of a loss. The currently favoured hypothesis is, however, that the board suffered a brown out which reset the AVR. Since we need to arm the AVR (by pushing a button on the board) before it will start doing anything, it presumably then spent the rest of the flight doing nothing useful.
However, in order to ensure all changes are flushed to the card before yanking it out, the arm button doubles as a flush button, which Rob held down for some time before yanking the card. So we would expect that the card would be written to in that brief period before he yanked it… it wasn’t.
The other most obvious hypothesis is that something went critically wrong in software, which caused all logging to disk to fail. Since we lost bluetooth more or less as soon as the plane took off, we didn’t see any log messages that might have gone out indicating a problem. The software has been developed by myself for months and months now, and pretty heavily tested (primarily on PC, but also on the AVR)… we’ve had several logging problems – including once in an earlier flight where again logging ceased part way – but when we’re on the ground and able to debug the board, we never have issues. (well, aside from temporary ones while we’re fiddling with bits and pieces)
So, it’s certainly a problem. We do have one good, complete flight log thus far, which we’re analysing at the moment… we’ll be flying again later today (Sunday), weather-permitting, and can hopefully see off these problems.
Aside from this thorny issue, there were several others we worked through. One in particular was the PID algorithms controlling the plane. Rob was trying to get the rudder working, since it’s relatively trivial – we know the bearing from the GPS and magnetometre are relatively reliable, so we should be able to see the rudder servo adjust itself appropriately as we rotated the board. Unfortunately, it just hasn’t been happening. Rob’s been at the problem for several days, but particularly today, where he spent many hours on it. Now, while it’s likely there were several issues preventing it working, which he progressively squished, it seems the biggest factor was in fact… *drumroll* the servo was plugged into the wrong header! For whatever reason, the labels Rob wrote on the board were back the front, so it was non too surprising that his rudder algorithm wasn’t affecting the throttle. Whoops!
With that issue resolved, the rudder servo now works appropriately… there’s still substantial tuning required to find the best PID parameters, but that’s a straight forward task.
A lesser issue that is more humorous than significant is a brief moment when Rob was connected to the board via Bluetooth, and then all of a sudden it started printing a steady stream of Q’s. He immediately assumed it was a glitch on our (read: my, since I wrote the Bluetooth stuff :) ) part, as I tended to… but a few moments later he realised what it in fact was – he was holding the plane vertically in one hand, and it was resting on the Q key. :D
In Rob’s defense, this was quite late in the evening, and we were both quite tired.
The last thing we tested was the magnetometre in the presence of a magnetic field… I used a PC speaker and a strong magnet to test the deviation of the magnetometre. Sadly, it was very significant – while they are strong magnets, which of course won’t be on the plane when we fly, we had somehow hoped the magnetometre would be more resistant.
This then, of course, led to a quick test of the motor’s influence on the magnetometre. We couldn’t be bothered putting the plane together proper, so Rob just held the board next to it, while I turned the throttle all the way up, then all the way down. And the result was most displeasing… significant deflection of the magnetometre. Luckily we have the GPS to provide us with a bearing as well, which doesn’t depend on magnetism, but it’s unreliable at low ground speeds. The motor’s effect on the magnetometre should be proportional to it’s rate of rotation (which is roughly proportional to the duty cycle of the PWM signal that controls the motor), so in theory we could probably perform a series of tests to determine the relationship between throttle and deflection, and adjust for that in software… but it’s not a trivial thing to do, and certainly not something we can get done by Monday morning for the presentation.
Unfortunately, with this project we’re learning a lot of ways not to do things. But I don’t consider it a failure at all, in academic terms at least – we’re learning a huge amount in a variety of areas, we’re making significant progress on several fronts, and we are actually pretty close to the primary goal of automated flight. We may even have some luck with it later today, touch wood.
So, I should get some sleep, so I can get up before the test flight and try to bang out some of the remaining significant performance issues with the data logging.
