Surprisingly, Atkins adds that during takeoff, the UAV is blind. “The plane takes no measurements of its surroundings. The waves would confuse it. ‘Most people wouldn’t do it this way,’ Atkins said. ‘The plane puts the motors on at full throttle and sets the pitch elevator enough to break out of the water. Then it counts and pitches forward. We believe that if we had done it any other way, we would have basically dived into the ocean on takeoff because the plane would have detected huge oscillations due to the waves.’”

• Part 1: Controlling servos with a Basic Stamp
• Part 2: Reading RC commands
• Part 3: Connecting a GPS module
• Part 4: More on connecting a GPS module
• Part 5: GPS simulation 1
• Part 6: GPS simulation 2
• Part 7: GPS simulation with Microsoft Flight Simulator 2004
• Part 8: Adding a failsafe board

1. They're basically the same model, from Haoye Models.
   
2. The one from Singapore was rubbish, unpainted and missing all sorts of necessary parts such as the carbon fiber wing rods.
3. The one from Sonic Electric looks better, with painted body parts (gray elements in the picture at right), and most of the necessary elements. Go for the combo pack, with motor and ESC, if you don't already have spare equipment to use.
4. There's not a lot of room in the equipment bay for autopilots, cameras etc. This is foam, of course, so some cutting is possible, but it's going to be a tight fit. This is NOT an ideal UAV plane, but in the interest of equal scale opportunity (we've been showing Predator favoritism!) I'll have a go anyway.
   

[UPDATED: paper is finished and available below]

I've put together a technical assessment white paper for the FIRST robotics league, proposing an indoor aerial robotics contest for 12-17 year old kids (and coaches). Target price is under $1,000 and safety is of prime importance. This paper lists the possible platforms--microplanes, helis, quadcopters and blimps--and discusses the pros and cons of each. At this point I've tried most of the options, from helicopters to quadrotors to blimps to ultralight planes and I'm leaning towards quadcopters and blimps as the best choice.

• Quadcopters: Pros: very maneuverable, already have a full IMU onboard. Cons: very expensive to do well, hard to fly, can do damage to vehicle or people when things go wrong.
• Blimps: Pros: cheap, safe, easy to fly. Cons: hard to maneuver precisely, requires inflation, can't lift much weight at indoor size. Cheap UAV versions neither commerically available nor open sourced.

Cost, simplicity and safety pushed me towards the blimps, but I'm concerned about having the kids having to build the autopilot from scratch. Check out the draft of my white paper and tell me what you think.

• Doesn't need special calibration and doesn't drift. "Down" is alway down.
• Much cheaper. Without the gyro, the cost drops from $100 to $25 (two servos and some aluminum)
• Doesn't take up a separate channel. The camera stabilization automatically comes on when I turn on the plane stabilization.
• Saves power because the tilt servo isn't always jittering with every gyro twitch.

1. Israel has UAVs in the air 24/7, mostly on its borders. Unlike the piloted Air Force squadrons, where most flights are training, 90% of UAV missions are "operational", meaning that they're actually tracking targets and watching for bad guys.
2. They've been working to eliminate "flying" altogether. The UAVs take and land themselves, and "R/C" piloting skills, which were once prized, are now discouraged. It simplifies the training, lowers costs, and mimimizes human errors. Often the joysticks are linked only to the camera, and the aircraft is only guided by clicking on a map.
   
3. Another advantage of a small country (about the size of New Jersey): all the UAVs above hand-launch size are launched from Air Force bases like this one and communicate with the ground with direct radio links. No need for satellites. They can usually get an aerial camera on any spot along the boarder within three minutes. Aerial imagery is shared between Army and Air Force in real time, so there are few of the intramural battles the US has over chain of command and airspace control.

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

• Basic Stamp autopilot code. [Latest version]

• 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.

We love GoogleMaps, but one of the problems with it is that you can't really add your own data to it. Sure, you can superimpose your imagery on a GoogleMaps layer, but it won't show unless people use a special URL. That's the reason for the creation of OpenAerialMap.

Pict'Earth's Jeff Johnson explains:

"OAM gives us a place to publish the imagery so that it easily reused. Basically the imagery that Google and MS Aggregate is not truly 'free' in the sense that it cannot be used in any useful sense outside of their programs without an overbearing license. Its kind of like Navteq or Teleatlas data. It may be freely available, but its not really free. So then, the goal of OAM is to provide a place where people like us (doing DIY stuff) can publish our imagery in a central place, but also a place for governments and other organizations that pay for imagery to get help publishing their data into the public space in an open/free way."

O'Reilly's Brady Forrest has great post that explans more here. (He also mentioned that I'm going to be giving a DIYDrones presentation at ETech on March 3-4 in San Diego. More on that later.)

You can see one example of one pass I took of the Alameda Naval Air Station runway that was orthrectified and stitched by Pict'Earth and is now part of the standard OAM map at that lat-lon (our imagery circled in the screen shot above).

(credits: Christopher Schmidt set up OpenAerialMap and the servers are hosted by Telascience, SDSC and bandwidth comes from CalIT)

Tarbert says it's possible that some regulation recommendations could be produced by July 2008, although he calls that "a big, big if." Even then, a Notice of Proposed Rulemaking wouldn't "hit the street" until a year later, and a public comment period of 90 days would follow after that, so any regulations likely wouldn't come into play until the middle of 2010.

One problem is that there's no definition yet for what a small unmanned aerial system is. MITRE Corp. has taken a stab at defining it for the FAA, and Charlotte Laqui, the UAS project team leader for the company, also spoke at the Wednesday meeting.

Stressing that the definition is just a "starting point," and certainly hasn't been accepted by the FAA, Laqui says MITRE has roughly defined possible operations for two classes of small vehicles.

One would have a maximum weight of four pounds, a flight ceiling of 400 feet above ground level and could fly in all classes of airspace. Such vehicles could fly over even heavily populated areas without posing a big risk to people on the ground or other vehicles in the air. Another class of vehicle could weigh up to 35 pounds, fly up to 1,200 feet above ground level only in Class G, or uncontrolled, airspace. Those vehicles would pose an acceptable risk in more lightly populated areas.

Vehicles could not operate within three miles of a chartered airport and would have to be kept within sight of the operators, she says.