|
COPYRIGHT 2006 American Association for Artificial Intelligence
* This article is my personal account on the work at Stanford on Stanley, the winning robot in the DARPA Grand Challenge. Between July 2004 and October 2005, my then-postdoc Michael Montemerlo and I led a team of students, engineers, and professionals with the single vision of claiming one of the most prestigious trophies in the field of robotics: the DARPA Grand Challenge (DARPA 2004). (1) The Grand Challenge, organized by the U.S. government, was unprecedented in the nation's history. It was the first time that the U.S. Congress had appropriated a cash price for advancing technological innovation. My team won this prize, competing with some 194 other teams. Stanley was the fastest of five robotic vehicles that, on October 8, 2005, successfully navigated a 131.6-mile-long course through California's Mojave Desert.
This essay is not about the technology behind our success; for that I refer the interested reader to recent articles on the technical aspects of Stanley (Dahlkamp et al. 2006; Montemerlo et al. 2006; Stavens and Thrun 2006; Thrun, Montemerlo, and Aron 2006; Thrun et al. 2006). Instead, this is my personal story of leading the Stanford Racing Team. It is the story of a team of people who built an autonomous robot in record time. It is also a success story for the field of artificial intelligence, as Stanley used some state of the art AI methods in areas such as probabilistic inference, machine learning, and computer vision. Of course, it is also the story of a step towards a technology that, one day, might fundamentally change our lives.
Thinking about It
My story begins in March 2004. Both Michael Montemerlo and I attended the first Grand Challenge Qualification Event at the Fontana Speedway, and Mike stayed on to watch the race. The race was short: within the first seven miles, all robotic vehicles had become stuck. The best-performing robot, a modified Humvee dubbed Sandstorm by its creators from Carnegie Mellon University (CMU), failed after driving just 5 percent of the course (Urmson et al. 2004). Even though I had never worked on autonomous cars, I could not help but to ask the obvious question: could we do better? And, more importantly, why was the Grand Challenge hard? Why did so many teams falter in the first few miles? And what could we learn by getting involved?
In July 2004, my research group decided to give it a try. Word of our decision traveled fast. Within two weeks of our initial decision to participate, Cedric Dupont from Volkswagen (VW) of America contacted us, offering his lab's support for a Stanford entry in the race. Cedric worked in a lab called Electronics Research Lab headed by Carlo Rummel, and located only two miles from campus. VW was in the process of marketing its new Touareg SUV in the United States. The lab saw the race as an opportunity to showcase its Touareg in a high-profile event, while working with us on new car-related technologies. Cedric offered our team two VW Touaregs equipped with drive-by-wire systems, plus full engineering support. This offer was irresistible. We were to have a robot car, one that was highly suitable for desert driving!
Before we received our robot, VW lent us a conventional Touareg. One of the very first actions was to drive the 2004 race course the good, old-fashioned way, with a person behind the wheel. To collect data, we bolted four laser range finders to the roof, plus a GPS system for positioning. As it turned out, we never again looked at the data collected that day. But we learned many important lessons. The area where Sandstorm had faltered was really difficult, and even getting there had been a tremendous achievement for the CMU team. And the course was long: it took us about 7 hours do drive the entire 142 miles of the 2004 Grand Challenge course, which made the DARPA-imposed time limit of 10 hours feel uncomfortably tight. And we learned a first hardware lesson, one of many more to come. A few dozen miles into the course, one of our lasers almost fell off the roof; others came loose to the point that the data became unusable.
The remainder of the summer months were spent purchasing vehicle components and designing some of Stanley's hardware. The VW engineers quickly identified an appropriate version of the Touareg, flew it across the Atlantic, and began the development of the drive-by-wire interface. In designing Stanley, I strongly believed that the process of software development would be as important as the final "product." Hence, Stanley had to be designed to facilitate the development work, not just to survive the race. Taking the robot out for a spin should be as easy as driving a regular car. And it should be fun, so that we would do it often. Thus, in contrast to several of the robots at the 2004 race, which were unfit for human driving, Stanley remained street-legal, just like a regular car. By moving all computers into the trunk, we maximized the development space inside. During testing, a big red button became our life insurance when the robot was in control. This button enabled us to take over control at any time, even at high speeds. My hope was that at times where our robot software malfunctioned, the person behind the wheel would take over fast enough to avoid any damage.
CS294: Projects in Artificial Intelligence
As a first step towards building Stanley's software, we decided to throw together a quick end-to-end prototype robot (see figure 1). This robot was to be deficient, but it should contain all essential components of a race-capable vehicle. We drew our motivation to start with an integrated system--instead of spending our time on component technologies--from the fact that we were quite ignorant about the nature of this challenge. Only from running a robot through actual desert terrain, and by watching it fail, would we be able to tell where the real challenges lay. Cedric and Carlo fully supported this vision and rushed the development of a drive-by-wire system for the Touareg, making the robot car available in early October.
[FIGURE 1 OMITTED]
We now faced the question as to how to find the necessary manpower for building a first prototype. As a college professor, I decided to offer the project as a course. In this way, our small team could draw many new students into this project for a limited period of time. CS294, Projects in Artificial Intelligence, was offered as a graduate course in the fall quarter of 2004, which ran from October through December.
CS294 was not a common course. There was no textbook, no syllabus, no lecture. With the exception of the papers by Kelly and Stentz (1998a and 1998b) we didn't even read a paper, so that we wouldn't be biased towards a particular approach. Instead, the course was to be a team of students working together to build a robot in record time. Most students had never worked on robotics, and few had ever been part of a large team. So the course offered a totally new type of experience.
The course was open to all students...
Read the full article for free courtesy of your local library.
|
Bookmark this article
Print this article
Link to this article
Email this article
Digg It!
Add to del.icio.us
RSS
