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.