Blogs

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

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.

Hello everyone, I have just found this site and looked at a few of the pages. I have wanted to get into the small uav type aircraft so this site is just what I have been looking for. I have just purchased a Hobbico NexStar but have not yet made the first flight, except on the simulator. This is the gas powered version and is slightly larger the the ElectriStar being used here. I have looked at the huge open bay where the RC system is and I know there is a lot of room to install more stuff. My main interest is in doing aerial photography so I am also looking at cameras and such.

As for me, I am now 53 and living in Bradenton Florida. I have spent the last 22 years working as a computer programmer. I am an Army brat so there is no real hometown, the high school I went to is in Japan.

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.