|By Janice J. Heiss, October 3, 2005|
From September 27 to October 5, Team Jefferson's Tommy, an unmanned, autonomous Java technology-powered dune buggy, will compete in the preliminaries of the DARPA Grand Challenge. Tommy will vie with 39 other vehicles at the California Speedway in Fontana, California, for a chance to be one of the 20 finalists for a grand prize worth $2 million at a 175-mile competition in the Mojave Desert on October 8.
We recently caught up with chief Tommy architect Paul J. Perrone on his way from Arkansas to California. The president of the Perrone Robotics company, Perrone has been working in the Java language almost since its inception. He is the author of four books on Java technology.
Why did you choose Java technology to run Tommy?
I started the Perrone Robotics company with the idea of leveraging my development background in Java technology. At one point, I realized that we could make it faster, easier, and cheaper to develop robotics applications by using off-the-shelf technology, with a lot of flexibility. And Java technology lends itself to that, in terms of selectability of underlying hardware, underlying operating systems, and integrated third-party components.
What version of the Java 2 Platform, Standard Edition (J2SE) do you use?
We're using J2SE 1.4 on the main processors and the Java Platform, Micro Edition (Java ME, formerly known as J2ME) 1.0 on the microcontrollers. We use the latest version of the Java Communications API and a Java software-based microcontroller from Systronix called J-Stamp. One of the flagship projects from Perrone Robotics has been to build the Mobile Autonomous X-bot platform, the acronym for which is MAX. The idea is to develop a generic robotics operating system or platform that makes it easy and economical to write robotics applications. I wrote a little about this in an April 2004 article in Java Developer's Journal .
"The basic port of MAX from the standard platform to the microplatform took about two days."
Chief Architect of Tommy and CEO, Perrone Robotics, Inc.
There's a standard profile of MAX and a microprofile, much like there's a standard profile of the Java platform and a microprofile. I wanted to run the same framework in both the J2SE environment and the J2ME environment. The basic port of MAX, from the standard platform to the microplatform, took about two days. Of course, there have been numerous tweaks and modifications since then.
That opened up the floodgates to integrate all the same types of sensors that we run on the big, standard-type platforms into the microplatforms. So if we have a GPS sensor that we had running on a standard laptop-type computer, that can plug into the J-Stamp microcontroller-type or J2ME-type environment. So Java technology enables massive and immediate reuse at all scales.
We like to say that the MAX robotics operating system allows you to create robotics applications from rat to cat to elephant size. Prior to the DARPA Grand Challenge, we had been working on rat- and cat-sized-type robots. A rat-sized robot would have just a single microcontroller and a cat-type robot may have a standard microprocessor and a microcontroller in it. And then there's the elephant-sized applications like Tommy, where there's a lot of room and potential for more processing power.
How is Java software suited for physical systems like Tommy that rely on rapid response to ongoing sensory feedback?
MAX enables us to seamlessly distribute objects and software across processors that are transparent to the actual application. They don't necessarily know where the code that they're invoking is running -- it could be running locally, as a web service or in a variety of ways. And so our initial plan was to have maybe three standard microprocessors and four microcontrollers in Tommy. And as we proceeded with development and gained some efficiencies and algorithms, we were able to incorporate all of our sensor fusion, analysis, data gathering, route planning, decision making, and commanding on a single microprocessor that cost under $200.
Other teams are using banks -- almost supercomputers -- to do essentially the same thing. I believe that's overengineering, and I don't think we're underengineering. I think we've been able to accomplish what we have through Java technology and MAX.
We use two controllers to do some of our low-level, real-time processing. The big processor sends a command to the microcontroller, and the microcontroller tells the steering motor to steer 10 degrees to the left. Then a steering encoder says, so to speak, "OK, you're at 10 degrees to the left, stop." So a lot of the real-time, low-level processing is performed on the microcontrollers, but all of the sensor gathering and fusion and decision making is done on the microprocessor. We haven't had any issues with real-time or processing capability to date.
We've essentially encapsulated, at one level, the entire generic sense-plan-act framework of robotics. Sense-plan-act is the common robotics term for what a robot does. It senses things from its environment, formulates a plan, and makes decisions based on that. And based on those decisions, it then actuates something that interacts with the real world. It may be turning wheels on the car; it may be turning a steering wheel; it may be hitting the brakes; it may be flapping wings. That's the basic idea of any robotics application.
We've encapsulated that and evolved it significantly to make it easier to create robotics applications. But then, of course, on top of that, there are all kinds of components and modules that are specific to specific sensors -- range sensors, laser radar, GPS sensors -- and we've created a suite of modules that makes it easy to integrate with various types of sensors.
Has Java technology made it easier to evolve and adapt the car?
"We're able to rapidly program Tommy with knowledge about the world, instantaneously in the field."
Chief Architect of Tommy and CEO, Perrone Robotics, Inc.
Certainly Java technology and object-oriented programming provide the capability to create modular components and reusable modules so that a change in one area does not require 20 different changes in 20 different modules. We created MAX to go even further by putting a lot of configuration variables and rules in an offline set of configuration data stores.
Very often, when running tests in the field, whenever we observe a new driving behavior that we want to encapsulate, we're able to alter the data on the spot so Tommy learns a new driving rule that is imparted to the vehicle immediately. If a code change is required, we're able -- through the modularity of Java software and MAX -- to add a new behavior and upload it to the computer, and away we go. Instead of five seconds, it may take 60 seconds. We're able to rapidly program Tommy with knowledge about the world, instantaneously in the field.
Also, because Java software allows mobile code and MAX allows distributed object communication, one robot on a bot network can dynamically communicate new data to another robot on the network or to multiple robots on the network, so all the robots benefit from that newly imparted data. To do this, we use the various communication protocols that Java technology supports in combination with Jini technology.
What about the role of Jini technology?
MAX is integrated with Jini technology, so robots can discover each other on a network to dynamically impart and communicate the knowledge they have about the world to the other bots on the network.
We've also used JXTA software in our robotics applications. JXTA allows communication with other types of applications, using the JXTA-type protocols -- XML-type protocols -- that run on different language-based platforms, whereas Jini technology requires another Java service somewhere on the network. So we did R&D on uses of JXTA to expand our ability to integrate with other variations of MAX that run on different platforms or other robotics applications written in C++ or other platforms. We have the ability to use both Jini and JXTA technology in a more-or-less seamless, transparent fashion.
You wrote, in reference to Java tools, in the April 2004 Java Developer's Journal article, "Apart from its simplicity as well as operating system (OS) and computing hardware independence, the wide range of built-in, commercial, and open-source tools readily available make it an attractive and low-cost platform for cranking out robotics apps." How does this apply to the role of Java technology in creating Tommy?
It applies significantly. First of all, in terms of operating systems, though we did some testing on Windows, we chose Linux for Tommy. So we're using an open-source operating system on top of which we seamlessly run MAX code. Thus, we were able to write once and run anywhere with no problem. And then, using off-the-shelf components -- for example, rather than writing our own serial communications protocols and APIs -- we were able to use the Java Communication API with the RX/TX plug-in. And IBM also has a Java communications plug-in that we can use that we don't have to write.
By using off-the-shelf components, we didn't have to write our own serial code drivers. We've also been using Blaze Advisor offline from Fair Isaac, as a third-party, commercial-source component, to do our route planning. We're able to leverage the advantages of the Java community in both the commercial and open-source components that are available.
What has your tools experience with Java applications been like?
It's been great. I mean, we use CLIPS as an integrative, development environment and have had a lot of success with that. We use Ant to build -- we're not sitting there spending an unnecessary amount of time trying to debug
.meg files, because we have Ant scripts where we type in a few commands and it compiles and creates a JAR file for our code and FTPs it to Tommy. So within seconds, we're ready to roll. So we use tools like Ant and Eclipse to speed up our application development, as well.
What was the biggest pleasure in working on Tommy?
Seeing him run for the first time was one of the biggest pleasures. He drove straight, but when he made that first turn at a waypoint, we knew we had an autonomous vehicle navigating on its own. That was extraordinary.
How do you feel going into the competition?
We're feeling good. Anything can go wrong, but I'm always cautiously optimistic. And even on the road here, we've been doing tests. We experienced some electrical problems in which one of our laser radars was shutting off, and we isolated that problem quickly. There are an infinite number of scenarios that Tommy's going to be up against both at the national qualifying events and in the Mojave Desert, if we advance. It would take me a long time as a human to train in these off-road environments to figure out how to navigate such terrain. Tommy takes an equivalent amount of time, if not a little bit more. But we're feeling good. We're feeling like we're going to be a competitive entry.
What do you see as the future of Java software in robotic applications?
"If someone completes this DARPA Grand Challenge, it's going be like landing in Paris. This has never been done before -- the challenge has never been met."
Chief Architect of Tommy and CEO, Perrone Robotics, Inc.
I hope to prove -- not only to the military but to the commercial world -- that you can run Java technology in robotics applications, and you can do it faster and cheaper. If we prove this at the Grand Challenge, we can help assure that Java technology is everywhere in robotics, and we can make it accessible and easier for others to build the robotics applications that they've dreamed of, faster and cheaper, much like we have.
Anything else you'd like to add?
If anyone completes this DARPA Grand Challenge in the Mojave Desert, it's going to be like landing in Paris. This has never been done before -- the challenge has never been met. So if we go a significant distance, we've shown that you can build such complex applications with limited resources, faster and cheaper, in 10 man-months' worth of software development time, on a microprocessor that cost less than $200 retail. Compare this with the banks of supercomputers of some of our competitors and their large resources.
One team last year reportedly spent $3 million to try to win the $1 million prize. We have nowhere near that level of money, but we want to show that with Java technology and MAX, everyone can build these types of applications.