MASSIVE UPDATE WARNING!

Oh, man. What a day. I'm already on my way back to Austin, having slept 12 hours last night (staying awake for ~30 hours will do that to ya), and sore due to a nice morning hike to one of the many summits in Colorado. Let me tell you, stuff went down.

During the competition, I did have some victories, but experienced even more defeats. The last issue that I mentioned having was that I was not able to go straight, so I'll start with that. My plan of attack for the day was to be able to go straight for long enough to make the first corner. In order to do that, I needed to be able to go straight for some time, then turn left, never mind the fact that the pavement that we would all start at had something like 20 degree grade -into- some curbs.

Anyways, after looking at and messing with the raw values that I was able to get from the IMU, I decided that i could get away with simply sampling the Gyro at 1KHz, and using that to tell the rudders which direction to turn. Plan of attack was decided, code was written, and tested. And it worked! Mostly. After I started testing, I found a condition where if I reset the MCU while a transfer was occurring, I would need to cycle power, until the part was responding to commands again. Something I need to look into later...

But when it worked, it worked wonderfully! The rudders would correct for the direction that I would rotate the Hovercraft, and fairly quick I would say. Then another problem arose. If I were moving the Hovercraft while it was fetching the first reading, it would noticeably drift at a rate of a few degrees per second. This was no bueno. To counteract this, I made part of my startup routine take samples while the Hovercraft was at rest, and use that as the resting state for the Gyro. Calibration might have corrected for this, but I simply didn't have the time. In any case, this was able to work well enough.

Alright, so now I have a possible method for going straight. Awesome! Time to start sending commands again. What's that? All of a sudden you're not taking them anymore? Not cool.

Sure enough, as soon as I got the stabilization code functioning, the part of the code that would receive and parse commands stopped working. If it's not one thing, it's another... An hour or two pass by, and I'm checking over all of my new code, everything looks good, and then I see it. Two hours lost because of a single character. You think I would have lost it by now, being sleep deprived and stressed, but this is something I've actually gotten use to, having worked with Embedded Systems for years now. What was happening was that because I wasn't clearing the Timer Interrupt, I got stuck in an infinite loop that would starve the main program whose only task is to parse commands.

Alright! So now with that out of the way, it was smooth sailing! ...right. I was able to get a few tests in that showed, for the first time, that the concept could work. I could start the hovercraft. It would hover on asphalt like it were smooth. It could lock on to a bearing and follow it as best it could. But it couldn't lock on well, and the control algorithm was primitive, and needed much more work. Evert time I tested it, it would over oscillate, correct for it, then swing even more. Frankly, it spent more time rotating and correcting for itself than actually moving forward.

But this was moot point, because by this time, one of the three heats had already come and gone, which I had to miss out on. At this point in time, I had the chance to at least show off what I had been working on for months, and I took it.

It performed as well as I thought it would, and took over a minute to actually get going due to the flakiness of the IMU startup code. Unfortunately, this was the only run in which the Hovercraft actually moved forward on it's own. It was exciting to watch, problems and all, but was still frustrating. It only made it halfway to the first turn before getting stuck in the curb due to the slant in the pavement.

Having followed the "successful" run, I started trying to fix the IMU startup issues, but in the process of doing so, managed to bork even more things such that the Smartphone to BoosterPack communication broke down again. This time around, I was not able to resolve it.

Out of all of the issues that I had, I still can't wrap my head around the fact that for some reason, I need a printf in my main function in order for the code to function properly. I can't tell if this is some sort of compiler issue, linker problem, or just a general logic snafu.

So with Sparkfun AVC now a thing of the past, and me being on my way back to Austin, I'd like to clear out these bugs before I release the code to the public. Hopefully sleep will help.