When most people think about mobile Linux, they're talking about laptops. When Paul Perrone, CEO of Perrone Robotics and CTO of Assured Technologies, talks about mobile Linux, he's talking about having Tux drive himself on a 175 road trip across the Nevada desert.

Perrone is leading Team Jefferson, one of the 40 teams that has qualified for the semifinals of the DARPA Grand Challenge, a Defense Department funded competition to design self-driving vehicles that can successfully navigate a series of waypoints along a demanding route.

"There is a Congressional Charter that says by 2015, I think one-third of the operational ground combat vehicles need to be unmanned," explains Perrone. "DARPA has taken [the mandate] into consideration and they came up with the idea that one way to spawn innovation outside of the traditional channels where they've been spending money for the last so many years is they came up with the idea of this race. The nature of the race is basically a 175 race through the Mohave Desert, and the idea is that you have to build your vehicle to traverse this terrain in 10 hours or less and beat out all other competitors in order to win the $2,000,000 prize. "So in a nutshell that's the challenge, to basically build a vehicle that is completely unmanned, completely autonomous; in other words there is no human intervention once you start the vehicle. You're only given the route coordinates two hours before the race and you load those in and that gives you a virtual course essentially for those 175 miles through the dessert and your vehicle needs to stay within those course boundaries and of course avoiding obstacles along the way and make it to the finish line," he continued.

Perrone, whose background is designing large-scale distributed railway control systems for companies such as Burlington Northern & Santa Fe before developing an interest in robotics, first became interested in the Grand Challenge after learning about the first Challenge.

"I started to get interested in it when I found out about it two summers ago. I had just at that point pretty much started up this robotics company and I thought it would be a great way to showcase some of the software, but I found out about the first race a little too late into the game and basically didn't have a chance to put together a team and a vehicle, and then just thought 'Well I'll wait and see kind of what the results are from the first race,'" Perrone explained.

The results were not encouraging, only 9 of the 15 entrants made any significant movement onto the course, and Intel's Team Red led the pack with an anemic 7.4 mile effort on the 142 mile route.

In spite of the relative lack of success of the entrants, Perrone was inspired. He relocated from Northern Virginia to Charlottesville, set up a workshop and started designing. One of the first decisions was to out-source the basic vehicle fabrication.

"I'm dangerous with a wrench," said Perrone, "so rather than have me try to build anything mechanically that could actually compete in this race, I went and looked around at a number of folks who could build vehicles that can engage in this terrain in question. So I looked at a number of different options and honed in on a dune buggy kind of concept and design and found a group out in Utah from this company Sand-Tec."

The owner, Dave Egelund, seemed to be just what was required for the project. "Dave is a paraplegic and had an interest in hand controls for vehicles and one of the things that I was looking for this dune buggy company to do is to not only build us a dune buggy but to put in a drive-by wire control, basically the thing that's going to turn the steering wheel, that's going to drive the brake, the throttle, the shifter. He was the most interested in it and also was interested in kind of taking it one step--he also recommended a number of other kinds of novel mechanical features for the vehicle." The end result was Tommy, a drive-by-wire dune buggy just waiting to eat up the Mohave (see Figure 1).

With the transportation taken care of, Perrone's next decision was a hardware platform for the computing. "We wanted to showcase this platform that we have through the robotics start-up and we called that Platform Max, for Mobile Autonomous X-BOT. The whole idea is X is a variable into which you can plug a variety of robotics applications that we've built on top of Max, which is kind of a general purpose platform. We've built on top of that a specific groundwork for unmanned ground vehicles that we called Max UGV, and Max and Max UGV run on the Java platform. It's distributed, there's two profiles essentially.

Well, there's actually three profiles, but the two that are relevant to Tommy is a standard platform that runs on just regular processor cards and then an embedded platform that runs on micro-controllers essentially. On the standard platform, we have Java running on Linux and we're happy to be using Fedora for that platform."

The system reads data from a number of different inputs, including high-resolution GPS, inertial guidance, laser detectors, conventional radar, bump and proximity sensors, and possibly a stereo vision system. Perrone's decision to use Linux is by no means unique among the competitors; several other teams have Linux-based control systems. But his choice of Java as the development language might raise a few eyebrows. After all, traveling at 40 miles an hour is no place to get stuck doing a garbage collection pass.

Perrone acknowledges the unique design decision, but sees it as a strength rather than a weakness.

"I think it's safe to say that we're the only team that's 100 percent Java based. I mean even our micro-controller code is all Java based. We're running it on the Systronics J-Stamp platforms. We have a couple of those in there and that has the JVM running in hardware. Java is not something traditionally used in robotics applications and that's where I think where we have kind of a unique perspective on things in that we are using off-the-shelf open source technology that's not traditionally been used in robotics and embedded applications. Yeah, there are some real-time considerations and for a lot of the things like driving motors, where you set out a pulse with modulated signal to activate a motor and it may be like a 30 percent duty cycle like one pulse per 500 micro-seconds or something like that, you can't do that effectively on a parallel port or whatever off of a standard processor. So that's where we use the J-Stamp.

"It does all the low-level kind of controls, like feedback control. Basically it will drive the motor and then we also have feedback sensors for all the motors and so when it gets to a position it just stops. You can think of the micro-controller as like the muscles and the tendons, and all the thought work is being done on the standard processor that runs Linux and the standard Java platform."

For Perrone, the choice of Fedora was somewhat arbitrary but the use of Linux was a clear advantage.

"First of all there was the question of what OS to use and I guess we thought that Linux and Fedora offered the most support in terms of Java libraries and things available that an open source tool that would run. They're more open source tools available obviously for the Linux platforms than there are per se for Windows, so we felt that we wanted to leverage use of these tools as much as possible in our design, so we thought Linux was kind of the best choice for that path. It just had more in the way of Java and open source support, and so that's kind of what drove the general Linux versus Windows versus some other flavored platforms. Once you tree into that decision making process the question is 'well which flavor of Linux to use?' and we just chose Fedora because we thought that it was also probably the most widely supported flavor of Linux for the various types of tools that we would be interested in using."

The hardware itself is a VIA Technology EPS Series motherboard. "They're fairly small form factor cards and have decent power consumption properties. So we've chosen a couple, the EPD specifically and the EPM motherboards for our main processor. There's a lot of support for Linux on those specific processor platforms," explained Perrone.

The hardware is protected from the elements by a silver egg-shaped covering, and further insulated by an equipment box mounted on air bags with it's own air conditioning.

Perrone was coy about revealing any particular vulnerabilities that Tommy might be prone to, but readily admits that the task is challenging.

"I think the biggest concern for most teams and for anybody is going to be the situation where you're running your vehicle at a fairly high speed and by high speed I might mean 40 miles an hour or more, or even less than that; I mean even if you're going like 20 really or 30 miles an hour, if your sensors detect something and even if your sensors detected out at 100-meters, if you think about that and you're traveling at those great speeds, your response is pretty limited. I think the worst fear for us and the worst fear for everybody is to tighten our algorithms and our ability to perceive out at further distances and react to that as quickly as possible. If you just program your vehicle to turn as soon as it sees something out front, you're going to roll your vehicle and that actually happened during testing to Carnegie Mellon last year; it happened to a couple teams already this year during testing, and when you roll your vehicle during the race it's of course pretty much game over, but even if you're rolling it during testing, I mean that can set you back a month or so at a time. So it's been something that we're not only worried about for the race, but we're worried about now because we really don't want to roll the vehicle. I guess that's really the Achilles heel, being able to perceive obstacles out far enough with enough lead time to be able to react without rolling the vehicle."

Perrone sees the Grand Challenge as an opportunity to showcase the technologies he's developing for generalized robotics. Beyond the Challenge, he sees a lot of potential.

"We think the next step is to take some of what we've been doing into some other application areas and demonstrations of what this technology can do, and start to push this maybe by getting some investment in the company and then in the technology, to take this to the next step which is commercialization. We think there are a lot of military applications for this and we like to say our software can run on anything from rat to cat to elephant size because essentially we've taken a lot of the same software and have run it in purely on a J-Stamp, something that can fit in the palm of your hand. A lot of that same software is what runs in Tommy which can fit in your garage. So we think there are a lot of applications for the military: surveillance and security, bomb detection, mine detection, delivering supplies, through hazardous environments. But we also think there are a lot of commercial applications for this technology, too, which includes things like hospitals. Automated carts that that deliver supplies from floor to floor. I mean they have this now but it's incredibly expensive and what we're doing by using Java and Open Source technologies like Linux, we really kind of just dropped the floor on cost for these applications. And so the idea is to really make mobile autonomous robotics viable in the commercial marketplace where it previously has yet to become viable, and then widespread in the marketplace. We've extracted away a lot of things that make it difficult to create robotics applications from the get-go, so we want to get this technology out there so developers can start to use it."

James Turner is a Senior Contributing Editor at LinuxPlanet and Linux Today. He works as a Senior Developer at Axis Technology, LLC., and has written for publications such as WIRED Magazine and the Christian Science Monitor. He is also the author of two books on Open Source Development using Java. You can read his blog at blog.blackbear.com.