In 2003 the Defense Advanced Research Projects Agency(DARPA) announced the first Grand Challenge with the goal ofdeveloping vehicles capable of autonomously navigating deserttrails and roads at high speeds. The competition was generatedas a response to a mandate from the United States Congress thata third of U.S. military ground vehicles be unmanned by 2015.To achieve this goal DARPA drew from inspirational successessuch as Charles Lindbergh’s May 1927 solo transatlantic flightaboard the Spirit of St. Louis and the May 1997 IBM Deep Bluechess victory over reigning world chess champion Garry Kas-parov. Instead of conventional funded research, these successeswere organized as challenges with monetary prizes for achievingspecific goals.

DARPA’s intent was not only to develop technology but alsoto rally the field of robotics and ignite interest in science andengineering on a scale comparable to the Apollo program. Thus,the Grand Challenges were born. Organized as competitionswith cash prizes awarded to the winners ($1 million in 2004; $2million in 2005; and $2 million for first, $1 million for second,and $500,000 for third in 2007). For the first two years the gov-ernment provided no research funding to teams, forcing themto be resourceful in funding their endeavours. For the 2007Urban Challenge, some research funding was provided to teamsthrough research contracts. By providing limited funding, thecompetition encouraged teams to find corporate sponsorship,planting the seeds for strong future relationships between aca-demia (the source of many of the teams) and industry.

The Grand Challenge1 was framed as a cross-country racewhere vehicles had to drive a prescribed route in the minimumtime. There would be no moving obstacles on the course, andno one was allowed to predrive the course. To complete the

Articles

SUMMER 2009 17Copyright © 2009, Association for the Advancement of Artificial Intelligence. All rights reserved. ISSN 0738-4602

Autonomous Driving in Traffic: Boss and the Urban Challenge

Chris Urmson, Chris Baker, John Dolan, Paul Rybski, Bryan Salesky, William “Red” Whittaker, Dave Ferguson, and Michael Darms

n The DARPA Urban Challenge was a compe-tition to develop autonomous vehicles capableof safely, reliably, and robustly driving in traf-fic. In this article we introduce Boss, theautonomous vehicle that won the challenge.Boss is a complex artificially intelligent soft-ware system embodied in a 2007 Chevy Tahoe.To navigate safely, the vehicle builds a model ofthe world around it in real time. This model isused to generate safe routes and motion plansboth on roads and in unstructured zones. Anessential part of Boss’s success stems from itsability to safely handle both abnormal situa-tions and system glitches.

challenge, the autonomous vehicles would need todrive the route in less than 10 hours. The compe-tition was scoped to require driving both on andoff road, through underpasses, and even throughstanding water. These diverse challenges lead to afield with a wide variety of vehicles, ranging frommilitary high-mobility multipurpose wheeledvehicles (HMMWVs) and sport utility vehicles(SUVs) to motorcycles and custom-built dune bug-gies.

The first running of the Grand Challengeoccurred on March 3, 2004. The 142-mile coursewas too difficult for the field, with the best vehicletraveling 7.4 miles. Though described as a failurein the popular press, the competition was a tech-nical success; though the vehicles drove a smallfraction of the course, the top competitors did so athigh, sustained speeds that had not been previ-ously demonstrated. Given the excitement andpromise generated by this first challenge, the com-petition was rerun in 2005.

The 2005 Grand Challenge began at 6:30 AM onOctober 8. Vehicles launched at intervals fromthree start chutes in the Mojave desert. Approxi-mately 7 hours later, the first of five finishers com-pleted the challenge. Stanley (Thrun et al. 2006),from Stanford University, finished first, in 6 hoursand 53 minutes, followed soon after by the twoCarnegie Mellon robots, Sandstorm andH1ghlander (Urmson et al. 2006). Kat-5, funded bythe Gray Insurance Company, and TerraMax, a30,000-pound behemoth developed by theOshKosh Truck Corporation, rounded out the fin-ishers. With five vehicles completing the course,the 2005 Grand Challenge redefined the percep-tion of the capability of autonomous mobilerobots.

The DARPA 2007 Urban Challenge2 continuedthe excitement generated by the previous chal-lenges, engaging researchers from around the

world to advance intelligent, autonomous vehicletechnology (figure 1). Competitors were requiredto develop full-size autonomous vehicles cable ofdriving with moving traffic in an urban environ-ment at speeds up to 30 miles per hour (mph). Thevehicles were required to demonstrate capabilitiesthat were undeniably intelligent, including obey-ing traffic rules while driving along roads, negoti-ating intersections, merging with moving traffic,parking, and independently handling abnormalsituations.

The Urban Challenge was fundamentally aboutintelligent software. The most visible artifacts ofthe research and development are the numerousautonomous vehicles that were entered in thecompetition, but the magic is really in the algo-rithms that make these vehicles drive. The compe-tition was a 60-mile race through urban traffic; adrive that many people face daily. Thus the chal-lenge was not in developing a mechanism thatcould survive these rigors (most automotive man-ufacturers do this already), but in developing thealgorithms and software that would robustly han-dle driving, even during unexpected situations. Tocomplete the challenge, vehicles had to consis-tently display safe and correct driving behavior;any unsafe or illegal maneuver could result in elim-ination from the competition.

In this article we present an overview of Boss,the vehicle that won the Urban Challenge (figure2). Boss was developed by a team of researchersand students from Carnegie Mellon University,General Motors, Caterpillar, Continental, andIntel. Boss drives at speeds up to 30 mph by mon-itoring its location and environment and con-stantly updating its motion plan and the model ofthe world around it. Throughout this article weprovide pointers to other publications that delveinto each area in greater depth.

Articles

18 AI MAGAZINE

Figure 1. The Urban Challenge Final Event.

Eleven teams qualified for the Urban Challenge final event. Eighty-nine teams from the United States and countries as far away as Chinaregistered for the competition.

The VehicleBoss is a 2007 Chevrolet Tahoe modified forautonomous driving. While it was built from thechassis up for the Urban Challenge, it incorporat-ed many lessons learned from the previous chal-lenges. Like most of the vehicles that competed inthe Urban, we built Boss from a standard chassis,to reduce mechanical complexity and benefit fromthe reliability of a highly engineered platform. TheTahoe provides ample room to mount sensors,computers, and other components while main-taining seating for four, which is important for safeand efficient testing and development. Computercontrol of the vehicle is made possible by usingelectric motors to actuate the brake pedal, gearselector, and steering column and through con-troller area network (CAN) bus communicationwith the engine control module. Despite thesechanges, the Tahoe maintains its standard human

driving controls, and pressing a button reverts it toa human-driven vehicle.

Boss integrates a combination of 17 differentsensors (a mixture of light detection and ranging[lidar], radio detection and ranging [radar], andglobal positioning system [GPS]). These sensors aremounted to provide a full 360 degree field of viewaround the vehicle. In many cases, sensor field ofviews overlap, providing redundancy and in somecases complementary information. The primarysensor is a Velodyne HDL-64 lidar, mounted on thetop of the vehicle. This lidar provides dense rangedata around the vehicle. Three Sick laser rangefinders are used to provide a virtual bumperaround the vehicle while two other long-rangelidars are used to track vehicles at ranges of up to100 m. Three Continental ACC radars are mount-ed in the front (two) and rear (one) bumpers todetect and track moving vehicles at long ranges. Inaddition, a pair of Continental sensors (lidar and

Articles

SUMMER 2009 19

Figure 2. Boss.

Boss uses a combination of 17 sensors to navigate safely in traffic at speeds up to 30 mph.

radar) are mounted on pointable bases, enablingBoss to “turn its head” to look long distances downcross streets and merging roads. To determine itslocation, Boss uses a combination of GPS and iner-tial data fused by an Applanix POS-LV system. Inaddition to this system, Boss combines data from apair of down looking SICK laser range finders tolocalize itself relative to lane markings described inits on-board map. The number of sensors incorpo-rated into Boss provides a great deal of informationto the perception system.

For computation, Boss uses a CompactPCI chas-sis with ten 2.16 gigahertz Core2Duo processors,each with 2 gigabytes of memory and a pair ofgigabit Ethernet ports. Each computer boots off ofa 4 gigabyte flash drive, reducing the likelihood ofa disk failure. Two of the machines also mount 500gigabyte hard drives for data logging, and all aretime synchronized through a custom pulse-per-second adapter board. The computer cluster pro-vides ample processing power, so we were able tofocus our efforts on algorithm development ratherthan software optimizations.

Software ArchitectureTo drive safely in traffic, the software system must

be reliable and robust and able to run in real time.Boss’s software architecture is fundamentally a dis-tributed system, enabling decoupled developmentand testing. In all, 60 processes combine to imple-ment Boss’s driving behavior. Architecturally theseare clustered into four major components: percep-tion, mission planning, behavioral execution, andmotion planning (figure 3).

The perception component interfaces to Boss’snumerous sensors and fuses the data into a coher-ent world model. The world model includes thecurrent state of the vehicle, the current and futurepositions of other vehicles, static obstacles, and thelocation of the road. The perception system uses avariety of probabilistic techniques in generatingthese estimates.

The mission planning component computes thefastest route through the road network to reach thenext checkpoint in the mission, based on knowl-edge of road blockages, speed limits, and the nom-inal time required to make special maneuvers suchas lane changes or U-turns. The route is actually apolicy generated by performing gradient descenton a value function calculated over the road net-work. Thus the current best route can be extractedat any time.

The behavioral executive executes the mission

Articles

20 AI MAGAZINE

Vehi

cle

Perc

eptio

n

Goa

l Abs

trat

ion

Sensor Data Abstraction

Mission Planning

Behavioral Executive

Motion Planning

Figure 3. The Boss Software Architecture.

The software architecture consists of a perception layer that provides a model of the world to a classical three-tier con-trol architecture.

plan, accounting for traffic and other features inthe world (Ferguson et al. 2008). It encodes therules of the roads and how and when these rulesshould be violated. It also implements an errorrecovery system that is responsible for handlingoff-nominal occurrences, such as crowded inter-sections or disabled vehicles. The executive isimplemented as a family of state machines thattranslate the mission plan into a sequence ofmotion planning goals appropriate to the currentdriving context and conditions.

The motion planning component takes themotion goal from the behavioral executive andgenerates and executes a trajectory that will safelydrive Boss toward this goal, as described in the fol-lowing section. Two broad contexts for motionplanning exist: on-road driving and unstructureddriving.

Software ComponentsIn this section we describe several of the key soft-ware modules (world model, moving obstacledetection and tracking, motion planning, intersec-tion handling, and error recovery) that enable Bossto drive intelligently in traffic.

World ModelBoss’s world model is capable of representing envi-ronments containing both static and movingobstacles. While this representation was developedfor the Urban Challenge, it can be also used morebroadly for general autonomous driving. Theworld model includes the road network, staticobstacles, tracked vehicles, and the position andvelocity of Boss. The road network defines whereand how vehicles are allowed to drive, traffic rules(such as speed limits), and the intersectionsbetween roads. The road representation capturessufficient information to describe the shape (thenumber of lanes, lane widths, and geometry) andthe rules governing driving on that road (directionof travel, lane markings, stop lines, and so on).

Static obstacles are those that do not move dur-ing some observation period. This includes obsta-cles off and on road. Examples of static obstaclesinclude buildings, traffic cones, and parked cars. Incontrast, dynamic obstacles are defined as objectsthat may move during an observation period. Withthis definition all vehicles participating actively intraffic are dynamic obstacles even if they are tem-porarily stopped at an intersection. By these defi-nitions an object is either static or dynamic; itshould not be represented in both classes. Anobject can, however, change from static to dynam-ic and vice versa: a person may, for example, getinto a parked car and actively begin participatingin traffic. The information about whether anobject is static or dynamic is not tied exclusively to

its motion; it is an interpretation of the currentstate of the world around the vehicle.

Each dynamic obstacle is represented by a seriesof oriented rectangles and velocities. Each rectan-gle represents the state, or predicted state, of theobstacle at an instant in time over the next few sec-onds. Additionally, each obstacle can be flagged aseither moving or not moving and as either observedmoving or not observed moving. An obstacle isflagged as moving if its instantaneous velocity esti-mate is above some minimum noise threshold.The obstacle is not flagged as observed movinguntil the instantaneous velocity remains above anoise floor for some threshold time. Similarly, amoving obstacle does not transition from observedmoving to not observed moving until its instanta-neous velocity remains below threshold for somelarge amount of time. These flags provide a hys-teretic semantic state that is used in the behavioralexecutive to improve behavior while maintainingthe availability of full fidelity state information formotion planning and other modules.

Static obstacles are represented in a grid of regu-larly spaced cells. The advantages of this represen-tation are that it provides sufficient informationfor motion planning and is relatively inexpensiveto compute and query. The disadvantages are thatthis simple representation makes no attempt toclassify the type of obstacle and uses a relativelylarge amount of memory. To generate the map,range data is first segmented into ground and non-ground returns and then accumulated in a mapusing an occupancy gridlike algorithm. To main-tain a stable world representation, dynamic obsta-cles that are flagged as not observed moving andnot moving are painted into the map as obstacles.Once a dynamic obstacle achieves the state ofobserved moving, the cells in the map that it over-laps are cleared. In the process of building the stat-ic obstacle map, an instantaneous obstacle map isgenerated. This map contains all static and dynam-ic obstacles (that is, data associated to dynamicobstacle hypotheses with the observed moving flagset are not removed). This map is much noisierthan the static obstacle map and is used only forvalidating potential moving obstacle tracks withinthe dynamic obstacle tracking algorithms.

Moving Obstacle Detection and TrackingThe moving obstacle detection and tracking algo-rithms fuse sensor data to generate a list of anydynamic obstacles in a scene (Darms, Rybski, andUrmson 2008). The tracking system is divided intotwo layers: a sensor layer and a fusion layer (see fig-ure 4). The sensor layer includes modules that arespecialized for each class of sensor and runs a mod-ule for each physical sensor on the vehicle. Thesensor layer modules perform sensor-specific taskssuch as feature extraction, validation, association,

Articles

SUMMER 2009 21

and proposal and observation generation. Each ofthese tasks relies on sensor-specific knowledge,generally encoded as heuristics; these are theimportant details that enable the machinery of theKalman filter to work correctly. For example, radarsensors may generate a specific class of false echoesthat can be heuristically filtered, but the filteringapproach would be irrelevant for a lidar or even adifferent class of radar. By encapsulating these sen-sor-specific details within sensor modules we wereable to modularize the algorithms and maintain aclean, general implementation in the fusion layer.

The fusion layer combines data from each of thesensor modules into the dynamic obstacle list,which is communicated to other components. Thefusion layer performs a global validation of sensorobservations, selects an appropriate tracking mod-el, incorporates measurements into the model andpredicts future states of each obstacle. The globalvalidation step uses the road network and instan-taneous obstacle map to validate measurementsgenerated by the sensor layer. Any observationeither too far from a road, or without supportingdata in the instantaneous obstacle map, is discard-ed. For each remaining observation, an appropriatetracking model is selected, and the state estimatefor each obstacle is updated. The future state ofeach moving obstacle is generated by either extrap-olating its track (over short time intervals) or by

using the road network and driving context (forlong time intervals).

Motion PlanningMotion planning is responsible for moving thevehicle safely through the environment. To dothis, it first creates a path toward the goal, thentracks it by generating a set of candidate trajecto-ries following the path to varying degrees andselecting the best collision-free trajectory from thisset. During on-road navigation, the motion plan-ner generates its nominal path along the centerline of the desired lane (Ferguson, Howard, andLikhachev 2008a). A set of local goals are selectedat a fixed longitudinal distance down this centerline path, varying in lateral offset to provide sever-al options for the planner. Then, a model-basedtrajectory generation algorithm (Howard et al.2008) is used to compute dynamically feasible tra-jectories to these local goals. The resulting trajec-tories are evaluated against their proximity to stat-ic and dynamic obstacles, their distance from thecenter line path, their smoothness, and variousother metrics to determine the best trajectory forexecution by the vehicle. This technique is suffi-ciently fast and produces smooth, high-speed tra-jectories for the vehicle, but it can fail to producefeasible trajectories when confronted with aberrantscenarios, such as blocked lanes or extremely tight

Articles

22 AI MAGAZINE

Object Hypothesis Set

Sensor Layer

Road World Model andInstantaneousMap

FeaturesValidatedFeatures

Measurement(Observations, Proposals, Movement Observation)

Local Classification and Proposal GenerationAssociationLocal Target ValidationFeature Extraction

Fusion LayerObject ManagementEstimation and PredictionModel SelectionGlobal Classification

Global Target ValidationRWM Checking

Figure 4. The Moving Obstacle Tracking System Is Decomposed into Fusion and Sensor Layers.

turns. In these cases, the error recovery system iscalled on to rescue the system.

When driving in unstructured areas the motionplanner’s goal is to achieve a specific pose (Fergu-son, Howard, and Likhachev 2008b). To achieve apose, a lattice planner searches over vehicle posi-tion, orientation, and velocity to generate asequence of feasible maneuvers that are collisionfree with respect to static and dynamic obstacles.This planner is much more powerful and flexiblethan the on-road planner, but it also requires morecomputational resources and is limited to speedsbelow 15 mph. The recovery system leverages thisflexibility to navigate congested intersections, per-form difficult U-turns, and circumvent or over-come obstacles that block the progress of the vehi-cle. In these situations, the lattice planner istypically biased to avoid unsafe areas, such asoncoming traffic lanes, but this bias can beremoved as the situation requires.

Intersection HandlingCorrectly handling precedence at intersections isone function of the behavioral executive (Bakerand Dolan 2008). Within the executive, the prece-dence estimator has primary responsibility forensuring that Boss is able to safely and robustlyhandle intersections. The precedence estimatorencapsulates all of the algorithms for determiningwhen it is safe to proceed through an intersection.Before entering the intersection, the intersectionmust be clear (both instantaneously and through-out the time it predicts Boss will take to travelthrough the intersection) and Boss must haveprecedence. The precedence order is determinedusing typical driving rules (that is, the first to arrivehas precedence through the intersection and incases of simultaneous arrival, yield to the right).

The precedence estimator uses knowledge of thevehicle’s route, to determine which intersectionshould be monitored, and the world model, whichincludes dynamic obstacles around the robot, tocalculate the precedence ordering at the upcomingintersection. To ensure robustness to temporarynoise in the dynamic obstacle list, the algorithmfor computing precedence does not make use ofany information beyond the geometric propertiesof the intersection and the instantaneous positionof each dynamic obstacle. Instead of assigningprecedence to specific vehicles, precedence isassigned to individual stop lines at an intersection,using a geometric notion of “occupancy” to deter-mine arrival times. Polygons are computed aroundeach stop line, extending backward along theincoming lane by a configurable distance andexceeding the lane geometry by a configurablemargin. If the front bumper of a moving obstacleis inside this polygon, it is considered an occupantof the associated stop line. Boss’s front bumper is

added to the pool of front bumpers and is treatedin the same manner to ensure equitable estimationof arrival times. Figure 5 shows a typical occupan-cy polygon extending three meters back along thelane from the stop line. Once the polygon becomesoccupied the time is recorded and used to estimateprecedence. To improve robustness of the dynam-ic obstacle list, the occupancy state is not clearedinstantly when there is no obstacle in the polygon.Instead, the polygon remains occupied for a smallamount of time. Should an obstacle reappear inthe polygon in this time, the occupancy state ofthe polygon is maintained. This allows movingobstacles to flicker out of existence for short inter-vals without disturbing the precedence ordering.

In cases where Boss stops at an intersection andnone of the other vehicles move, Boss will wait 10seconds before breaking the deadlock. In this casethe precedence estimator assumes that the othertraffic at the intersection is not taking precedenceand asserts that Boss has precedence. In these situ-ations other elements of the behavioral executivelimit the robot’s maximum speed to 5 mph, caus-ing it to proceed cautiously through the intersec-tion. Once the robot has begun moving throughthe intersection, there is no facility for aborting themaneuver, and the system instead relies on themotion planner’s collision-avoidance algorithmsand, ultimately, the intersection recovery algo-rithms to guarantee safe, forward progress shouldanother robot enter the intersection at the sametime.

Error RecoveryDespite best efforts to implement a correct and reli-able system, there will always be bugs in the imple-mentation and unforeseen and possibly illegalbehavior by other vehicles in the environment.The error recovery system was designed to ensurethat Boss handles these situations and “never givesup.” To this end, a good recovery algorithm shouldgenerate a sequence of nonrepeating motion goalsthat gradually accept greater risk; it should adaptbehavior to the driving context, since each contextincludes road rules that should be adhered to ifpossible and disregarded only if necessary in arecovery situation; and finally, the recovery systemshould also be kept as simple as possible to reducethe likelihood of introducing further softwarebugs.

Our approach is to use a small family of errorrecovery modes and maintain a recovery level.Each recovery mode corresponds to a nominaldriving context (driving down a lane, handling anintersection or maneuvering in an unstructuredarea). When in normal operation, the recovery lev-el is zero, but as failures occur, it is incremented.The recovery level is used to encode the level ofrisk that is acceptable. It is important to note that

Articles

SUMMER 2009 23

the recovery goal-selection process does not explic-itly incorporate any surrounding obstacle data,making it intrinsically robust to transient environ-mental effects or perception artifacts that maycause spurious failures in other subsystems.

All recovery maneuvers are specified as a set ofposes to be achieved and utilize the movementzone lattice planner to generate paths throughpotentially complicated situations. The successfulcompletion of any recovery goal returns the sys-tem to normal operation, resetting the recoverylevel. Should the same, or a very similar, normalgoal fail immediately after a seemingly successfulrecovery sequence, the previous recovery level isreinstated instead of simply incrementing fromzero to one. This bypasses the recovery levels thatpresumably failed to get the system out of troubleand immediately selects a goal at a higher level.

The on-road recovery algorithm involves gener-ating goals at incrementally greater distances downthe current road lane to some maximum distance.These forward goals (goals 1, 2, 3 in figure 6a) areconstrained to remain in the original lane of trav-el. If none of the forward goals succeed, a goal isselected a short distance behind the vehicle (goal4) with the intent of backing up to provide a newperspective. After backing up, the sequence of for-ward goals is allowed to repeat once more with anoffset, after which continued failure triggers high-

er-risk maneuvers. For example, if there is a laneavailable in the opposing direction, the road iseventually marked as blocked, and the systemissues a U-turn goal (goal 5) and attempts to followan alternate path to the goal. The intersectionrecovery algorithm involves attempting to navi-gate alternate paths through an intersection andthen alternative routes through the road network.The desired path through an intersection is asmooth interpolation between the incoming andoutgoing lanes that may be blocked by some obsta-cle in the intersection or may be infeasible to drive.Thus, the first recovery level (goal 1 in figure 6b) isto try to achieve a pose slightly beyond the origi-nal goal using the lattice planner, with the wholeintersection as its workspace. This quickly recoversthe system from small or spurious failures in inter-sections and compensates for intersections withturns that are tighter than the vehicle can easilymake. If the first recovery goal fails, alternateroutes out of the intersection (goals 2, 3, 4) areattempted until all alternate routes to the goal areexhausted. Thereafter, the system removes the con-straint of staying in the intersection and selectsgoals incrementally further out from the intersec-tion (goals 5, 6).

The unstructured zone recovery procedure variesdepending on the current objective. Initially, thealgorithm selects a sequence of goals in a regular,

Articles

24 AI MAGAZINE

1m

Stop Line Occupancy Polygon

LaneIntersection3m 1m

1m1m

Figure 5. A Typical Occupancy Polygon for a Stopline.

triangular pattern, centered on the original goal asshown in figure 6(c). If, after attempting this com-plete pattern, the vehicle continues to fail to makeprogress, a more specialized recovery process isinvoked. For parking spot goals, the pattern is con-tinuously repeated with small incremental angularoffsets, based on the assumption that the parkingspot will eventually be correctly perceived as emp-ty, or the obstacle (temporarily) in the spot willmove. If the current goal is to exit the parking lot,

the algorithm tries first to use alternative exits, ifthose exits fail, then the algorithm issues goals tolocations on the road network outside of the park-ing lot, giving the lattice planner free reign in gen-erating a solution out of the parking lot.

An independent last-ditch recovery systemmonitors the vehicle’s motion. If the vehicle doesnot move at least one meter every five minutes, itoverrides any other goals with a randomly selectedlocal motion. The hope is that some small local

Articles

SUMMER 2009 25

5

4 1 2 3

a

6 5 1 2

34

OriginalGoalb

4

5

7

6

8

9

3

2

1

OriginalGoal

c

Figure 6. Boss Uses Context-Specific Recovery Goals to Provide Robustness to Software Bugs and Abnormal Behavior of Other Vehicles.

motion will either physically dislodge the vehicleor, by changing the point of view, clear any arti-facts due to noisy perceptions that are causing thefailure. Upon successful completion of thismotion, the recovery level is reset, enabling thevehicle to continue on its way. This functionalityis analogous to the “wander” behavior (Brooks1986).

The components described in this section arejust a few examples of the autonomy componentsthat caused Boss to drive safely. For a more indepth overview, we point the reader to Urmson etal. (2008)

PerformanceDuring testing and development, Boss completedmore than 3000 kilometers of autonomous driv-ing. The most visible portion of this testing

occurred during qualification and competition atthe DARPA Urban Challenge. The event was heldat the former George Air Force Base in Victorville,California, USA (figure 7). During qualification,vehicles were required to demonstrate their abili-ties in three test areas. Area A required theautonomous vehicles to merge into and turnacross dense moving traffic. Vehicles had to judgethe size of gaps between moving vehicles, assesssafety, and then maneuver without excessivedelay. For many of the vehicles, this was the mostdifficult challenge, as it involved significant rea-soning about moving obstacles. Area B was a rela-tively long road course that wound through aneighborhood. Vehicles were challenged to findtheir way through the road network while avoid-ing parked cars, construction areas, and other roadobstacles but did not encounter moving traffic.Area C was a relatively short course but required

Articles

26 AI MAGAZINE

Figure 7. The Urban Challenge Final Event Was Held on a Road Network in and around the Former George Air Force Base.

autonomous vehicles to demonstrate correctbehavior with traffic at four-way intersections andto demonstrate rerouting around an unexpectedlyblocked road. Boss demonstrated safe and reliabledriving across all of these areas and was the firstvehicle to qualify for the Urban Challenge compe-tition.

During the final event, the 11 finalists wererequired to drive 52 miles in and around the basewhile interacting with each other and fifty human-driven vehicles. Six of the 11 teams that enteredthe final competition completed the course(Buehler, Lagnemma, and Singh 2008). Boss fin-ished approximately 19 minutes faster than thesecond-place vehicle, Junior (from Stanford Uni-versity), and 26 minutes ahead of the third-placevehicle, Odin (from Virginia Polytechnic Institueand State University). The vehicles from CornellUniversity, the Massachusetts Institute of Tech-nology, and the University of Pennsylvania round-ed out the finishers, but each of these vehiclesrequired some human intervention to completethe course. All of the vehicles that completed thechallenge performed impressively with only rela-tively minor driving errors: Boss twice incorrectlydetermined that it needed to make a U-turn, result-ing in driving an unnecessary 2 miles; Junior hada minor bug that caused it to repeatedly loop twicethrough one section of the course; and Odinincurred a significant GPS error that caused it todrive partially off the road for small periods oftime. Despite these glitches, these vehicles repre-sent a new state of the art for autonomous urbandriving.

During the final competition, the value of Boss’serror recovery system was demonstrated on 17occasions. All but 3 of these errors were resolvedby the first error recovery level, which, in general,meant that an outside observer would not detectthat anything untoward had occurred. Theremaining three recoveries consumed more thanhalf of the 11 minutes the vehicle spent in errorrecovery modes and were generally due to soft-ware bugs or sensor artifacts. For example, the U-turn mistakes described above were due to a com-bination of perception and planning bugs thatcaused the system to believe that the path forwardalong the current lane was completely and per-sistently blocked by other traffic when there was,in fact, no traffic at all. After repeated attempts tomove forward, the recovery system declared thelane fully blocked, commanded a U-turn, and fol-lowed an alternate route to its goal. While subop-timal, this behavior demonstrated the recoverysystem’s ability to compensate for subtle butpotentially lethal bugs in the software system. Theend result is that Boss demonstrated robust auton-omy in the face of the unexpected and its ownshortcomings.

DiscussionThe Urban Challenge was a compelling demon-stration of the state of the art in autonomousrobotic vehicles. It has helped to reinvigorate beliefin the promise of autonomous vehicles. While theUrban Challenge is not wholly representative ofdaily driving, it does represent a significant steptoward achieving general driving. Some of theremaining challenges include diagnostics, valida-tion, improved modeling, and autonomous vehi-cle and driver interaction.

Diagnostics: It is essential that autonomous vehi-cles understand when they are in a safe workingcondition and when they should not be operated.Reliable detection and diagnosis of certain classesof sensor and operational faults are very difficult.

Validation: Prior to deploying something as safe-ty critical as an autonomous vehicle, we must haveconfidence that the vehicle will behave as desired.While there has been significant progress in bothsystems engineering and automated software vali-dation, neither field is yet up to the task of vali-dating these complex autonomous systems.

Improved modeling: The Urban Challenge offeredonly a subset of the interactions a driver faces dai-ly; there were no pedestrians, no traffic lights, noadversarial drivers, and no bumper-to-bumper traf-fic. A sufficient and correct model of the world forcomplex urban driving tasks is yet to be developed.

Autonomous vehicle and driver interaction: By notallowing drivers in the Urban Challenge robots,this problem was irrelevant, but whenautonomous vehicles are deployed, the sharing ofcontrol between driver and vehicle will be critical-ly important. We are only just beginning to under-stand how to approach this problem.

Many of these items will best be addressed byapplying artificial intelligence and machine-learn-ing techniques since they require complicatedmodels that are difficult to explicitly encode.Despite these challenges, autonomous vehicles arehere to stay. We have already begun work withCaterpillar to use techniques and algorithms devel-oped during the Urban Challenge to automatelarge off-highway trucks for mining applications.The automotive industry is interested in improv-ing existing driver assistance systems by usingautonomous vehicle techniques to further reducetraffic accidents and fatalities (global traffic acci-dent fatalities exceed 1.2 million people each year),reduce congestion on crowded roads, and improvefuel economy. The question is no longer if vehicleswill become autonomous but when and where can Iget one?

AcknowledgmentsThis work would not have been possible withoutthe dedicated efforts of the Tartan Racing team andthe generous support of our sponsors including

Articles

SUMMER 2009 27

AAAI Executive Council Nominations Needed!

To submit a candidate’s name for consideration, please sendthe individual’s name, address, phone number, and e-mailaddress to Carol Hamilton, Executive Director, AAAI, 445Burgess Drive, Menlo Park, CA 94025; by fax to 1-650-321-4457; or by e-mail to hamilton@aaai.org. Nominators shouldcontact candidates prior to submitting their names to verifythat they are willing to serve, should they be elected. Thedeadline for nominations is November 1, 2009.

General Motors, Caterpillar, and Continental. Thiswork was further supported by DARPA under con-tract HR0011- 06-C-0142.

Notes1. See the DARPA 2005 Grand Challenge website(www.darpa.mil/grandchallenge05).

2. See the DARPA 2007 Urban Challenge website(www.darpa.mil/grandchallenge).

ReferencesBaker, C., and Dolan, J. 2008. Traffic Interaction in theUrban Challenge: Putting Boss on Its Best Behavior. InProceedings of the IEEE/RSJ International Conference on Intel-ligent Robots and Systems (IROS ’08), 1752–1758. Piscat-away, NJ: Institute of Electrical and Electronics Engineers,Inc.

Brooks, R. A. 1986. A Robust Layered Control System fora Mobile Robot. IEEE Journal of Robotics and Automation2(1): 14–23.

Buehler, M.; Lagnemma, K.; and Singh, S.; eds. 2008. Spe-cial issues on the 2007 DARPA Urban Challenge, Parts 1–3. Journal of Field Robotics 25(8, 9, 10).

Darms, M.; Rybski, P.; and Urmson, C. 2008. Classifica-tion and Tracking of Dynamic Objects with Multiple Sen-sors for Autonomous Driving in Urban Environments. InProceedings of the 2008 IEEE Intelligent Vehicles Symposium,1197–1202. Piscataway, NJ: Institute of Electrical andElectronics Engineers, Inc.

Ferguson, D.; Baker, C.; Likhachev, M.; and Dolan, J.2008. A Reasoning Framework for Autonomous UrbanDriving. Proceedings of the 2008 IEEE Intelligent VehiclesSymposium. Piscataway, NJ: Institute of Electrical andElectronics Engineers, Inc.

Ferguson, D.; Howard, T.; and Likhachev, M. 2008a.Motion Planning in Urban Environments: Part I. In Pro-ceedings of the IEEE/RSJ International Conference on Intelli-gent Robots and Systems (IROS ’08). Piscataway, NJ: Insti-tute of Electrical and Electronics Engineers, Inc.

Ferguson, D.; Howard, T.; and Likhachev, M. 2008b.Motion Planning in Urban Environments: Part II. In Pro-ceedings of the IEEE/RSJ International Conference on Intelli-gent Robots and Systems (IROS ’08). Piscataway, NJ: Insti-tute of Electrical and Electronics Engineers, Inc.

Howard, T.; Green, C.; Ferguson, D.; and Kelly, A. 2008.

State Space Sampling of Feasible Motions for High Per-formance Mobile Robot Navigation in Complex Envi-ronments. Journal of Field Robotics 25(1): 325–345.

Thrun, S.; Montemerlo, M.; Dahlkamp, H.; Stavens, D.;Aron, A.; Diebel, J.; Fong, P.; Gale, J.; Halpenny, M.; Hoff-mann, G.; Lau, K.; Oakley, C.; Palatucci, M.; Pratt, V.;Stang, P.; Strohband, S.; Dupont, C.; Jendrossek, L.-E.;Koelen, C.; Markey, C.; Rummel, C.; van Niekerk, J.;Jensen, E.; Alessandrini, P.; Bradski, G.; Davies, B.;Ettinger, S.; Kaehler, A.; Nefian, A.; and Mahoney, P.2006. Stanley: The Robot that Won the DARPA GrandChallenge. Journal of Field Robotics 23(9): 661–692.

Urmson, C.; Anhalt, J.; Bartz, D.; Clark, M.; Galatali, T.;Gutierrez, A.; Harbaugh, S.; Johnston, J.; Kato, H.; Koon,P. L.; Messner, W.; Miller, N.; Mosher, A.; Peterson, K.;Ragusa, C.; Ray, D.; Smith, B. K.; Snider, J. M.; Spiker, S.;Struble, J. C.; Ziglar, J.; ; and Whittaker, W. R. L. 2006. ARobust Approach to High-Speed Navigation for Unre-hearsed Desert Terrain. Journal of Field Robotics 23(8):467–508.

Urmson, C.; Anhalt, J.; Bae, H.; Bagnell, J. D.; Baker, C.;Bittner, R. E.; Brown, T.; Clark, M. N.; Darms, M.; Demitr-ish, D.; Dolan, J.; Duggins, D.; Ferguson, D.; Galatali, T.;Geyer, C. M.; Gittleman, M.; Harbaugh, S.; Hebert, M.;Howard, T.; Kolski, S.; Likhachev, M.; Litkouhi, B.; Kelly,A.; McNaughton, M.; Miller, N.; Nickolaou, J.; Peterson,K.; Pilnick, B.; Rajkumar, R.; Rybski, P.; Sadekar, V.;Salesky, B.; Seo, Y.-W.; Singh, S.; Snider, J. M.; Struble, J.C.; Stentz, A. T.; Taylor, M.; Whittaker, W. R. L.; Wolkow-icki, Z.; Zhang, W.; and Ziglar, J. 2008. Autonomous Driv-ing in Urban Environments: Boss and the Urban Chal-lenge. Journal of Field Robotics 25(8): 425–466

Chris Urmson is an assistant research professor in theRobotics Institute at Carnegie Mellon University. Heserved as the director of technology for Tartan Racing,leading the development of Boss.

Chris Baker is a graduate student at the Robotics Insti-tute at Carnegie Mellon University. He worked on Boss’sbehavioral reasoning and fault recovery algorithms.

John Dolan is a senior systems scientist in the RoboticsInstitute at Carnegie Mellon University. He served as thebehaviors lead for Tartan Racing.

Paul E. Rybski is a systems scientist in the Robotics Insti-tute at Carnegie Mellon University. He served as the per-ception lead for Tartan Racing.

Bryan Salesky is a commercialization specialist at theNational Robotics Engineering Center of the RoboticsInstitute at Carnegie Mellon University. He served as thesoftware lead for Tartan Racing.

William “Red” Whittaker is the Fredkin UniversityResearch Professor of Robotics at Carnegie Mellon Uni-versity. Whittaker was Tartan Racing’s team leader.

Dave Ferguson is a researcher at Two Sigma Investments.He was the planning lead for Tartan Racing’s Urban Chal-lenge team.

Michael Darms is team leader in the Advanced Engi-neering Department of Continental’s Chassis and SafetyDivision. He worked on the perception system of Bossand was responsible for object tracking algorithms.

Articles

28 AI MAGAZINE