In my focus on the Lego UAV, I forgot to mention that I've also uploaded the Visual Basic source code for our cellphone autopilot. It's in pretty good shape, and just needs a little more tweaking for reliable airbone use. If you're comfortable with Visual Studio and Windows Mobile, this is a great starting point for cellphone-based aerial control, communications and imaging. The code is here.

Anybody recognize where I stole the image that is on the program's opening splash screen? (Shown here on the Windows emulator. Weirdly, the emulator blocks screen shots, so I had to photography the screen. Apols for the poor quality...)

You may have missed it in the discussion threads at left, but Howard Gordon has been doing some terrific work combining his robot and camera control boards with UAV platforms. The latest uses the quadcopter platform that the X-UFO/X3D guys in Germany developed. Check out his full post here.

Keep us posted on your progress, Howard! (Here's hoping you'll offer the components for sale, too, once you've got it done.)

An amateur UAV maker in Los Angeles built a UAV designed to fly 21 miles, from Long Beach to Catalina Island and back. It was notable especially for having the motor moved to a pylon above the wing and a pan-tilt gimbal camera put in the nose instead (see picture). This thread about it on RC Groups is a great introduction to high-end UAV making, diminished only by being a few years old (and I don't know if they ever had the courage to attempt the flight. Given the costs--nearly $4,000--it would have been an expensive loss at sea if anything went wrong)

Anyway, in this post he provides a spreadsheet of all his costs. It's very instructive, and most of those costs have not changed in the past three years. Small sample below; full version here.

Tom Pycke, who is one of the more sophisticated UAV hobbyists, has a good post showing how to use the open-source Flight Gear simulator program to test your autopilot code.

He begins:

"A lot of people think they need great electronics skills, a lot of time, and embedded programming skills to experiment with Kalman filtering of IMU-data. Think again! The key to all your success stories is simulation!

One of the easiest tools that can help you with those simulations, is a great flight sim called Flight gear. It uses advanced aerodynamics simulation libraries, among which some were created by the NASA. Good enough for our purposes! On top of that, you can easily configure Flightgear to log all the data you need. I updated my config file to log the following variables:

• Roll
• Pitch
• Acceleration along the 3 axis
• Gyro reading along the 3 axis
• Heading
• Airspeed"

He includes sample VB code, too (yes, you can code a Kalman in VB!). Read it all here.

The cover of MAKE magazine this month is a how-to on "blubberbots", which are small indoor blimp UAVs (story only for subscribers for the moment--subscribe! It's worth it). You can buy a kit from the MAKE store for $99 that will allow you to build a limited UAV--it heads towards lights and has a bump sensor to retreat when it hits walls. But how much harder would it be to give them real navigation abiliites, triangulating off IR beacons or even using GPS (if your roof isn't too thick)?

Oh, and the back page feature of that issue is on me and my Lego UAV (blush).

Here's a picture of the CPU and motor assembly from the creator's website, where there are several other Autonomous Light Air Vessels (ALAVs) and robtics projects:

These scientists describe their UAV project at the South Pole. Sound familiar?

"Flying a mission is always a little scary. Tom, the project engineer and pilot, stands by with his remote control and flies it a little until a stable flight is acheived, then we engage the autopilot. The plane then turns and heads off into the distance, disappearing from view after about half a mile, and dropping out of radio contact with its computer base station after four miles or so. That part of the mission is the most scary, as we've nothing to do but wait for fifteen minutes biting our nails as the plane follows its plan.

We breath a sigh of relief when we regain the signal and see some coordinates on the screen, but only declare success once we've seen the machine, taken it smoothly back down to the snow, and downloaded the data its recorded."

Play around with Lego Mindstorms NXT enough and at some point you'll inevitably get frustrated with NXT-G, its graphical programming language of "blocks" that you drag around and connect with "wires". It's great for teaching kids the basics, but once they embark on anything remotely ambitious they're bound to run into trouble. Whether it's the crazy sprawl of blocks over the work area (even a simple loop can require screens of slow horizontal scrolling), the lack of floating point math or, perhaps worst of all, the total absence of debugging tools, sooner or later you're going to start longing for a proper programming language that uses, you know, text and stuff.

"if...then...else", "while", even "for...next" -- you won't know how much you actually like those constructs until you don't have them. For anyone who's ever programmed, there's nothing better for understanding programming logic than properly tabbed and commented code, all in a column of text as God intended. And for your kids, there's no time like the present to introduce real programming, using coding conventions that will be as relevant in the decades to come as they were in decades past.

The good news is that there are lots of replacement text-based languages for Mindstorms NXT, from Java to Lua (or, if you want to stick with visual programming, you can also use LabView, the professional-grade language that NXT-G is based on). Even better news: I'm here to tell you that one stands out from all the rest.

It's RobotC and it's simply fantastic. If you're not a C programmer, don't worry--aside from a few grammatical conventions, it could be BASIC. But where it really stands out is in the programming environment. RobotC's integrated development environment (IDE) includes real-time syntax checking, compiling and contextual help and auto-complete of functions and variables. It has an awesome debugger, allowing you to step through your program, set break points and watch variables, or just watch the code executing on the NXT brick. And its collection of instructional and sample programs is unmatched in the Mindstorms world.

To give you of sense of this, here's my Lego UAV code in NXT-G (here and here) and in RobotC (here).

RobotC got its start at Carnegie-Mellon, the nation's top robotics school, and the pedigree shows. But special credit should go to Dick Swan, who authored much of the current program. (Dick, get a home page so I can link to you!)

For the stuff that we're now doing, including integrating GPS via Bluetooth, there's nothing for Mindstorms NXT that can match RobotC for flexibility and ease of use. Plus if you want to teach your kids real programming, why not introduce them to a real programming language? C leads to C+, C++ and C#, which is a lot more than you can say for Java ;-)

(Aside: as I was re-teaching myself how to program in C, I was reminded about the funny logic of computers. -100 is > than -90. Is this true in all languages?)

If you ask me, this is better than NASCAR. The DARPA Urban Challenge (robot cars race though a town) is being webcast live now.

Very well done live video is here, with color commentators, helicopter views and tons of team cams. Go Stanford (pic)!

How long till we see something like this for UAVs?

"Not even the bucolic Berkeley hills are immune to security concerns in a post-Sept. 11 world, as the editor in chief of Wired magazine has discovered.

Chris Anderson, a 45-year-old Berkeley resident and aerial-reconnaissance enthusiast, sparked a minor security scare Sunday when his remote-controlled plane - equipped with a camera - crashed into a tree at Lawrence Berkeley Laboratory.

Security personnel apparently didn't notice the plane until Anderson asked for help retrieving it, but they've taken notice since.

UC Berkeley police are investigating and federal authorities may be notified about the breach at the hillside lab, which is owned by the U.S. Department of Energy and managed by the university. Unlike UC-managed labs at Livermore and Los Alamos, Berkeley is not involved with nuclear weapons and does not conduct classfied research.

It does have important equipment that needs to be protected, said Dan Lunsford, who manages lab security.

"I think, post-9/11, when we see an event that is out of the ordinary, those are things that gain our interest," Lunsford said. "The greatest thing right now in the war on terrorism is prevention."

Anderson, who lives within walking distance of the lab, does not appear to have broken any laws, Lunsford said. In fact, Anderson said, firefighters helped him get the 4 [ed: that should actually be around 40] -ounce foam plane back when he came calling at the lab's front gate.

"They were incredibly nice about it," he said.

The flight was an attempt to take photos of the unusual architecture of the lab's cyclotron, a mostly round particle accelerator. The photos were to be posted on his personal Web site, diydrones.com, devoted to unmanned aerial vehicles, or drones.

Instead, Anderson, whose children took turns piloting the plane, ended up with a partial photo of the cyclotron and a blog entry titled: "Lesson: Don't fly planes over secure national labs!"

Anderson, who worked at Los Alamos lab in New Mexico, acknowledged he should have known better than to take the close-up aerial photos.

"I promise not to fly over secure national labs anymore," he said."

I had the wackiest near-catastrophe this weekend. My kids and I were running aerial mapping patterns over the Lawrence Berkeley Labs cyclotron (which is very distinctive from the air) and testing some ISO settings on the Pentax A30. Because we were over a built-up area and had to hand launch and recover from a hillside, we were using the Mutiplex EasyStar, which is just an RC plane, not a UAV. Which means that it's all up to the pilot to keep things in hand.

Unfortunately I was the pilot for one run where the sun was in exactly the wrong position and I got momentarily blinded. When I found the EasyStar again I couldn't tell what it's orientation was. Needless to say, ten seconds later it was in the top of the highest tree inside the gate of a super-secure National Laboratory. Yikes.

I dropped the kids off at home and went to the main gate of the lab and explained what happened. To my astonishment, they neither laughed at me nor arrested me. Instead, the head of security escorted me to the cyclotron and we started looking around. I went and got the transmitter and gunned the motor, and eventually we were able to find the plane by following the sound. Sure enough, it was 60 ft off the ground in the tree and really wedged in.

There wasn't much to be done, but at least we'd located it. I left my contact details and we agreed to have me come by the next weekend and see if the wind had budged it at all. Then I went home.

Half an hour later I got a call from the lab. "How would you feel about us using a hose to knock it down?" Needless to say, the risk of water damage seemed a lot better than losing the whole thing, camera, GPS, radio and all. "Go for it!" I said and dashed down the hill again to see what I could do.

When I got there it looked like the scene of a real airplane crash. A lab fire engine with lights flashing was at the base of the tree and searchlights had pinpointed the plane. Hoses snaked across the road and emergency radios were squawking. A fireman was braced against the truck and was about to let loose a high-pressure stream at the plane.

It actually turned out to be harder than it looked, given how high the plane was and how dense the tree was. They had to replenish the water tank once from a fire hydrant before they finally knocked it to the ground. The foam wings and tail were torn off (that's okay--they're just $20 to replace), but the fuselage and the all-important electronics were all there. I thanked everyone profusely and took it all home to dry things out and gauge the damage.

Right now the radio, motor and GPS look fine. The camera is going to have to dry out more before I can tell if it's going to be okay [UPDATE: It's fine!] , and so too for the LiPo battery. But I'm so pleased to get the rest back that I hardly care. Meanwhile, the image data on the card was really pretty good (a PTGui stitch of one pass is above).

Thanks LBL guards and firemen! I promise not to fly planes over your super-secure lab again!

Check out this great post from the winners of the Australian amateur UAV contest--the guys at Dionysus Designs, a Chico, CA-based team who focus on advanced RC technology, aerial photography and now amateur UAVs. They built their own airframes, then modded a beautiful powered glider (shown here neatly packed into a golf case to make the trip) to win best in show. Loads of helpful links in that post, too. Get in touch guys! We can use that sort of initiative here ;-)

Meanwhile, if you want other shots of contestents and UAVs from what sounds like a really sucessful contest, check out the photo archive here.

1. It only records a GPS record every 15 seconds in low-power mode and every 5 seconds in high-power mode. Even at the highest, battery-draining settings, that's way too slow for aerial mapping.
2. It takes forever to get a satellite lock. The first time, it took more than half an hour and subsequently it took more than three minutes.
3. Keeping that satellite lock is a struggle, too. By having a terrible GPS chip that only sees 12 satellites, the Trackstick II suffers from frequent drop-outs and glitchy datapoints. We found it essentially unusable.
   

"The Defense Department's unmanned air force has grown exponentially; there are now more than 3200 mil-drones in the fleet, up from about 200 in 2002. But after spending some time in Iraq, I'm starting to get the feeling that a lot of those robo-planes are sitting on the shelves, barely used.

Here's why. The military's big unmanned aerial vehicles (UAVs) are controlled by colonels and generals. The local commanders on the ground basically have no say where the things fly. For example, a company commander, recently returned from Anbar province, sa id his area got a grand total of eight minutes of coverage from the Predator spy drone per day.

But wait, you say. The vast majority of America's UAVs are little, hand-launched drones, like the four-and-a-half pound Ravens and the five-pound Dragon Eyes. The local captain has control over those, right? Well, theoretically, yeah.

But there are so many bureaucratic hoops to jump through to get those tiny UAVs in the air that many captains have stopped bothering to try. Air clearance is the hoops that comes up most. Although the drones are small, they can get up pretty high -- 1000 feet, or more. Which means there's a concern about the UAVs getting tangled up with helicopters. Setting aside space for the drones can take 24 to 48 hours -- and insurgents don't usually stay in one place that long.

A few weeks ago in Anbar, I spoke to local Marine commander who had basically given up on using his Dragon Eye, for this reason. The same thing happened in Tarmiyah, north of Baghdad, where Captain Pat Roddy told me, "the Raven? Never fly it." Which is particularly frustrating. Because Roddy regularly gets airspace for himself, to fire mortars. But his higher-ups won't let him launch his drone during that time, because the computer program that tracks airspace says its a no-aircraft zone. Roddy has been told that he can make an emergency switch from mortar to Raven airspace -- and it'll only take an hour to make the switch in the computer. But he can only do so if his troops are in a firefight. And firefights in Iraq almost never take more than a few minutes. An hour later, the Raven is all-but-useless."

And from the bottom, it looks like this:

In a comment on a thread at right, David Albert makes an important point about frequency clashes between spread specturm radios and 2.4 Ghz video downlink systems, such as the RangeVideo and Black Widow AV setups that we use. If you haven't been following the chatter on aerial photography newsgroups, you might have missed this (as I did). This info may save your plane!

• "Having a 2.4Ghz Tx right next to a 2.4Ghz Rx is a bad idea. Regardless if it is Spektrum, Futaba, or Xtreme Power Systems. Once you get a certain distance, the video TX will swamp (overload) your Rx. Imagine looking into a bright spotlight and trying to see a candle in the distance. Even if the candle is changing colors (changing frequencies, ie spread spectrum) it is just a matter of time and distance before you can no longer see the candle. Check out ezonemag.com there are many many threads on this under the UAV forum and FPV forum on this. That is the reason why people with 2.4Ghz RC systems are moving to 900Mhz video or keeping 2.4Ghz video and using plain old 50Mhz or 72Mhz RC Transmitters."

• How an IMU works
  
• How accelerometers can control pitch and roll
• How gyros can control pitch, roll and yaw
• How Kalman filters work
• A review of one commercial autopilot (Micropilot MPO2028)
• Other commercial IMUs