There's nothing like a big project for a crash course in a new technology. After choosing the Basic Stamp platform for the embedded processor version of the autopilot, I've now learned the hard way about the complexities and limitations of embedded processors. They're not insurmountable, but they're important to know, since that knowledge will help me choose the right embedded processor platform for a more advanced autopilot at some point in the future.
First, why use an embedded processor in the first place? The answer is total systems integration. The only way to properly connect a R/C receiver, servos, GPS and a stand-alone navigation processor so you have full control over the whole melange of devices is to integrate them at the hardware level. That means speaking the language that R/C receivers use to drive servos, which is pulse width modulation signals. The receivers send the servos a square wave, and the "width" (time length) of that square pulse determines how far the servo moves.
The way a UAV autopilot works (at least in our definition) is that there is always a choice between manual (human pilot) control and autonomous control. We take off and land the UAVs manually, and switch them into autonomous mode for the self-guided portion of their mission, either to test their robotic functionality in a closed course within visual range, so we can take over manual operation is something isn't working right, or eventually to go to and return from waypoints beyond visual range when all is working properly.
For a computer to take over control of some of those servos when it's acting as an autopilot, it needs the ability to intercept and pass through the regular R/C commands during manual mode, and then create and send out its own command in autonomous mode. That means the ability to read and generate square waves and that, in turn, means the ability to read voltages on specific pins of the chip.
This ability to have full pin-level control of the chip, along with internal processing routines that can make sense of square waves, is what makes embedded processors so well suited for driving hardware such as servos and sensors. But the trade-off is that you are forced to deal with a lot of primitive computing issues that are usually abstracted away behind the operating system in a more advanced processor such as those used in PCs. One such example in the Basic Stamp series is that you can't work with real numbers with digits to the right of the decimal. Instead, everything is limited to integer arithmetic (3/2 = 1, not 1.5), which means tiresome conversions and approximations when you're trying to do any sort of proper math.
Another limitation of embedded processors is that they're typically limited to onboard memory, which is usually just a few kilobytes of program memory in non-volatile EPROM storage, and a few dozen bytes of volatile RAM for real-time variable storage. This is going to require some real discipline and means that the first version, at least, won't be using accelerometers. Instead, I'll once again use an external stabilization system and just use the Basic Stamp for GPS-guided navigation.
So to end this post, here's the current state of play: The Basic Stamp will have two programs loaded. The first one, based on this code, just passes through R/C receiver commands when the plane is under manual control. When it detects that the landing gear switch has been thrown, which is the sign that the pilot has switched on autopilot mode, it switches command to the second program (based on this code), which reads GPS coordinates from the GPS module (shown) and sends commands to the rudder servo to steer to the next pre-loaded waypoint. When it detects that the landing gear switch returns to its off position, it switches command back to the first program and manual control. Sounds simple, but this will take a few more weeks to perfect. Stay tuned....
Comments