What the crowd can do with a Reaper

A recent article at Wired caught my eye: A man and his drones: on the front line of robotic warfare.

Lt Col Curry, commander of the 62nd Expeditionary Reconnaissance Squadron at Kandahar, wanted to use his UAVs for "change detection" missions: shoot some photos, come back later, shoot more photos, and look for differences. These missions would be useful for identifying "buried bombs and hastily-placed rocket launchers plaguing Kandahar." Unfortunately, the infrastructure was not in place to utilize the Reaper's camera capabilities.

... the Reaper's Synthetic Aperture Radar (SAR) can create the instantaneous, high-resolution, black-and-white still images seen in the Ground Control Station on November 5. "Nobody was really using it," Curry says of the SAR. According to Curry, Nato commanders prefer the Predator's and Reaper's "sexy" full-motion video over the visually unimpressive radar pictures. The SAR was so unpopular than the Air Force doesn't even install monitors for radar pictures in the standard UAV control station.

What did Curry do? According to this article, his squadron invented their own solution to capture and analyze the data.

To use SAR over Kandahar, the 62nd had to rig makeshift displays tied to off-the-shelf servers. The improvised system wasn't certified by the Air Force, meaning the additional computers weren't allowed to touch the existing Ground Control Station. To keep the servers separate, the squadron installed a shelf in the control trailer to hold them.

Hardware is one thing. Processing SAR shots for change detection also requires software to make the actual image comparisons. For that, Curry turned to the Ministry of Defence, which has been quietly developing change-detection software for British intelligence systems.

This is a fascinating lesson in crowdsourcing. The Reaper is an extremely powerful platform with a suite of built-in capabilities, but--as so often occurs with modern technology--the front line operators had ideas of their own. They envisioned new ways of harnessing the technology. If I read this article right, Lt Col Curry and his team developed a completely new kind of mission at the squadron level by integrating their own hardware and software. That's pretty remarkable.

Can we take any broader lessons from this?

First, if we want to make the military into a dynamic and responsive learning organization, we need to expect and actively encourage this kind of innovation. We should expect our people to brainstorm new ways of using existing technology, whether that's using B-52s for close air support, using silly string to identify tripwires, or designing their own hardware/software tools for analyzing reconnaissance photos.

Second, we need to design our military technology for tinkering. Most military technology is like an iPod; it's a closed system that is tightly controlled by its creators and is not designed for experimentation. An iPod is excellent at the tasks it's designed for, but you can't make it do anything new. A lot of technology is moving in a different direction, giving users the ability and tools to add their own creative spin. Microsoft provides free tools, examples, and tutorials that let anybody in the world write and distribute their own games for the X-Box 360. They also run contests to drive innovation. Google and the Open Handset Alliance have brought the same openness to cell phones through Android. Many video games ship with the very tools that were used to design levels, characters, and storylines; any user can write their own content for these games. Can we do the same thing with military technology? We can't give users total access, but perhaps we could settle on an intermediate solution akin to the iPhone: any user can write iPhone applications, but they are carefully vetted by Apple for quality control before they can be published. At the very least, we need to make it easy for users to access and manipulate data.

Third, we need a more flexible certification and regulation framework. Innovation often requires cheating because of our stringent regulations and certification processes. According to this article, the 62nd had to keep their hardware separate from the ground station because of certification issues. When I wrote my program interfacing DOD mission planning software with Google Earth, I had to design it to run from a thumb drive--without installation--because there was no way to get the program certified and get a computer administrator to install it (this was before the thumb drive ban).

Certification and network security are obviously critically important, especially in fields like aviation with zero tolerance for error, but they can slam the door on innovation. Is there a way forward? I wonder if it's possible to design maneuvering space for innovators into our regulatory framework. If we think of a weapons system like a Reaper as a black box with inputs and outputs, it makes sense that we should prohibit uncertified hardware or software from providing inputs--they could cause real damage inside the system. But why not allow unlimited access to the outputs? We should create a nice polished software interface, where any computer savvy user can access the outputs for his or her own purposes. This is nothing new; websites do it all the time. Any programmer can write new programs built on Google Translate, Google Maps, Facebook, Twitter, or hundreds of other sites; they can access webservers that provide all the relevant data. That's why we have great Facebook interfaces for iPhone, Android, and other mobile devices. There's no reason we couldn't do the same thing with our military technology.

If we had a system like that, with a clear separation between parts, we could have different certification processes for different parts. You would subject the black box itself to the usual scrutiny, but it wouldn't make a bit of difference what custom applications are accessing the outputs. If Capt Reach 364 wants to plug his laptop into a dataport on his C-17 and download his flight plan, his engine readings, his GPS coordinates, and the air pressure at every sensor in the jet's bleed air system, more power to him. If Reach 364 invents something cool--say, a way to overlay the jet's position on a color moving map (something the C-17 lacks)--and he wants to institutionalize this tool, you could have a separate, streamlined certification process for such tools (like custom iPhone programs).

This might sound like a lot of crazy technical wizardry--how many soldiers or airmen would really write custom software for a C-17 or Stryker, one might ask?--but these trends have already transformed civil society. Programming tools are becoming more powerful, more intuitive, and more mainstream. I expect there would be tremendous payoff in institutionalizing this kind of openness in our military technology.