Here's a semi-scale Predator. Pretty cool, but it's an ARF so I can't do too much bragging. I just modded an inexpensive ($80) Nitro Models kit with a AXI 2208 brushless motor and added some proper landing gear and an airscoop to cool the motor in the back. (BTW, Nitro sells two Predators. Get this one, not the similar camo version with a slightly smaller wingspan. That one's wings don't come off! I have no idea how you're supposed to transport it, short of a van).

But there's more to this Predator than meets the eye. It's not just a model of an Autonomous Aerial Vehicle--it is a UAV! How can you tell? Look closer.

This is a Pentax W30 camera, which is one of the smallest cameras to have a proper programmable time-lapse photography setting. Why would I want to strap a camera with a time-lapse function to the bottom of a R/C plane? Because it's not just a R/C plane!

Here's what's under the canopy, or at least the first layer of it. It shows the installation of a UNAV Picopilot GPS-guided autopilot. This makes the Predator totally autonomous. You can enter up to 20 GPS waypoints, and the Predator will fly to them and then return home afterwards. That, in turn, explains the time-lapse camera. It snaps a 7 megapixel picture every ten seconds while the UAV is following its programmed course. Which means that you can stitch those pictures together and create a super high-quality aerial view of any area you choose. They're WAY better than Google Maps resolution, and you can update the aerial views anytime you want to.

But how can you take off and land the Predator? The Picopilot can't do that. Fortunately, there's another layer in the Predator's electronics bay.

Underneath the autopilot floor, there's space for all the standard R/C stuff: A Futaba 2.4 GHz receiver, a 1,500 mAh Li-Po battery and an electronic speed control. When the transmitter's gear switch is down, this lower layer controls the plane manually. When you switch the gear lever up, it transfers control to the Picopilot and the Predator goes into autonomous mode. Just like the real thing!

From Army Times:

WASHINGTON — The use of unmanned aircraft in Iraq has surged by nearly one-third since the buildup of U.S. forces began early this year, and drones are now racking up more than 14,000 hours a month in the battlefield skies.

The increase in unmanned aircraft — from high-altitude Global Hawks to short-range reconnaissance Ravens [shown] that soldiers fling into the air — has fueled a struggle among the military services over who will control their use and the more than $12 billion that will be spent on the programs over the next five years.

The Air Force wants to take over development and purchasing of unmanned aerial vehicles, arguing that it would save money and improve technology and communications.

It also wants more centralized command of the drones, saying better coordination could eliminate airspace conflicts that can endanger U.S. troops.

The other military services see a power grab, and they’re fighting it.

A little more than a year ago, about 700 unmanned aircraft were operating in Iraq. By last December, according to Army data, that number had grown to about 950, and it’s soon expected to hit 1,250.

At least 500 are the smaller Ravens that are used by the Army. The rest include Hunters and Shadows — the Army’s medium-altitude aircraft that can carry weapons — as well as the Air Force Predators, which are also armed. Larger Global Hawks are used for high-tech surveillance

Continue reading here.

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

Great news on the Lego UAV front. Ralph Hempel, who has been helping me on adding GPS waypoints and navigation to my Mindstorms Autopilot, has cracked the tricky bluetooth integration code problem. Just the review the challenge, it appeared that the easiest way to connect the Mindstorms NXT CPU with a GPS receiver is via its bluetooth interface. But the native NXT bluetooth stack and API is very limited, and we couldn't find a good way to do it in the native NXT-G language.

Ralph cracked the problem by using pbLua, a more powerful language that has been ported to the NXT. He's got a great post to show how it works here. He's also included a GPS parser, so the only remaining challenge is the port the rest of the autopilot code to pbLua and write the navigation routines that turn the GPS location information and directional vectors into rudder commands to reach the next waypoint. That will probably take another month or so, during which we'll continue to fine-tune the basic platform stability using the current compass-based autopilot that's already working.

From the MAKE blog:

Here is a link to pictures of an attempt by a group of Calpoly engineers to have a UAV glider bring back pictures from 100,000 feet. After some sleepless nights and an overwhelming amount of work on hardware and software we launched a glider in California Valley. The balloon reach about 31,000 before something caused it to cut away, possibly a strong downdraft caused the code to cut the glider from the balloon thinking the balloon prematurely popped. We latter found the fuselage and one wing of the aircraft near Bakersfield, thanks to a friend with a Christian Husky and GPS tracking on the APRS network.

• Airframe: Nitro Models Predator ($80, modded with an AXI 2208/34 brushless motor, $70)
• [UPDATE] I crashed that version, in part because the V-tail just isn't enough control by itself and in part because the AXI wasn't enough power. I've now moved back to another Predator model ($67) which has ailerons, and given it a more powerful Hacker A30-28s motor. My post on how to build and enhance it is here. If you do decide to stick with the original Predator without ailerons, you'll probably want to cut off a few inches of the tail, put in a proper motor bulkhead and give it a more beefy outrunner like the Hacker. You might want to extend the area of the V-tail control surfaces, too. It really is hard to control as it is.
• Autopilot: AttoPilot, the most powerful under-$1,000 autopilot.
• Imaging: Pentax Optio A30, which is the smallest high-res camera I've found that allows for IR shutter trigger, plus a Prism R/C-controlled IR trigger. (both are around $200). This is also good candidate for the DIY stabilized camera mount described here, which doesn't require the Prism trigger, although note that you'll need to build the version with the Futaba "Pilot Assist" sensor, since this UAV doesn't use IR stabilization.

From Wired's Danger Room blog:

"The number of flying robots in the American armed forces' arsenal has gone up by nearly 1400% in four years, military documents show. A relatively-modest unmanned fleet of 217 machines has grown into a 3211-drone armada.

Most of the change has come in small, handheld unmanned aerial vehicles (UAVs) -- ones weighing 10 pounds, or less. In 2002, there were only 90 of the machines, used to peek around a corner or over a hill for enemy activity. By late last year, there were over 2800. The most popular of these UAVs in the Army's three-foot-long Raven. It weighs about four-and-a-half pounds, and good, hard toss will get it airborne, where it can loiter for a little over an hour, at nearly 1000 feet."

Read more here

Description: The main aim of this project is to both make the world's cheapest full-featured UAV and the first one designed to be within the reach of high school and below kids, as a platform for an aerial robotics contest. Like the Lego FIRST league, but in the air.

(There is another aim of this project, which is more about policy. At the moment the FAA regulations on UAVs are ambiguous (we believe that by staying below 400 feet and within line-of-sight we're within them). But there is a good deal of concern that as small and cheap UAVs become more common, the FAA will toughen the rules, making activities such as ours illegal without explicit approval. I hope this project will illustrate why that approach won't work.

By creating a UAV with Lego parts and built in part by kids, we haven't just created a "minimum UAV", we've created a reductio ad absurdum one. If children can make UAVs out of toys, the genie is out of the bottle. Clear use guidelines (such as staying below 400 feet and away from tall buildings) would be welcome, but blanket bans or requirements for explicit FAA approval for each launch will be too hard to enforce. The day when there was a limited "UAV industry" that could be regulated are gone.)

Features: In GPS mode, unlimited pre-programmed waypoints, with programmable options such as circle and hold. Ability to integrate other sensors, such as ultrasonic, compass, gyros, accelerometers, or barometric pressure (altitude). With optional bluetooth cellphone integration, control via text message, including dynamical-changed GPS waypoints, "come home" and "circle" commands, etc.

This is the most complete UAV, so I'll start the instructions here from the beginning:

1. Learn to fly R/C planes! These UAVs don't take off or land by themselves, so you've got to be a competent pilot. If you've never flown before, I suggest starting with a Hobbyzone Firebird Phantom ($60). Once you've got the hang of that (you'll crash a lot when you start, but it's tough and can take it), you may want to upgrade to the Hobbyzone Aerobird Swift ($150), which has an elevator and ailerons and will get you really ready for proper planes. Don't worry if you total this bird; we'll be able to use its radio system later.
2. Get the UAV airframe: a Hobbico NexSTARr (68" with radio and motor, $429).
3. Autopilot: I'll assume you've already got Lego Mindstorms NXT. For the basic version of the UAV you'll also need a compass sensor. You can see how the whole thing works here (it's easy to build the mechanical assembly, which is quite simple. Just remember to screw the base pieces into the airplane's plywood servo floor so they don't move. Full details and diagrams are here.) Here's a video of it working: Here's the Mindstorms NXT-G code: Main, Subroutine (download both). Or, if you prefer RobotC (I do!), here's the code in that. The GPS version is also working and you can download the beta of it (RobotC version) here. If you're using GPS, you'll need a Bluetooth GPS receiver. Might as well get one that has logging, too, so you can see your course in Google Earth. The i-Blue 747 ($70) is recommended.
4. For stabilization, use the FMA Direct FS8 Co-Pilot, which uses infrared sensors ($115). Put the sensor on the top of the wing, as the instructions suggest. It works better there than on the bottom of the plane.
5. You turn the autopilot on and off with a servo strapped to a touch sensor. This video explains how.
6. For video, use the Range Video Aerial Video System 2 (camera, rx and tx, $365; pick the "portable video" option, which gives you a rechargeable battery on the receiver).
7. You can build a pan-tilt camera mount out of Lego and your two spare servos, like this. Here's a video of it working: Use a spare transmitter and receiver to control the pan-tilt,and power it with this Li-Ion battery ($18). I assembled the whole video downlink assembly on the back of the Electristar battery door, like this. (that's showing a different receiver and battery pack, but the concept is the same.)
8. For recording and viewing the video, you'll want a video capture card for your laptop. There are several available options, but if you have an ExpressCard slot, I recommend the Avertv Express MCE.
9. It's hard to see many laptop screens in daylight, so you might want to get one of these screen shades.
10. Later, we'll add the cellphone for real-time GPS waypoint uploading via SMS.

Notes:

Many people have asked why the Lego autopilot moves the whole servo back and forth, rather than just controlling the servo arm the way a R/C receiver would. There are two answers to this: 1) we always want to have a manual override, so in this case you can manually control the rudder servo arm even as the autopilot is moving the whole assembly back and forth to control the rudder another way. 2) there is no good commercially available way to communicate directly from the NXT brick to a R/C servo. That said, there are some products in development that will make this possible. Stay tuned....

1. I've updated the GeoCrawler 2 (Lego UAV) instruction page. It now has a list of steps and parts necessary to complete the compass-sensor version of the UAV. The GPS version software is still in development. That should be ready later this summer.
2. I've switched GeoCrawler 1 (Picopilot UAV) to a more appropriate airframe. It's now flying on a Mini-Telemaster (shown), which is an inherently stable 3-channel trainer. We may someday move back to the Predator airframe, but we need to ensure the autopilot is rock-solid before putting it in a more challenging airframe.
   
3. Development on GeoCrawler 3 (cellphone-based UAV) is now in the alpha software stage. The code is able to control the servo and read the GPS coordinates from the phone. Now working on parsing the SMS command set and turning heading information into rudder commands. At a later stage we'll incorporate a GPS-based altitude hold by using the phone to control the throttle as well. Yes, I know GPS altitude readings are pretty approximate, but if you average them over time it's good enough for the +-10m that we need.
   
4. I'm working on a new pan-tilt gimbal for GeoCrawler 1. Because the plane is smaller than GeoCrawler 2, it will be made out of aluminum and modeled after this simple Lynxmotion design (but for micro servos, not standard size)
5. We lost our flying field at the Alameda airfield due to environmental remediation. Now scouting new airfields in the Bay Area.
   

My kids and I actually had the first successful test flight of the sub-$1,000 UAV two weekends ago, but I haven't had time to edit the video properly until now. The good news is that a) it didn't crash, and b) it works. We tested stabilization, autonomous navigation (only using compass headings this time, although GPS is in the works), and the real-time video downlink. Everything worked well enough that we're able to see what we have to improve, which is the definition of a successful test.

Just as a reminder, this is a R/C plane that's been modded into a proper drone. It's got a Lego Mindstorms NXT autopilot, a Lego pan-tilt camera, and an infrared autostalization system.

Here are some video clips from that flight (we're still getting the hang of filming a small plane in flight, so please forgive the distance and shakiness, too): The only thing you can kind of make out about the flight characteristics in the brief part where the you can see the plane in the air is the distinctive "crabbing" behavior as the autostabilized ailerons fight the autopilot-steered rudder. This is normal and is just an artifact of the way I designed it, with stabilization and navigation as two separate systems that don't communicate with each other. It still turns as intended, it's just a little graceless about it.

Finally, a word on why we're doing this.

The main aim of this project is to both make the world's cheapest full-featured UAV and the first one designed to be within the reach of high school and below kids, as a platform for an aerial robotics contest. Like the Lego FIRST league, but in the air.

But there is another aim, which I ended being asked about a lot at Maker Faire. At the moment the FAA regulations on UAVs are ambiguous (we believe that by staying below 400 feet and within line-of-sight we're within them). But there is a good deal of concern that as small and cheap UAVs become more common, the FAA will toughen the rules, making activities such as ours illegal. I hope this project will illustrate why that approach won't work.

By creating a UAV with Lego parts and built in part by kids, we haven't just created a minimum UAV, we've created a reductio ad absurdum one. If children can make UAVs out of toys, the genie is out of the bottle. Clear use guidelines (such as staying below 400 feet and away from tall buildings) would be welcome, but blanket bans or requirements for explicit FAA approval for each launch will be too hard to enforce. The day when there was a limited "UAV industry" that could be regulated are gone.

May 13th, first test flight of both the Lego UAV and the stealth "minimum" UAV at Alameda Naval Air Station. Video coming soon.