• For the ailerons, you'll need micro servos like the Futaba S3114s. When you're threading the servo extension cables through the wing, wrap the connectors with tape and taper the wrapping into the wire, to avoid connector edges that will catch on wing bulkheads.
• You definitely want steerable landing gear. There are a lot of good tips on how to do that in this thread. One of the things that stumped people was how to use servo mixing for the V-tail and still use the rudder to steer the nose gear. The answer is to use a VeeTail hardware mixer, with a Y-connector from the receiver going to the nose gear servo and the VeeTail input. The VeeTail board is also compatible with the UNAV PicoPilot autopilot, which we'll be using later.
  
• I used a Hacker A30-28S motor with an 8x6 pusher prop. I had to use 1/2" spacers to get it far enough back to clear the fiberglass rear cover. And even then I needed another 1/4" nut on the prop shaft to get the prop far enough back to clear the cover. (BTW, if you use the Hacker you'll have to trim away an eighth of an inch around the open in the back of the fiberglass cover to clear the prop mount.
  
• I made the wings removable. This involved putting little hooks in the side of each wing and drilling a corresponding hole in the fuselage on each side. A short rubber band, threaded through the fuselage with a paper-clip hook, keeps the two wing halves from falling off.
• I put two spruce rails on the bottom of the plane, just ahead of the landing gear (ie, right on the center of gravity) , and put screws sticking out them at the front and back sides of each. This will serve as our payload attachment point, and the screws sticking out are for rubber bands. It fits our stabilized camera mount beautifully.
• It remains to be seen how well the UNAV PicoPilot flies this plane. UNAV warns against planes with ailerons and little dihedral, which is the case here. Until I test it in autonomous mode, consider this just a very cool looking R/C aerial photography plane.
  

I was reminded by the Pict'Earth guys last weekend that one of the best all-purpose planes for carrying cameras, GPS recorders and any other sort of equipment you want to test is the Multiplex EasyStar, a virtually unbreakable powered glider. Because it's made of elastopore foam you can carve out the equipment compartment to carry pretty much anything you want, and the same foam protects everything in case of a "hard landing".

EasyStars are available for $54 without the radio equipment. This post is just a quickie to show you what else you'll need top make them good UAV platforms.

Although the kit comes with a brushed motor, I suggest you upgrade to a brushless so you can carry heavier loads with ease. This motor is a perfect fit and has power to spare. I matched it with this ESC. As always, you'll want Li-Ion batteries if you can afford them. An 11.1v, 2200 mAh pack will allow you to fly for more than half an hour under power. A 6x4 prop fits perfectly

For a radio, almost anything with six channels or more will do. The EasyStar has compartments pre-cut for servos; the HITec HS81s fit them best.

Finally, here's an important point. With the more powerful brushless motor, you'll find that rudder is really too small to be effective. You need to make it bigger to increase its "authority", which both helps in more extreme moves and at slow speed. The easiest way is to glue or double-sided-tape two business cards to the rudder. Here's a picture of one such mod (I didn't bother to trim mine as neatly as this guy did):

Once you've done all that you can shove all manners of cameras and such in the equipment area. If you don't want to carve holes in the bottom, you can always just bolt a camera to a bit of wood and strap it to the top, like this.

I'm posting this because I feel honestly conflicted about something that's come up. As readers of this blog know, one of my side projects is making Unmanned Aerial Vehicles ("drones") and the technology that goes into them. Everything I do is open source, and I share much of it here. There are also loads of other open source UAV projects, led by amateurs from Germany to Australia.

People often think of UAVs as military tools, whether as spy planes or Hellfire-launching robot weapons. We're hoping to change that perception by showing how useful UAVs can be for everything from commercial geomapping to scientific sensing. But the UAV-as-weapon concern is persistent, and many people have asked whether we, by making the technology available and easy to use, might be inadvertently be helping our enemies.

My usual response is that the technology is out there anyway, and by doing things in public we're just making it easier for authorities to know what's possible and who's working on it. Hezbollah already has UAVs, after all, and the technologies we use (which range from cellphones to Lego) are hardly export-controlled.

But all that came to a head today when I read the main UAV newsgroup, and saw that Amir Aalipour, an Iranian in Tehran, had posted some pictures of his swing-wing UAV (shown), proudly bedecked with the colors of the Iranian flag. He's been following the discussion in these forums for some time and now wanted to come forward with his own impressive work.

Part of me says "Bravo Amir! Excellent work on the airframe, and thanks for posting." And part of me says "Yikes. We're helping Iranians make UAVs draped in nationalistic colors. This isn't going to help us in our efforts to destigmitize drones."

Obviously Iranian != terrorist/bad guy/anti-Israeli zealot. And needless to say, most of the terrorist/bad guy/anti-Israeli zealots out there who are building UAVs aren't posting on RC Groups. But what should I do if Amir or someone like him from a country associated with Bad Stuff posts on our own forums looking for technical advice? My instinct is to treat everyone alike and help anybody who asks, regardless of where they're from (odds are Amir is just a geek like the rest of us, no matter where he lives). But how does this look to someone in Washington? We're just a pen stroke away from being regulated out of existence, and in this climate it's politically unwise to discount the Homeland Security card (my own feelings about that notwithstanding).

I know, that's an ignorant, xenophobic and paranoid reaction. And my first instinct is to pay nationality no mind. But as I say, I'm conflicted on this. What would you do?

[UPDATE: Amir himself responds in the comments of my other blog. He's 17 years old. Which makes what he's done all the more impressive.]

Photo of the real thing:

This weekend I was at the Google campus in Mountain View for the SciFoo scientific conference. My session was on using micro UAVs for mapping and scientific sensing, and I thought it would be fun to give a little demonstration. What better than a UAV mission over the Googleplex?

This was cool for a number of reasons. First, you may have noticed that the Google campus "satellite" view is much higher resolution than almost any other imagery on Google maps. (The way you can tell is to switch to satellite view, click on the "Link to this page" button, and then edit the URL so that "z=19" becomes "z=22", which is the maximum resolution available. Like this.)

Suffice to say, that imagery didn't come from a satellite. Instead I happen to know it was taken by a small aircraft with 5 megapixel cameras at 600 ft.

I wanted to do better. So at the crack of dawn on Sat morn, I was on a nearby field planning my mission.

Because I didn't have a runway to take off from, I used GeoCrawler 3, which can be hand launched. I wanted better imagery than the cellphone camera could provide, so I put the cellphone inside the fuselage (it would still do the GPS navigation) and strapped a digital camera to the bottom of the plane instead. I put in a few GPS lat-longs taken from Google Maps and off we flew.

It was a perfect day for flying, with virtually no wind and nobody around. I took off manually, steered the plane to north end of the campus at about 200 ft, and turned it over to the autopilot. Because I was so close I could see the plane the whole time, and truth be told I mostly did manual turning at the end of each run because we were in a built-up area and I didn't want to take the risk of missing a waypoint and losing sight of the plane, even for a few seconds. So to be accurate this wasn't a fully autonomous UAV mission, although the plane was capable of that.

The first pass was with a Pentax Optio A30, which is a small 10 megapixel digicam that supports an IR remote. I'd stuck an IR trigger board over the IR window on the front of the camera, connected that to my serial-to-servo board, and had the cellphone autopilot send a trigger signal to the board every two seconds (which is the fastest the camera will take pictures in remote mode). This worked great except for two things:

1. Two seconds is too long between shots. At the altitude and speed I was flying at, you'd want to have a picture at least every half-second to ensure overlap between sequential pictures. The field of vision of the camera at 200 feet at default zoom is about 30X30 feet and the plane flies at about 30 ft/sec. To make it possible for the mosaic software to stitch pictures together by comparing common features from sequential shots, you need no more than about 15 feet between pictures. (At higher altitudes, that distance is much greater, but you lose resolution proportionally).
2. Motion blur turned out to be a big problem. Pretty much all the pictures were unusable. It's clear that the default settings of the camera just won't do when it's in motion. We need a faster shutter speed, for starters, and even that may not be enough. I'll have to test the camera further to find out what settings both work in IR trigger mode and reduce the motion blur from the air, but I didn't have time for that on Sat morn before people started showing up.

So it was back to the launching point for a quick change to another camera. I swapped in the Pentax W30, which has a built-in time-lapse mode and doesn't need to be IR-triggered. I knew that the camera's minimum delay interval between time-lapse shots was an interminable ten seconds, which would make mosaicing the pictures impossible, but I hoped I'd at least get a few sample shots to demonstrate the high-resolution possible from these planes.

I'd previously tested the W30 from the air and found that it didn't have the same motion blur problem, for reasons that I don't quite understand (it's only a 7 megapixel, so perhaps its CCD processes the imagery faster).

Another launch, with the same starting points and path, and a quick return to check the imagery. This looked much better, so I took it up for one final series of passes. By 7:30 am we were done, and it was time to head into breakfast at the conference and admire the shots on a laptop. Here are some samples of what we got, with the same locations at the highest resolution on Google Maps as a comparison, and my with my imagery at about the same scale.

The advantages of the low-altitude UAV imagery go beyond the higher resolution. It's more recent, so, for example, you can see that since the imagery in Google Maps was taken, Google has put solar cells on every roof in the complex. That's great, and they deserve more credit for this. Updating their imagery to show the extent of it (see example below) would help.

You can also fact-check existing imagery. On Google maps, one of the campus's cool infinity pools has the company's logo at the bottom. In reality, it doesn't--the logo was photoshopped on:

(Real Googler's will spot the flaw in my data. What you're actually seeing in my images are the blue pool covers, not the water itself. But I walked over and lifted them up to confirm that the logo isn't there. Ground truth!)

All pretty cool. But before you get too impressed, remember that I can't tile these shots into a proper map because I don't have enough imagery. I just have loads of random shots of the campus from the air, which isn't really very useful. Next time I'm going to attempt to solve this with a Canon Digital Elph camera shooting in rapid-sequence mode, which is less than a second between shots. Canon's got some of the fastest CCD sensors and image processing chips around, so I'm optimistic that this will give me enough imagery for the photo-stitching software to take over and make a proper map. That, however, will require making a custom camera mount with a servo that can physically push the camera shutter button, because the Canons don't have IR remotes or anything else I can electronically trigger. This isn't too hard, but may take me a week or two. Stay tuned...

Finally, a note for anybody thinking of doing the same thing--don't. I checked this with the right people at Google, and they unofficially agreed to look the other way because I was flying a small (under 3 lbs) electric plane that couldn't hurt either buildings or people, and was doing the demonstration as part of scientific conference on campus. Google has lots of 24/7 security on electric vehicles, and you really don't want them coming after you. Plus there's those rooftop laser cannons ;-)

The chairman of the aviation committee for the International Association of Chiefs of Police... Donald Shinnamon... charges that the FAA is applying its rules inconsistently and defying federal laws about government-operated aircraft.

"There is an immediate need by state and local public safety personnel for unmanned aerial systems," he said at an unmanned systems confab here this week. But by his interpretation, the FAA's rules mean "it's OK to fly a model aircraft but not OK to fly an aircraft in search of a murder suspect" without its permission...

Local officials aren't necessarily looking for unfettered UAV [unmanned aerial vehicle]-driving rights, Shinnamon said. Ideally, the FAA will be able to work with state and local government officials to come up with UAV-specific regulations, which address things like how high the drones can fly, how far they can travel from their operator, and whether they need to be in the driver's line of sight.

"Once we overcome this regulatory issue, I honestly think the use of this technology will explode at the local government level because it offers just so many benefits to us and the ability to serve our citizens," Shinnamon said.

[L.A. Sherrif's Department Sid] Heal, whose office tested a drone last year but has not yet secured formal permission to use it, said he doesn't "detect any sense of urgency" on the FAA's part to make its regulations simpler for local officials to follow.

"We're going to do this; this is coming," he said. "And (the FAA) can jump on this train or they can run along behind it, but it is going to leave without them."

• Lego Autopilot: Tested FMA co-pilot sensor in new position on top of wing (worked much better), compass sensor in new position behind wing, away from the magnetic interference of the brushless motor. The test ended when autopilot stopped responding. Found two problem: the Lego motor had become dislodged from its mount (it's now screwed in to avoid this) and the software wasn't responding to "autopilot off" commands, for reasons that are neither clear nor repeatable. Given that we're porting all the code to Lua, we won't debug this. Also, the directional patch antenna that we're using on the ground for the video downlink just isn't doing the job, for reasons we don't understand. We'll go back to the stub antenna for now (at least nobody has to point it) while we diagnose the problem.
  
• PicoPilot UAV: This was just the first flight test of this autopilot, just checking the gyro-based stabalization. It seems to work great. Also tested the cute and light FlyCamOne micro video camera with a 2GB SD card. It worked great until an aborted takeoff, which dislodged it and mis-oriented it from the mirror that lets it look forward. So the black line obscuring the top of the video isn't its fault!
• Cellphone UAV: This was just a stabilization test of the FMA co-pilot with the sensor in the under-body position. It didn't work as well as the Lego UAV's wing-mounted position, so we'll move it above the wing in this UAV, too.
• Predator UAV: First airframe test, under manual R/C command. Flew okay, but needed a lot of down elevator and otherwise felt sluggish. Later diagnosed as a thrust angle problem, due to motor bulkhead being tilted up. Have now reseated bulkhead to fix. Also had a pretty gnarly landing due to a tip-stall at low speed. Will land under power from now on; this plane doesn't like to go too slow.

• Wiimotes (shown) have a three-axis accelerometer and an infrared sensor.
• An iPhone has an accelerometer and a light sensor
• My laptop has tilt sensors (to take the hard drive read/write head off the platter when the laptop moves)

It's been amazing to watch how computer technologies have revolutionized the R/C aircraft world. The combination of high-efficiency brushless electric motors (first developed for DVD drives), lithium-ion batteries (developed for laptops) and spread-spectrum digital radio (popularized with WiFi) have created a class of small, quiet electric planes that are every bit their old noisy gas-powered predecessors. AMA membership is down even as R/C flying is booming because you don't need to go to a AMA certified field or join a AMA club to fly anymore. Today's planes are quiet and safe enough to fly in most parks.

More and more military UAVs are using this same technology, most notably the Raven, which is the most common UAV found in Afghanistan. (it uses a brushless electric and LiPo combination similar to that you can buy from any hobby store.)

Now, inevitably, the same revolution is coming to full-size planes. At Oshkosh, Sonex unveiled a prototype electric one-seater. From a Green Car Congress post:

"Since 1994 and Flash Flight’s feasibility study, the popularity of radio-controlled (RC) electric powered toy vehicles, gas-electric hybrid cars, and the boom in wireless electronic devices such as cell phones and PDA’s have pushed the state-of-the-art in battery, electric motor and controller technology.

Brushless DC cobalt motors are now lighter and more efficient. Advances in microprocessors have allowed motor controllers to be smaller, lighter and more efficient. Lithium Ion and Lithium Polymer battery technology has pushed the endurance, efficiency and power output of electronic devices, while shrinking in physical size and weight. The Sonex R&D team concluded that the time for this endeavor had arrived.

E-Flight’s proof-of-concept prototype will use the flight-proven Waiex airframe, flown single-pilot only, so that the emphasis can be placed solely on powerplant research and development. Initial top speeds will reach approximately 130 mph, and endurance is expected to range between 25-45 minutes or longer, depending upon power usage on each individual flight."

The search engine giant announced the move Friday on its LatLong blog about Google Earth and its other mapping efforts. It didn't disclose terms of the deal.

"We're excited about how ImageAmerica's technology will contribute to our mapping services down the road," Product Manager Stephen Chau said on the blog. "Since we're in the research and development phase right now it may be some time before you see any of this imagery in Google Maps or Earth."

ImageAmerica supplied Google Earth with high-resolution aerial photos of New Orleans after Hurricane Katrina struck in 2005.

According to older pages from the Internet Archive's Wayback Machine, Clayton, Mo.-based ImageAmerica specialized in creating aerial photos with "accuracy, quick delivery and low cost," selling primarily to city, county, state and federal governments and to corporate customers. In addition to developing its DDP-2 (Direct Digital Panoramic) camera system, the company has its own aircraft to house it. The high-resolution camera can capture details as small as 6 to 12 inches, and the company's processing system can produce orthorectified imagery that's been corrected for perspective distortions.

Here at DIY Drones, I've been working with other amateurs to create open technology platforms to make it easier for more people to build their own UAVs (for aerial imagery, high-res Google Maps mashups, contests and other flying robot fun).

The good news is that there are a lot of programmers out there happy to donate their time and talent to helping these project along. The bad news is that each of them has their own favorite programming language, and it's up to the organizer (ie, me) to somehow weave them all together into something useful for newcomers. Which means that the job of crowdsourcing software development requires the organizer to become a Rosetta Stone of software styles, which is tough if you're not a hard core programmer yourself. And I very much am not.

Let me give you an example: Our UAVs are using software written by at least 10 programmers, each of whom has contributed something valuable. The problem is that the various elements are all in different languages: NXT-G, Lua, Visual Basic, Python, Stamp Basic, LabView, C, and Parallax's Spin (for the Propeller chip).

It's not surprising that volunteers want to use their own favorite programming languages, and because they're volunteers I'm in no position to tell them what language to use. If this were just an open source software project, I imagine we'd just be pulling from within a community of people using one language. But because our UAV projects cross so many disciplines--software engineering, hardware engineering, robotics, R/C planes, GPS hacking, aerial photography and Lego, to name just a few--it's a programming language Tower of Babel.

Right now I'm porting the NXT-G autopilot to Lua, so I can integrate it with the Blutooth GPS code. This is after having already ported it to LabView to get access to floating point math. I'd like to combine our Widows Mobile cellphone autopilot with the cool GPS-tagging and image-sending of the Pict'Earth team, but they're using Python on a Symbian-based Nokia N95 and our Windows Mobile code is VB.net. Meanwhile, I'm going to port our Stamp Basic autopilot to Spin, so we can use the more powerful Propeller chip, but to include gyros or accelerometers, I'll have to also port the open source inertial guidance software, which is written in C, to Spin.

And did I mention that I'm not a real programmer and the last language I was really comfortable in was Pascal, back in the 80s?

So that's the problem with herding an army of technology volunteers. Someone has to serve as the universal translator so that everyone's contribution works together. And that someone has to be a technology polymath, sufficiently fluent in all languages and dialects to be able to do that well. How many such people exist? Not enough.

In my quest for the perfect pan-tilt gimbal assembly for a small UAV, I've made one out of Lego and have some clumsy ones out of aluminum. Most commercial pan-tilt assemblies are made for much larger cameras than the ones we fly, or they're incredibly expensive turrets meant for military and commercial UAVs. But I've hunted around and found three that appear to be within our size, weight and price range. How do they stack up?

• The Lynx B Pan & Tilt kit ($35.93 with servos)
• The Budget Robotics Pan & Tilt Turret for sensors ($34.95 with servos)
• The Pandora Pan & Tilt assembly ($29.95 without servos; servos will for you another $20 or so)

First, some general notes about all three. The most important thing is something you can see from the picture. The first two are designed for standard size servos, which are a bit big for our UAVs. Only the Pandora gimbal is designed for mini and micro servos. It's also the only one specifically designed for the Panasonic KX-131 video camera (shown) that is commonly used in R/C aerial videography, and is the core of the RangeVideo system we use. I haven't shown the other two with the KX-131 mounted (it's a pretty simple matter of drilling some holes or using double sided foam tape), but you can see that it would make them much taller than the Pandora system (they'll stick out almost twice as far).

The other two are intended for hobby robotics, where weight and size is not as big an issue as it is on planes. Indeed, the Budget Robotics assembly isn't meant for cameras at all (it's intended for infrared sensors), although it works fine for them.

Another thing to keep in mind is that most of the stress in supporting a camera assembly is felt by the lower "pan" servo, so they tend to be bigger than the "tilt" servos (except in the case of the Lynxmotion one, where both are pretty beefy)

Here are the basic stats.

Weight (with KX-131)_____Max tilt degrees (all have 90 deg pan)

• Lynx ___________130 grams____________90
• Budget Robotics _120 grams____________90
• Pandora ________70 grams ____________60

Most of the difference in weight is in the size of the servos. The other main difference is that the Pandora's actuator arm, which allows it to have such a low profile, also limits the tilt range to just 60 degrees unless you overdrive your servos with some transmitter programming. That's a trade-off that may be worth making, but it's important to know all the same.

Here's a video of them all in action:

For my money the Pandora is the way to go. It's much smaller and lighter than the other two, and I can live with the reduced range. It's more complicated to assemble (although I cheated and used superglue to accelerate the process), but worth it in the end with better flexibility and installation options.

I'm still planning to make an aluminum clone of the Lynx gimbal but for mini/micro servos, and we'll see how that goes. The Lynx gimbal is a really nicely machined aluminum kit, and for something heavier than the KX 131, it's the best way to go. The only one that didn't stand up well is the Budget Robotics kit, which to be fair isn't designed for cameras at all. Its sensor/camera platform isn't supported on both sides like the Lynx's is, and I'm worried that this will lead to shaking in the air due to motor vibrations.