Musings on Hackable UAVs

2013-08-04

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

2013-07-31

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:

https://www.youtube.com/watch?v=6jX0YbPTv44

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

2013-07-04

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

2013-06-17

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:

my $timer; $timer = AnyEvent->timer(
    after => 5,
    cb => sub {
        $uav->pitch( -1.0 );
        my $timer2; $timer2 = AnyEvent->timer(
            after => 2, 
            cb => sub {
                $uav->pitch( 1.0 );
                my $timer3; $timer3 = AnyEvent->timer(
                    after => 2,
                    cb => sub {
                        $uav->land;
                        $cv->send;
                    },
                );
                $timer2;
            },
        );
        $timer;
    },
);

$uav->takeoff;
$cv->recv;

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:

my $cv = AnyEvent->condvar;
my $event = UAV::Pilot::EasyEvent->new({
    condvar => $cv,
});

$event
    ->add_timer(
        duration => 2000,
        duration_units => $event->UNITS_MILLISECOND,
        cb => sub { $uav->pitch( -1.0 ) },
    )->add_timer(
        duration => 2000,
        duration_units => $event->UNITS_MILLISECOND,
        cb => sub { $uav->pitch( 1.0 ) },
    )->add_timer(
        duration => 2000,
        duration_units => $event->UNITS_MILLISECOND,
        cb => sub { 
            $uav->land;
            $cv->send;
        },
    );

$event->activate_events;
$uav->takeoff;
$cv->recv;

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

2013-06-02

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:

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.

Blackhawk Farms HSAX, 2013/05/27

2013-05-28

Videos are up

The Black Hole of Awkward Timing Known as High Performance Tires

2013-05-13

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.

That's Better

2013-05-12

Playing around with WordPress themes.  I wanted something akin to my old custom-built blog, with the retro-greenscale console screen look. The Mantra theme looked close to what I wanted, and then I messed around with the CSS a bit. Looks to be good enough for now.

AR.Drone Nav Data

2013-05-12

There are parts of the Parrot AR.Drone that are rather underdocumented, and one of those is getting the navigation data.  Once you activate the nav data, it doesn’t send the data directly to you. Instead, it sends it to the 224.1.1.1 muticast address.

Which is great and all. That means you can have one person controlling on their laptop and a bunch of other people watching the nav data on their own systems. But it’d be nice if their docs told you this.

There’s also a way to get it to unicast to your address, but they certainly don’t lay that out.

Anyway, the good news is, I can receive the AR.Drone’s nav data now, which is a big milestone for the 0.2 release.

Announcing: UAV::Pilot v0.1

2013-05-09

UAV::Pilot is a Perl library for controlling UAVs.  It currently works with the Parrot AR.Drone, with plans to expand to others in the future.

Demo video

The current library supports basic commands, such as takeoff, pitch, roll, yaw, vert speed, and land.  All the preprogrammed flight animations are also in place. Navigation data and video are not yet supported–see the ROADMAP file for future plans.

Github repository: https://github.com/frezik/UAV-Pilot

CPAN: https://metacpan.org/module/TMURRAY/UAV-Pilot-0.1/lib/UAV/Pilot.pm