The microcontroller reads serial data from a cxd2951 GPS unit (a Polstar PGM-111 to be specific). This gives it the aircrafts position, heading and speed, once every second. The microcontroller also reads pulse-widths from a Memsic mxd2125gl dual-axis accelerometer. This gives it the aircrafts orientation (pitch, and roll). The desired heading to the target waypoint is calculated using great circle navigation, which accounts for the curvature of the Earth. This is totally over-kill, since the plane will never be going farther than a few hundred meters, but it was fun to write, and I have the processing power to spare (for now). The microcontroller also generates output pulses for the 5 servos - ailerons, elevator, rudder, motor, and a special function.

One of my current challenges is adding support for remote-control flight. I’d like to be able to assume control of the plane using a standard RC transmitter for take-offs, landings, and if ever the CPU should go haywire (not that I’d be able to fly it any better). I started by hacking open my HiTec HFD-08RD Receiver, and (with the help of my oscilloscope) found a pin with the RF signal before it’s demultiplexed out to the individual servos. I soldered a wire onto that pin, and ran it to an input on the microcontroller. Hopefully, I’ll be able to develop an algorithm to tell the difference between a clear signal and static. I can then have it switch to manual-pilot if there’s a signal, and revert to autopilot when it’s just static.

There are two potential problems I can foresee with the current design. The first is that the accelerometers are probably too sensitive to acceleration. Yeah, I realize how dumb that sounds. I’m using the accelerometers as tilt-meters (measuring just the acceleration due to gravity). Unfortunately if the plane is buffeted around, or makes a tight turn, those accelerations will be read as well, and interpreted (incorrectly) as rotations. The solution, as it was discovered during the Apollo program, is to add some gyroscopes to the mix, and push all the data through a Kalman Filter. I should doubt very much that I have that kind of processing power, but we’ll see. Perhaps it won’t be necessary.

The second problem is that the microcontroller is outputting increasingly inaccurate pulse-widths to the servos. As I add features, more and more interrupts vie for the CPU’s time, and eventually it happens that the CPU is busy when it should be switching on or off a servo signal. It’s not too bad yet – just a slight twitch in the servos every few seconds. If it degrades further though, I’ll have to include a separate microcontroller for handling the pulses.

I started out with a Basic Atom (a rip-off of the famous Basic Stamp), which was a great decision. It worked right out of the box, and provided a good introduction to the world of microcontrollers. It wasn’t long though before I had out-grown it. There were no methods for floating-point math, so SIN and COS were pretty-well out of the question. The syntax of BASIC was also starting to drive me mad.

With my new-found knowledge of microcontrollers, I started assembling my own version of the Basic Atom. I sampled some PICs from Microchip, ordered some parts from Digi-Key, and put them together on a breadboard. To my utter astonishment, it worked! I had a blinking LED! (the “Hello World” of hardware)

For a while I flirted with Mikroelektronika’s C compiler / IDE. That was probably the biggest mistake I’ve made on this project. The Mikroelektronika compiler is crap. Compile the same code multiple times, and you’ll get different hex sizes and checksums (some of which run correctly - most of which don’t). After spending weeks chasing compiler ghosts, and fruitlessly tinkering with broken libraries, I finally gave up and switched to Microchip’s MPLAB. I should have known that the only tools to use would be the “official” ones. I’ve never found a broken library or had unexplainable behavior since.

And so the project was born. The goal: to build and fly a UAV. Sure you can buy them ready-to-fly, but for $4000 who can afford it? Hobbies are supposed to be about wasting your time, not your money… and has this one ever. It will soon be 2 years since we sat by his pool, tossing around ideas, and it still isn’t finished.

The last 19 months have been a strange journey: diving head-long into things I knew nothing about, accumulating a strange assortment of electronics on my desk (now workbench), and learning that there’s a kind of “art” to programming under-powered microcontrollers.

I’ll see if I can summarize the project’s “troubled” history in my next post.

And so, as it stands Microsoft would make a killing from licenses if this product ever hit the market. We’re running Windows XP, a copy of Office 2003 (yes, just for the speech recognition engine), and .NET 3.0. I was considering Vista which has a speech recognition engine built-in, but the laptop has “only” 256MB of RAM. Vista demands 512MB before it will install. Now, that’s some serious tom foolery!

The one thing I can say about using .NET / Visual Studio 2005 is that it sure makes life easy. With its plentiful libraries and tools, it can do in 100 lines what many platforms would in 1000. Even more impressive, the learning curve lasted about 10 minutes. I swear I could train a monkey could do this. I feel a little guilty (okay, a lot guilty), but I suppose this is really the future. Software is becoming too complex for anyone to write from the bottom up.

On the software side, it’s even more miserable: speech recognition, text-to-speech, internet connectivity, and some kind of yet-to-be-invented “topic-jisting” AI. Worse than all that though, it’s got to be dead simple. No setup, no updates, no GUI, and definitely no BSOD – “grandma” (god bless her) has never even heard of it, and I want to keep it that way.

The project is already well underway so thankfully most of these problems have a solution. The hardware for the prototype will be an old laptop donated by teammate Tanya. I pulled it apart a few weeks ago, and found myself with this unholy creation:

Tanya and Nate will be figuring out how to mount that into a picture frame, while I concentrate on the software. More to come on that.

One would put this product in a living room, waiting room, or any space where people tend to congregate and chat. As they do, The Conversation Piece will illustrate their dialog, enhancing the conversation and perhaps taking the discussion in new and interesting directions. At the very least, it should give people something to talk about besides the weather.

In another mode, The Conversation Piece will act like a regular digital picture frame, showing photos from ones own Flickr account. This will also make use of the speech interface though for quick and easy navigation. For instance a command like, “Show Lorne” would show pictures from my Flickr account tagged with “Lorne”. The command, “Show Lorne hiking” would show pictures tagged with both “Lorne” and “Hiking”. In this way the product should be simple to use, even for “Grandma” who has little or no computer experience.

So why am I starting a blog? The goal is really to catalog work on the various projects I start (and occasionally even finish). Not all of them are worthy of showcasing on my website, but all are interesting in some way and I feel they deserve some exposure. Perhaps the solutions I discover will be of interest to others - perhaps not. At the very least, I’ll be able to look back and remember what I’ve done with my time. It will be a little like a high-tech “engineering log” I suppose, (though I doubt I’d be very successful at arguing patent rights with a blog).

As time goes on, I’ll likely throw in some personal posts as well, just to thoroughly confuse things. I have my Flickr photos on the sidebar, so it’s headed in that direction already.