blog.lorneswork.com

The current design, (and I stress current, because it changes every 3 weeks), is built around a PIC18F2550. This is one of Microchips USB-enabled devices, which means that new firmware or flight-plans etc. can be uploaded to it in seconds from any computer with a USB port. You know you waaaaant it.

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 should have kept a blog from the beginning, because it’s almost impossible now for me to relate (or even remember) everything that’s happened.

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.

I think it’s time to introduce another project I’ve been working on. One day, near the start of summer ‘05, I was hanging out with my friend Colin. He’s a mechanical engineer, and I’m a computer scientist so we tend to talk about some pretty nerdy stuff. Trying to break our boredom, he hit upon the idea of building an RC plane. This sounded fun, but just wasn’t high-tech enough for me. People have been flying RC planes since the 1950’s… big deal. A UAV though! Now THAT would take our project into the 21st century.

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.