UAV Basics — Types of UAVs

This will be the first of a series of articles about the basics of UAVs. Today we start with the different types out there.

The first is your standard airplane model. This one is the Rhino UAV, which is a project intended to help anti-poaching efforts:

Rhino UAV

The design is similar to all the model airplanes that have been out there for years. The only real difference is that the on-board electronics can be made sophisticated enough to fly to a destination without any human input.

The other kind of flying UAV is the helicopter type, though the traditional helicopter doesn’t seem too popular to build. The multipod design, especially quadcopters, seem more widespread.

CycloneCloseup1

There were a number of historical attempts to build a multipod, but the single-rotor helicopter became preferred in general aviation, despite the problem of the torque on the blades inducing it to spin. The reason seems to be that slight differences in motor speed, weight balance, and propeller shape tend to make multipods unstable. The pilot has to make constant corrections for this, and it becomes too much of a mental load. Meanwhile, the helicopter’s torque problem was solved with a simple rear vertical propeller, so everybody just did that.

Now we have cheap microcontrollers, gyros, and accelerometers for automatic stabilization. That takes the load off the pilot, making this a viable design. Quadcopters have particularly grown in popularity of late.

One variation I’m interested in is this 3-armed, 6-propeller design from 3D Robotics:

Tri Copter

The dual prop design lets it have high lifting capacity in a small package.

UAVs don’t just fly, though. They drive and swim, too. Google’s self-driving car is essentially a UAV. The ASV Roboat is an autonomous sailboat used for research into the endangered harbor porpoise in the Baltic Sea:

ASV Roboat

Most of what I’ll be working on is the flying variety, though.

Dynamic Perl Code Loading

There’s a trick done by mod_perl for running old-style CGI scripts. These have to be loaded on-demand, but how do we load code into the parser at runtime?

Well, eval(STRING), of course. Really, there’s no magic to it beyond that. This often maligned feature is at the heart of not just mod_perl, but also pretty much any templating system that embeds Perl code inside. Isn’t that dangerous, you ask? Not really; you presumably trust the code coming from template files on your own server. It’s no more dangerous than downloading a random CPAN module and loading it up.

Generally, they don’t eval the straight code. They wrap it up inside a package and a subroutine, then call the sub. Something like:

Things can get more sophisticated than this. Perhaps you expect to load up multiple code files, so you generate a predictable package name for each one (maybe based on the file name). Maybe the run() sub takes an argument, like $request for the Apache request object, which will then be available to the loaded code.

One problem with the above as written is that it screws up error messages for the filename and line number reporting. If you use the debugger, it’ll screw up it outputting the code you’re stepping through. This is where a trick with Perl comments comes in handy, where the line number and file in error messages can be set in a comment. It’ll work something like:

And all is well in the world. In the case of templating systems, you might want to keep track of the line number you’re getting the code from, and fill that into the line directive, too.

Underappreciated Perl Modules: File::ShareDir

Problem: you have some kind of data that needs to be distributed with your Perl module. Where do you put it in a cross-platform way?

Solution #1: Put it in a giant datastructure inside some module. This ends up with a big .pm file that chews up memory.

Solution #2: Put it in a __DATA__ section. But you only get one of those per module, and binary data might get hairy.

Best solution: File::ShareDir.

If you’ve ever looked through your Perl module directory, you’ve no doubt seen a directory called ‘auto’. This was used for a few different autoloading systems, but there’s no reason you can’t use it for your own module.

When I added SDL navigation data output to UAV::Pilot, the text overlayed on the screen needed a specific font. SDLx::Text can take a path to a TrueType font file, but where do you put that file?

The answer is that you create a ‘share/’ directory in your project and drop it in. The files there will be placed in your module’s ‘auto/’ entry. You can then get the path to the file with:

Thus providing a safe, cross-platform way of storing module files.

Musings on Hackable UAVs

Programming the AR.Drone has been a mostly fun challenge, and occasionally a frustrating challenge. The nav data is particularly under-documented, and UAV::Pilot still suffers from a few video parsing issues, probably because the documentation doesn’t fully explain the PaVE headers. But I pushed through them, figured it all out, and now there’s a release that I would consider close to feature-complete.

I never intended to stop with just the AR.Drone. It was a cheap way to get started–cost about $300 rather than $500-700 for a some other types–but it’s ultimately a toy. I don’t have a problem with big-boy toys; in fact, I own quite a few of them. But it’s a bit limited.

More “serious” UAV platforms, such as Ardupilot, often use some kind of mission planner software that allows you to put in a path of GPS coordinates and do something at the waypoints (like take pictures). With a GPS attachment and the right software, this is technically possible with the AR.Drone, but not out of the box.

The AR.Drone also has decent but somewhat limited hacking potential. If you’re willing to void your warranty, you can set on-board scripts to connect to AP-mode WiFi, add cheaper high-capacity batteries, or use the USB port to run attached devices. But it’s ultimately a closed platform with all the limitations that implies.

I find some of the other autopilots out there just as frustrating, for a somewhat opposite reason. They allow you to do anything, but their starting point is more sophisticated and need some work to dial them back down. The Ardupilot hardware, for instance, needs a compass, GPS, barometer, and some other assorted electronics. Not all this stuff is necessary for all uses. If you’re flying lower than 20-50 feet or so, the barometer isn’t much use and is too inexact. An ultrasonic range finder would be better for that case.

It’s all FOSS, so I’m sure you can get it all to work one way or another, but it isn’t designed for it.

By way of analogy, for years before the iPad, Microsoft had tried pushing tablets by taking their desktop OS and scaling it down to a tablet. They were largely ignored. What Apple (and later, Google) showed was that the correct strategy was to take a smartphone OS and scale it up.

That’s similar to the strategy I’d like to try with UAVs. If you want a toy UAV like the AR.Drone, you should be able to put it together cheaply without a GPS or barometer or anything. But if you want to get more serious, you should be able to add all that stuff without much trouble.

The platform should allow you to alter every aspect of the design, allowing the frame to be fully 3D-printable. Some printable UAV designs are already out there, such as the PL1Q Vampire, though often under a non-commercial license, which doesn’t meet widely accepted definitions of FOSS.

My goal is to build a UAV platform with the following requirements:

  • Complete design is under FOSS-compatible licenses, allowing modification for personal or commercial use. Licenses like BSD, Lesser GPL, or CC-BY[-SA] (but not CC-NC).
    • Software will probably be BSD, with CC-BY for hardware
  • On-board systems controlled by cheap and easily available computing platforms, such as Raspberry Pi, Arduino, and/or ATtiny.
  • Frame is fully 3D printable
  • Wide choice in attaching hardware; GPS, barometer, cameras, nerf guns, etc.
  • Wide choice in control methods; WiFi, XBee, cell phone towers, etc.
  • Complete documentation on control, navigation data, and accessories

I respect the work that’s already gone into projects like Ardupilot, but they don’t seem well suited for toy UAVs. And there’s nothing particularly wrong with toy UAVs; they are bound to have some rather un-toy-like uses, and even if not, there’s nothing wrong with a few toys. This looks like an open niche among the FOSS autopilots, which I intend to fill.

UAV::Pilot v0.5 Released, Now Supports Real Time Video

UAV::Pilot, a Perl library for controlling the Parrot AR.Drone, has released version 0.5.

This was the big one. With the ffmpeg library installed, you can decode the h.264 video stream coming right off the drone, in real time. This is where UAV::Pilot starts to get really interesting, opening up applications like augmented reality games and object recognition.

Demo video:

I’m going to be taking a short break from working on UAV::Pilot for a while. After lazing about, I’ll start work on the next release, which will mostly be cleaning up the API and bugs.

Also, I’ll be giving a presentation on UAV::Pilot in September for the Madison Perlmongers Group, which I plan on recording.

UAV::Pilot v0.4 Released, Now Supports Video

UAV::Pilot, a Perl library for controlling the Parrot AR.Drone, has released version 0.4.

The big change for this update is streaming video to a file. Display in real-time is not yet
implemented–that’s coming in 0.5.

There are also some API changes in how event loops are initialized to make the naming more consistent. There will probably be another API change in the video handling in 0.5. Once I do a complete release, API changes will have a proper deprecation plan, but for right now I think it’s fine to change things willy-nilly.

UAV::Pilot v0.3 Released

Version 0.3 of UAV::Pilot has been released on CPAN. The major change in this version is an improved event loop based on AnyEvent.

AnyEvent is a very nice framework overall, but unfortunately doesn’t have quite the right syntax for UAV::Pilot’s purposes. Consider this plain-English description of a UAV flight:

Takeoff, wait 5 seconds, then pitch forward for 2 seconds, then pitch backwards
for 2 seconds, then land

In AnyEvent’s standard interface, things would work out something like this:

All that indentation gets hairy. So I created an interface on top of AnyEvent, UAV::Pilot::EasyEvent, which is based on the Node.js event interface used by NodeCopter. Here’s how you’d write the same problem using EasyEvent:

Much better.

As an added bonus, having a good event interface means we can also support controlling UAVs through SDL joysticks. See bin/uav_joysticks in the distribution for details.

Announcing: UAV::Pilot v0.2

UAV::Pilot version 0.2 is now up on CPAN. The big change in this one is initilizing the navigation stream and parsing the data. I also whipped up this retro-videogame looking graphical output:

nav_output_sdl

The usability of the nav data is a bit limited at this point, because we need to grab the stream continously in a loop for display while also processing the flight commands. This is where an event system like AnyEvent will come in handy. You can try programming it around AnyEvent (or whatever event system you like) with what’s there right now.

The major work for the v0.3 release will be getting an event loop integrated into the library.

The Black Hole of Awkward Timing Known as High Performance Tires

My 370z needs new tires. The tread depth is technically legal, but driving in the rain is scary, and they don’t grip very well under hard launches. They’re also 19-inch wheels, which apparently nobody is selling in the best, most grippy street tires right now.

Tires might seem like the most boring part of the car, but they’re the only part that touches the ground (well, usually . . . ). They’re also something that tends to get a little bit better every year.

Bridgestone Potenza RE-11’s were my first choice. I had them on my RX-8, and they were great. Problem is, they’re slowly introducing the RE-11A’s and pulling the older RE-11’s from sale. Which would be all well and good if they actually had RE-11A’s in 19-inch sizes. The originals are going or gone in 19-inches, and the new ones haven’t been introduced there yet.

Then there are BFGoodrich g-Force Rivals, and the Dunlop Direzza ZII’s. The Rivals don’t seem to come in 19-inch sizes yet, and while the Direzza’s do, they’re not in the widths I want.

Bridgestone Potenza S-04s are a step down from all the above, but they are in the right size.

Two or three months from now, I’m sure this will all be worked out, but I can’t wait that long. I have an event coming up and I want sticky tires for it. The question might come down to the S-04’s slightly less sticky compound being made up for with a slightly larger contact patch.