This post describes the beta version of BASIC Stamp autopilot code. As mentioned in my last post, the two main challenges in this project were dealing with the constraints of integer-only math and a severely restricted variable space (just 26 bytes!).

The first one I got around by treating fractional degrees as full degrees (since the UAV is never going to travel more than one full degree away from launch) and essentially treating them as integers. This was a little tricky, since I'm limited to word-length variables (with a max value of 65,535, which is essentially 4 and half digits of precision) and the GPS natively generates six and half digits of precision (360.9999 W/E). But I truncated the full degrees to just 1 and -1 from the current position, and that let me retain the full precision of the fractional degrees.

The second problem I got around by splitting the program up into five sub-programs (each one is allowed to reuse the variable space in RAM) and switching in real-time between them. I also used the Stamp chip's 121 bytes of "scratchpad" memory to store a lookup table of all the waypoints, and that's available to all the programs, although you can't manipulate the scratchpad memory directly without copying it into a variable.

The current program does three things:

  1. It intercepts R/C receiver commands to the rudder, elevator and gear switch and translates them into computer commands, which drive the servos through a Parallax servo board or FT639 chip. When it detects that the gear switch has been thrown, it transfers control of the rudder and elevator to the autopilot program, and back again when the switch is returned to its manual position.
  2. When under autopilot control, it reads GPS coordinates and headings and translates them into directional vectors to the next GPS waypoint. It uses those vectors to steer the rudder.
  3. It also uses GPS altitude readings to do a crude sort of altitude hold. Because the GSP altitude data is so noisy, the autopilot averages over three readings and treats that as accurate +- 10 meters. It uses that data to adjust the elevator to try to keep the plane within a range of +- 10 meters of the original altitude at which it was put into autopilot mode.

The code has been tested on several different kinds of servo driver chips and GPS modules, as well as with GPS simulators, but not yet in the air. So consider it just instructional at this point. I'm sure there are some bugs, and a lot of settings that need to be tweaked. Also, we have not yet added camera controls and other more sophisticated in-air options, such as circle and hold (although these aren't hard to add, not that we've got the basic hardware interfaces working).

You can download the code at the following link. Load the first program (uav.bsp) and it will call the others at compile and download time.

The recommended hardware is a Basic Stamp BS2p on a dev board using the FT639 servo driver chip and a standard GPS module such as the EM406. Details on these hardware configurations can be found in the main post on this UAV. Other servo drivers, such as the Parallax board can be used, and the details on how to modify the code for them is in the comments of the code

-------------------------------------------------------
[Older code, no longer supported but may be useful for instructional purposes]
  • Code for the Parallax servo board and Parallax GPS module is here.
  • Similar code for the FT639 servo controller chip and Parallax GPS module is here.

Views: 1128

Comment by Simon Pan on January 28, 2008 at 11:06pm
Chris, is there a particular reason why you don't use a floating point coprocessor? It seems to solve some of your problems fairly effectively since it offers floating point math and more than doubles the available variable space.

I'm asking because I'm using it myself and I was wondering if there was a reason you WEREN'T using it, as opposed to not bothering to use it.

(Btw, I've been looking through your code and I can't find where you handle the commands from the Rx, which is something I've been trying to research lately)

3D Robotics
Comment by Chris Anderson on January 28, 2008 at 11:12pm
Simon,

You're right, I probably should be using the floating point co-processor. But I figured out how to get around that with the usual multiply-by-1000 trick and some standard approximations. So at the moment, I don't need it.

The Rx reading-and-retransmitting code is in the main UAV code. It looks like this:

PULSIN chan2in , HIpulse , chan2
chan2 = (chan2 */ scale)/2
DEBUG DEC chan2 ,TAB
SEROUT sdat, bauds+$8000,["!SC",ch2,ra,chan2.LOWBYTE,chan2.HIGHBYTE,CR]
Comment by Simon Pan on January 28, 2008 at 11:35pm
Ah, I see, I didn't see the "RUN 0" right after your if/then in the navigation program.

One more thing (Sorry I know I sound like a broken record), I don't understand why you truncate the degrees to 1 and -1. Can you not just omit the degrees entirely? My understanding is that with the rotated frame of reference, and assuming the UAV operates in only one quadrant (western, northern hemisphere), then there are no negative latitude/longitude coordinates.

3D Robotics
Comment by Chris Anderson on January 28, 2008 at 11:47pm
Yes, I could probably omit the degrees entirely, but I wanted to accommodate the possibility that the UAV could be flying on a degree boundary and pass from Lat or Lon (x).999 to (x+1).001 or something like that. I knew I wouldn't be going more than one degree, so a single digit to the left of the decimal was enough.
Comment by Josue on February 14, 2008 at 1:24pm
Is there a way to use an ATmega32 instead of the BS2 for the parallax GPS? If there is, can someone help me get some code for it?

3D Robotics
Comment by Jordi Muñoz on February 14, 2008 at 1:36pm
Yes, you have serial ports, 32KB of Flash, very good micro. You just need to adapt the code and thats all. Are you using c++ IDE?
Comment by Josue on February 14, 2008 at 3:06pm
I do have it. Any tips on the changes needed to make?

3D Robotics
Comment by Jordi Muñoz on February 14, 2008 at 3:35pm
Well the problem is we don't have a parse library like Basic Stamp, we need to do it Manually. Maybe my example help you out.
So you can see my GPS waypoint navigation is in C++ (and is compatible with parrallax GPS):
http://jordii07.googlepages.com/GPSwaypointv101.txt

Is based in this example, but this examples just read NMEA sentences (no navigation):
http://www.arduino.cc/playground/Tutorials/GPS

And the math is obtained from this example:
http://jordii07.googlepages.com/Waypoint-Math.pdf

If you need help understanding my IDE c++ command's you can use this arduino reference, explain everything i use in my code:
http://www.arduino.cc/en/Reference/HomePage

Letter i will release a gps navigation based on this source code of basic stamp.
Comment by Josue on February 14, 2008 at 6:51pm
Thank you very much. I will work from there. If I have any questions I'll come back. Gracias!!
Comment by Josue on February 15, 2008 at 12:30pm
It keeps asking me for a gps.pch file where can I get that?

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service