A Mission Planning System forMultiple Mobile Robots inUnknown, Unstructured, andChanging Environments

Submitted in partial fulfillment ofthe requirements for the degree ofDoctor of Philosophy in Robotics

By Barry L. Brumitt

The Robotics InstituteCarnegie Mellon UniversityPittsburgh, PA 15213

January, 1998

1998 by Barry L. Brumitt. All rights reserved.

This research was sponsored by DARPA, under contracts “Perception for OutdoorNavigation” (contract number DACA76-89-C-0014, monitored by the US ArmyTopographic Engineering Center), “Unmanned Ground Vehicle Systems” (contractnumber DAAE07-90-C-R059, monitored by TACOM), and “TechnologyEnhancements for Unmanned Ground Vehicles” (contract number DAAE07-96-C-X075, monitored by TACOM). The views and conclusions contained in this documentare those of the author and should not be interpreted as representing the official policies,either expressed or implied, of DARPA, TACOM, or the U.S. Government.

i

Abstract

Research in autonomous mobile robots has reached a level of maturity where roboticsystems can be expected to efficiently perform complex missions involving multipleagents in unstructured environments. Across a wide space of real-world tasks,particularly those which are expensive or risk-intensive, efficient teams of autonomouscooperative mobile robots could provide a valuable alternative to current solutions.Through the distribution of computation, perception, and action, a cooperative robotteam is more capable than the sum of its parts, as this team exhibits increased reliabilityand the ability to complete physically distributed tasks.

For multiple mobile robots to be effective in real-world applications, more than onerobot must be able to safely share a potentially unknown workspace. Complicatedmissions with interdependencies between these robots must be feasible. Finally, roboticsystems must accommodate an operational environment which is not necessarily static,certain, or known in advance.

Many tasks which are likely candidates for robotic automation (such as hazardouswaste site remediation, planetary exploration, materials handling and militaryreconnaissance), require a robot team to perform an essentially mobile mission whichinvolves robots moving between significant locations. It is important that thesemissions be completed efficiently, appropriately minimizing the cost of the task. Thesimilarities among these tasks indicate that a single general system could supportcoordinated mission execution for many scenarios.

To this end, GRAMMPS (a General Robotic Autonomous Mobile Mission PlanningSystem) has been developed. GRAMMPS supports the optimization of real-worldmissions involving multiple robots and multiple concurrent goals. The largestcomponent of GRAMMPS is its central planner, which continuously optimizes theexecution of a multi-robot mission as information about the world is acquired.GRAMMPS distributes its computation, gracefully degrades from optimal performancewhen presented with computationally intractable missions, and performs efficientreplanning in an unknown, unstructured, and changing environment. This system hasbeen demonstrated on two autonomous outdoor mobile robots and extensivelyvalidated in simulation.

Abstract

ii

iii

Acknowledgments

Rather than attempt an all-inclusive list of people who’ve been helpful, invaluable,supportive, insightful, and so forth, I’ll just blurble mickurt feemur marb.

Acknowledgments

iv

v

Contents

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Problem and approach 1Synopsis 6

Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Multi-Robot Systems 9Supporting Technologies & Architecture 17Other planning systems 23Summary 28

Mission Planner: Design & Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Conceptual Overview 29Mission Grammar 30An Intuition Interlude 36Grammar Compiler 38GRAMMPS Central Planner 43Component Planners 51Summary 59

Results from Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Simulation Details 61Results and insights 64Summary 73

Contents

vi

Demonstration System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Architecture Overview 75The Local Navigator 78Position Estimation 82Dynamic Path Planning 84Steering Arbiter 92Distributed Operation 94Field Trials 98Summary 108

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Contributions 109Accomplishments 110Insights and Lessons Learned 110Future directions 111

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

1

Chapter 1

Introduction

Research in autonomous mobile robots has reached a level of maturity where roboticsystems can be expected to efficiently perform complex missions involving multipleagents in natural environments. To this end, GRAMMPS (a General RoboticAutonomous Mobile Mission Planning System) has been developed. GRAMMPSsupports the optimization of real-world missions involving multiple robots and multipleconcurrent goals. The largest component of GRAMMPS is the central mission planner,which continuously optimizes the execution of a multi-robot mission as informationabout the world is acquired. This system was both demonstrated on two autonomousoutdoor mobile robots and extensively validated in simulation. This documentdescribes the design and implementation of this system, and offers some fundamentalinsights into the nature of fieldable multi-robot systems.

Problem and approach 1.1

The Big Picture 1.1.1

Mobile robots represent a budding new technology capable of changing a huge portionhuman activity. This century has seen the role of stationary robotic arms in factorieschange from a new concept to virtual ubiquity in the manufacturing process. Mobilerobots have recently reached adolescence, moving from laboratory experiments toprototype fieldable systems. In the last year alone, mobile robots have explored Marsand the Atacama desert, driven at highway speeds on Route 15 in San Diego, harvestedacres of alfalfa, and walked unassisted up flights of stairs. This explosion ofdemonstrated capability in mobile robotics is largely due to the ever-decreasing cost ofcomputation and related digital technologies, such as GPS receivers, CCDs, MEMS,etc. Taken as a set, these new technologies are providing inexpensive eyes and brainsfor autonomous machines. Mobile robots have the potential to be used in hazardousenvironments (such as nuclear power plants, oil platforms, hazardous waste sites), in

Introduction

2

big industry (silicon manufacturing, dock yards, central post offices, construction sites),and at a consumer level (lawn-moving, cleaning, entertainment, transportation).

While many systems to date have relied on teleoperation as their primary modusoperandi, autonomy is an increasingly important focus for fieldable systems. Whereone person could once drive only one tractor or vehicle, autonomy can permit a singleoperator to control and manage a fleet of mobile robots. Teleoperation also fails inenvironments where constant contact between operator and robot cannot be maintainedfor reasons of distance, expense, or security. Many tasks are also too tedious or complexfor teleoperation to provide an effective solution. Autonomous robots offer the potentialof a tireless worker, capable of performing complex long-duration tasks in inhospitableenvironments at reasonable cost. Making robots more autonomous greatly increasestheir applicability to real-world tasks.

In applications where one autonomous robot is good, more than one robot is likely tobe even better. Multiple mobile robots can carry out tasks which are inherentlydistributed in location, time, and/or functionality. For example, several tractors mightmow a field more quickly than one, or a cutter, a baler and a thresher could worktogether as a team in a single field. Perhaps even more significantly, multiple robotsprovide a distributed system with all the advantages inherent thereto, including faulttolerance, redundancy, and reliability.

For the majority of real robotic applications, the operational environment is not staticor structured. A priori information may be incorrect, commands may not be executedcorrectly, and perception information may contain noise; in general, unexpected eventsmay occur frequently. To be successful and robust in real world operations, roboticsystems must accommodate the fact that the world is dynamic and changing, and maynot be amenable to a simple environmental model. Therefore, whatever plan a robotmay be executing must be allowed to change regularly as new information about theworld and the task arrives.

Beyond merely succeeding at a task, it is important for mobile robot systems to performtasks efficiently. Failing to compete effectively with humans performing the same task,or appearing to act capriciously or randomly will prevent mobile robots’ acceptance intarget areas of application. Multiple mobile robots bring an economy of scale to mobilerobots, allowing many relatively interchangeable robots to be manufactured anddeployed more easily, instead of relying on a single expensive custom robot.

Collectively, these ideas paint a picture of the immense potential advantage ofcooperative autonomous mobile robot systems, but also illustrate the challenges ofefficient operation in unstructured environments. Cooperative mobile robotics is poisedfor a phase of explosive growth because fundamental capabilities of single robots arebeginning to reach maturity, enabling affordable autonomous robots. Cooperativerobotics requires new ideas for mechanisms, software, and hardware. Currently, fewautonomous multi-robot systems have moved beyond the lab into field deployment.

This thesis describes a partial solution to the problem of coordinating multiple mobilerobots operating in natural terrain, addressing issues including mission planning,dynamic path planing, map sharing, distributed system architecture, and executionoptimization. This chapter briefly introduces current work in this field, defines a scope

Introduction

3

of research, provides a succinct problem statement, and introduces the approachutilized in this work.

The Story So Far 1.1.2

To date, work in autonomous mobile robotics for natural environments has beenprimarily concerned with maintaining robot safety while moving in the environment.Robotic tasks, particularly in the outdoor realm, have been largely limited to pathtracking with obstacle avoidance, or to single-robot / single-goal scenarios. Localautonomous navigation technology has progressed to a point where it is possible tospecify more complicated missions for single or even multiple mobile autonomousagents without first having to design an entire perception and control system to handlelocal obstacle avoidance. For mobile robotics to be effective in real-world domains,more than one robot must be able to safely share a potentially unknown workspace andcomplicated missions with interdependencies between these robots must be feasible.

Many independent areas of research contribute to aspects of these tasks, such as AI-planning, motion planning, and outdoor navigation. In addition, there exists a widevariety of work explicitly concerned with multi-robot systems, including completeimplementations and component research. However, existing systems for autonomousrobots fail to permit the execution of complex missions by multiple robots inunstructured environments because they do not adequately address three primarydifficulties with these missions:

• mission planning• dynamic planning• distributed planning

Mission planning is the process of determining what each robot should do to achievethe goals of the mission. Isolated autonomous robot systems typically either address asingle problem, or are only navigation testbeds, concerned with avoiding situationswhich endanger the robot. Existing cooperative robotic systems frequently overlook thedemands of the overall task when determining a course of action, or are limited to asingle type of cooperative task.

Dynamic planning is the process of updating the mission plans (i.e. changing eachrobot’s plan or current goal location) when further knowledge of the world is gained, orwhen the robot fails to follow the mission-planner’s directions. Many autonomoussystems do not consider efficient performance of the mission, particularly with respectto changing the mission plan as information about the environment is gained.

Distributed planning permits the other two types of planning to occur in a decentralizedfashion. It is unrealistic to expect all robots to communicate all information about theworld to a single central planner which then adjusts plans and communicatesinstructions back to the individual robots. Each robot should be as independent aspossible, which will give the system of robots all the advantages typical of distributedsystems, including fault tolerance, reduced communications bandwidth, and improvedresponse time.

Therefore, while aspects of the problem of coordinated multiple mobile robots havebeen addressed independently, existing systems fail to attack the unique demands ofefficient operation of robot teams in unstructured environments. Essential components

Introduction

4

of mobile robot systems have been designed and demonstrated (such as path planners,local navigators, task schedulers, etc.), but the complexity of an integrated systemintended for field deployment requires that complete systems be developed to fullyunderstand the problem, and to verify the strengths and weaknesses of a solution.

Scope 1.1.3

This thesis describes the design, implementation and testing of a complete systemwhich addresses the problem of operating multiple mobile robots in unstructuredenvironments. This system is called GRAMMPS, or a “General Robotic AutonomousMobile Mission Planning System.”

GRAMMPS is designed to provide a solution to applications which benefit from groupsof autonomous mobile robots, allowing them to efficiently accomplish tasks in dynamicenvironments. However, the thesis does not address every aspect of a particularapplication which could so benefit. Assumptions are made concerning capabilities ofthe robot, the nature of the operational environment, and the class of tasks which can beaddressed. While the demonstration testbed for GRAMMPS utilized two particular full-scale autonomous off-road vehicles, GRAMMPS is designed to be general, capable ofoperation on any platform which meets basic requirements outlined below.

Robots to be used with GRAMMPS are assumed to have effective infrastructure(positioning and communications) and basic navigation capabilities (perception,obstacle detection and avoidance). On the demonstration testbed, GPS and radioethernet were used to meet the first requirement. Basic navigation (autonomous driving)was provided by Smarty [Langer94a], utilizing either stereo vision or laser ranging.GRAMMPS expects a positioning system able to provide each robot’s location withina graph, and expects the perception system to provide costs of transitions between statesin this graph. For example, an 8-connected grid is an acceptable representation, aswould be a graph of hallways and intersections in a warehouse.

Environments to be addressed by this work are those which are typical to mobile robotsoperating in unstructured terrain. GRAMMPS assumes that the local navigator on arobot is capable of preventing the vehicle from endangering itself. The workspace isassumed to be relatively open, so that a motion planner need not concern itselfovermuch with resolving collisions between robots. The algorithmic complexity of theplanning problem increases exponentially if inter-robot collisions must be explicitlyconsidered; however, most workspaces allow simple behaviors to avoid and resolvesuch circumstances.

Finally, missions capable of being planned, executed and optimized within GRAMMPSare those which may be expressed with a mission grammar. This grammar permits theexpression of missions for the robot team which involve conjunctions, disjunctions, andordering of robots and goals and sub-tasks. Expressing more complex missions wouldrequire either extensions to the existing system, or a higher-level planner/executorcapable of using GRAMMPS as an operational component. While typical AI-style pre-/post-condition planners search for satisfying plans, GRAMMPS searches for theoptimal solution to a given mission statement. An optimal solution is one thatminimizes the time until mission completion.

Introduction

5

The assumptions described in this section roughly delineate the type of problem(including robots, environments and tasks) which are addressed by this thesis. Theessential power of this approach is that it leverages off existing basic capabilities inmobile robots, permitting the optimized execution of complex missions by multiplerobots in natural environments.

Problem Statement 1.1.4

GRAMMPS represents the state of the art in dynamic mission planning for multiplemobile robots in unstructured environments. This thesis uses GRAMMPS as a vehiclefor exploring the basic requirements of such systems, including investigations into thecomputational requirements for dynamic planners, the utility of randomized planningfor GRAMMPS-style missions, and the nature of simulations required for testing.

The problem addressed in this thesis is stated as follows:

To support:• motion planning and• complex missions

for:• multiple robots,• multiple concurrent goals, and• unstructured environments,

using mobile robots which have:• relatively open operational workspaces,• similar mobility characteristics, and• effective positioning, communication and perception,

in order to permit:• successful, optimized task execution, and• dynamic replanning as world knowledge increases.

Approach 1.1.5

Given the scarcity of systems which address problems within this scope, this thesistakes the approach of building a system which satisfies the basic requirements formobile missions involving multiple robots in unstructured environments, and thenexplores the consequences of these decisions. The system designed is explicitlyengineered to work with existing obstacle avoidance systems, operating in asupervisory manner to the moment-to-moment demands of maintaining robot safety.Rather than using an explicitly defined robot architecture, a message-passinginfrastructure is used with a group of separate computation modules, each responsiblefor a portion of the overall system function. Beyond merely providing simulationresults, a complete demonstrated system which successfully controlled two full-scalemobile robots in natural terrain will be described in detail.

While this thesis describes a particular approach to this problem, as well as particularrobots and operating environments, both the system as a whole and the primarycomponents thereof are intended to be generally applicable to a wide class ofapplications. The generality of the developed system lies in the expressiveness of the

Introduction

6

grammar, which encompasses a large variety of missions, and in the general class oflocal navigation and perception systems which may be easily integrated.

This thesis describes a line of reasoning and research that has resulted in a partialsolution to the problem above, and demonstrates that:

• Existing systems are inadequate for dynamic mission planning for multiple robots andconcurrent goals in unstructured environments

• GRAMMPS enables a variety of heretofore unattempted tasks for cooperative mobilerobots operating in unstructured environments.

• This research advances several landmark technologies for the efficient operation ofsuch robots.

Synopsis 1.2

This thesis describes the design and implementation of GRAMMPS, demonstrates itseffectiveness and utility for real-world applications, and investigates the general needsof fieldable multi-robot systems, thereby laying the groundwork for future endeavors inthis area.

Background and Related Work 1.2.1

GRAMMPS stands on the shoulders of giants, utilizing existing capabilities inperception, planning and obstacle avoidance to enable missions involving multiplerobots. Other researchers have investigated very closely related areas of work; however,they fall short of producing complete fieldable systems for a variety of reasons. Thischapter will detail both supporting work and that research which comes closest toproviding the capabilities of GRAMMPS.

Mission Planner: Design & Implementation 1.2.2

The central mission planner provides the core decision-making capabilities forGRAMMPS; this chapter takes a functional perspective in describing the componentswhich constitute this planner. A mission grammar provides a succinct definition formissions which are amenable to GRAMMPS. A parser takes mission statementsprovided in the grammar and manipulates them into a ‘plannable’ form. The plannerand replanner compute and continuously update the current plan, determining whateach robot should be doing at any time to best help with the mission. Sub-planners workon computationally intensive components of the mission. Additionally, work insimulation has been essential to the investigation and understanding of dynamicmission planning for multiple mobile robots.

Results from Simulation 1.2.3

This chapter describes and gives results from two different types of simulations whichwere used to demonstrate the capabilities of GRAMMPS as well as to investigate thecomputational requirements for dynamic mission planners and the utility ofrandomized planning for GRAMMPS-style missions. Simulations of several differentmissions involving robot teams in unknown environments are presented in detail.

Introduction

7

Demonstration System 1.2.4

Unfortunately, a planner alone does not make a complete mobile robot system. Adynamic path planner provides real-time cost updates for single steps within the plan.An inter-robot communications module permits the exchange of map informationbetween robots, avoids inter-robot collisions, and enables distributed planning. Anextensively engineered dynamic path-planning module computes optimal collision-freepaths for robots to follows. An arbiter resolves conflicts between the demands of thelocal obstacle avoidance and goal-seeking behaviors. Besides these softwarecomponents, this chapter describes some infrastructure issues includingcommunications, positioning, and distributed computation.

Introduction

8

9

Chapter 2

Background

Background

The research presented in this thesis concerns a fundamentally new addition to thesmall1 group of fully-implemented cooperative mobile robotic systems. While thiswork shares many characteristics of the previously implemented systems, it offers newcontributions: its abilities to utilize general task descriptions, to optimize missionexecution, and to operate in natural environments. As the first complete multi-robotsystem demonstrated in natural terrain, GRAMMPS stands on the shoulders of giants,utilizing existing, proven capabilities in perception, planning and obstacle avoidance toindividually enable each robot involved in the cooperative endeavor. This chapter firstexamines the taxonomy of multi-robot systems, considering both the design andcapabilities of existing systems with respect to the problem of coordinating multiplemobile robots in unstructured environments. The second section discusses supportingtechnologies for an outdoor autonomous mobile robot system, including robotarchitectures, autonomous local navigators, and map-building systems. This chapterconcludes with a brief discussion of the limitations of existing AI- and motion-planningsystems as related to the demands of mission planning for multi-robot systemsoperating in unknown, unstructured, and changing environments.

Multi-Robot Systems 2.1

Overview 2.1.1

Multi-robot systems are robotic projects and theories which address architectures andsystems for coordinating the behavior of multiple robots. This organization of thissection will loosely follow the recently proposed [Cao97] “Research Axes” for

1.Fewer than ten

Background

10

cooperative robotics. Before delving into a detailed comparison, however, it isimportant to limit the scope of relevant work, and provide some general motivation.

A multi-robot system involves a group of robots working in the same environment.While some systems worry about competitive, uncooperative, or selfish agents (e.g.[Asada94], [Reynolds94]) the problem statement addresses implicitly cooperative systems,which largely excludes such systems from consideration. In this vein, Cao [Cao97]

proposes the following definition for cooperative behavior:Given some task specified by a designer, a multi-robot system displayscooperative behavior if, due to some underlying mechanism (i.e. the“mechanism of cooperation”), there is an increase in the total utility of thesystem.

It is reasonable to expect a cooperative multi-robot system to exhibit a performancegain (an “increase in total utility”) over a single agent or even a a group of agents whoare not coordinating their efforts. Parker [Parker94b] offers a solid justification for theadvantages of cooperative mobile robots:

Achieving cooperative robotics is desirable for a number of reasons. First, manyrobotic applications are inherently distributed in space, time, or functionality,thus requiring a distributed solution. Second, it is quite possible that manyapplications could be solved much more quickly if the mission could be dividedacross a number of robots operating in parallel. Third, by duplicatingcapabilities across robot team members, one has the potential of increasing therobustness and reliability of the automated solution through redundancy.Finally, it may actually be much cheaper and more practical in manyapplications to build a number of less capable robots that work together at amission, rather than trying to build one robot which can perform the entiremission with adequate reliability.

The problem addressed by this thesis is motivated by precisely these concerns:applicability to tasks requiring a distributed solution, parallelizing missions viamultiple agents, and allowing fault tolerance and robustness by reallocating goals whenthe situation changes. Implicit in this statement is the notion of “tasks.” For thisproblem, a task is a specific operator-supplied mission expressed in a mission grammarconsisting of robots, goals, and desired relationships among them. It is assumed thatthis task should be performed efficiently; since one is using multiple robots rather thanonly one, it is almost certainly important to perform the task efficiently. Therefore, thisthesis is concerned with successful optimized mission completion.

However, there are classes of multiple-robot systems which are unconcerned with thenotion of a task. These systems tend to exist for the purpose of exploring the nature ofcooperation and the emergence of “intelligent” behavior from cooperative groups.Examples of these systems include SWARM [Beni91] and CEBOT [Fukuda93]. In both,many simple agents occupied simple environments and exhibited behaviors such aspattern generation and self-organization. In general, these systems are sufficientlyremoved from the space of task-oriented mobile robot systems as to be inapplicable tothe given problem statement.

Yet another group of systems is primarily concerned with cooperative forcefulinteraction with the environment, either with multiple mobile robots or with

Background

11

manipulators. These schemes are frequently cast in terms of the control laws ofessential behaviors needed to produce the particular motion. These systems, too, lieoutside of those relevant to the basic nature of the work described herein. Note,however, that box-pushing (a popular task for such control-law research) is also used asa task domain by some general cooperative systems. Those systems will be discussedas they do possess capabilities outside of a single domain.

The following discussion will step through several of the primary axes provided by[Cao97] (“Group Architecture”, “Resource Conflicts”, “Origins of Cooperation”,“Learning”), explaining the position and relevance of this research relative to othermulti-robot systems. In addition, it will explore the problem of coordinating multiplerobots in unstructured environments in terms of “Task Domain” and “MissionDecomposition.” This section will conclude with a summary of the benefits andadvances GRAMMPS offers over other systems.

Group Architecture 2.1.2

Group architecture for cooperative robots is not a trivial extension of those architectureswhich are designed for single robots because many issues arise which are irrelevant tosingle-agent systems. Cao [Cao97] proposes three areas2 in which cooperative robotsmay be compared in terms of their internal structure or architecture. They are“Centralized/Decentralized”, “Differentiation”, and “Communication Structure”.Clearly, these three areas are not applicable to single robots because with a single robot1) there is nothing to decentralize, and 2) there is no other robot to be different from or3) with whom to communicate. This subsection discusses how existing multi-robotsystems solve the problem of in terms of these basic architectural characteristics.

Centralized/Decentralized 2.1.2.1

At one extreme, a completely centralized system would have a single computer (orgroup of computers) working to control a fleet of robots. Each robot would necessarilyrelay all sensory information back to this central system, which would evaluate allinformation in light of the group task, and continuously control each robot. This isterribly inefficient, as many actions a robot takes are extremely local in nature, and arethus not amenable to a centralized structure. Examples include foot placement (forwalking robots), obstacle avoidance, and local manipulation tasks. Additionally,limited communications bandwidth and latencies in data transfer between robots implythat data-intensive or time-sensitive process should be performed locally to the robot inquestion. Therefore, it makes sense to place some computational capacity on eachrobot.

At the other extreme, a completely decentralized system has no central server, planner,or coordinating agent. Each robot is responsible for avoiding conflicts with, requestinghelp from, and offering assistance to other robots in the system. However, it is nigh-impossible to ensure optimal activity when all decisions are to be made locally, so inpractice most systems rely on some small degree of centralization. The advantagestouted for decentralized systems include “fault tolerance, natural exploitation of

2.Cao[Cao97] also proposes “Modeling of Other Agents”: this is not applicable to the problem addressesherein as this type of reasoning has largely been used in Box-Pushing or competitive paradigms whichare outside of this scope.

Background

12

parallelism, reliability, and scalability.” [Cao97] Examples of such systems includeALLIANCE [Parker94a], ACTRESS [Ishida94], Lumelsky’s Cocktail Party Model[Lumelsky97], and Mataric’s work in behavior-based systems[Mataric92]. All eschew acentralized approach. These systems tend to permit active negotiation between agentsproducing intentional cooperative behavior. However, some implementations([Lumelsky97], [Kube97]) have no explicitly coordinated activity. Any distributed taskaccomplishment occurs only because all robots are in the same environment. Somesystems do allow agents to have some pre-existing hierarchy which permitsnegotiations to occur more easily.

However, for the purposes of task-based efficiency and mission coordination, somecentralization is important, though some local tasks should be performed closer to theacting agent. A centralized mission planner which reasons about the entire task isimportant to ensure efficient execution. However, given the unstructured nature of theenvironment, the local navigation and obstacle avoidance is best performed separatelyon each robot. Many other systems utilize similar hybrid architectures. Robots in theGOFER system [LePape90] receive commands (e.g. “deliver crate to dock 37”) from acentral planner, but are then responsible for finding their own path to that location,avoiding other robots along the way. Aguilar [Aguilar95] and Alami [Alami95] offer a PlanMerging Paradigm, which provides central directives, and permits robots toindependently merge and resolve conflicts between plans. Similarly, Causse [Causse95]

utilizes a central schedule to dispatch robots that are expected to resolve local conflictsas they arise. Other examples in this paradigm include [Noriels93] and [Lueth94].

Differentiation 2.1.2.2

Differentiation refers to variation in the natures of the robots available for use in thesystem. A homogenous approach assumes all robots have identical capabilities. Aheterogeneous system permits and may reason about differences in capabilities amonginvolved agents. A typical paradigm for understanding heterogeneity is to have a modelof tasks which a given robot may participate in, such as in ALLIANCE [Parker94b] andACTRESS [Ishida94]. This capability is not limited to decentralized systems: GOFER[LePape90] allows functional differentiation to be performed by the central planner.

For the problem addressed by this thesis, allowing differentiation among the robotsexecuting a mission can only enable a larger set of applicable real-world tasks.However, it is difficult to permit robots which are extremely different to interact directlyand explicitly. Construction projects illustrate this well: though all workers may bebuilding the same structure, electricians will only work on the electric systems, masonswill only work on bricklaying, and so forth. Therefore, as the problem statementexpresses, only robots of “similar mobility characteristics” will be addressed in thisparadigm. This simplifies problems of map information exchange and conflictresolution.

GRAMMPS allows heterogeneity in two ways. First, the mission statement canexplicitly assign some goals to certain robots, while excluding others from suchassignments. In an office mail-delivery task [Vestli96], where some robots could liftheavier boxes than others, the mission statement might assign all robots to the smallpackages, but only assign the larger robots to the big packages. The system wouldensure the task was done efficiently, likely instructing the large robots to take care of

Background

13

the parts of the mission which only they can accomplish. Second, it is possible tomeasure the relative performances of the robots and then weigh them appropriatelywhen determining how each robot contributes to the mission. For example, if one robotoperates at half the speed of another robot, it would be given a total path to followduring the mission which is half the length of the other’s. In this way, many aspects ofheterogeneous robots can be captured by GRAMMPS.

Communications Structures 2.1.2.3

There are three basic ways robots may communicate with each other. First, via theenvironment: if one robot has picked up a Coke can, others can observe the lack of theCoke can and change their intentions accordingly. Second, via sensing: one robot mayobserve another robot’s actions and modify its own action accordingly. Third, viaexplicit communication. The first two are challenging to use for systems which performcomplex missions, as they require very capable perception and optimized activity. Mostmulti-robot systems which expect task completion utilize some form of explicitmessage passing. These messages can be passed as broadcast messages to all robots[Yoshida96], as local messages to nearby robots [Arai96][Li94], or published on a centralblackboard [Wang90]. The problem with explicit message passing is that it requiresextensive engineering to design a comprehensive system; more biologically motivatedsystems typically limit their use of this type of communication.

For the problem statement at hand, it is therefore appropriate to use explicitly-engineered communication structures. Part of the problem statement assumes all robotscan communicate with all other robots selectively. A Publish/Subscribe [Gowdy94]

mechanism can be a very effective methodology, effectively combining the three typesof communications described above (local, broadcast, blackboard), providing theneeded messages to each subscribing process on each robot. For example, the centralplanner can publish the current plan for every robot, each robot’s map-sharing modulecan broadcast map changes, and each robot can broadcast its current location.

Group Architecture Summary 2.1.2.4

For efficient operation, coordinated robots working on a task in an unstructuredenvironment require a degree of centralized operation. However, the unpredictably ofthe environment plus the need for robust operation demand a degree of decentralizationto enable reactivity and some fault-tolerance. Allowing differentiation between robotspermits a multi-robot system to address more complex tasks more effectively. Finally,the efficient execution of complex missions requires explicit communication betweenrobots.

Resource Conflicts 2.1.3

The notion of resource conflicts usually refers to the need to avoid inter-robotcollisions, though some cooperative robotics research uses the term to refer tocontention for communications bandwidth or a manipulable object. The latter situationsare typically resolved by, respectively, engineering the communications medium andcareful task planning. Methods of avoiding inter-robot collisions can be assessed interms of the Centralized/Decentralized division which has been previously discussedpreviously. It is extremely computationally expensive to plan coordinated paths whichexploit account for robot collision avoidance; this is discussed extensively in Motion

Background

14

Planners below. However, some systems such as GOFER [LePape90] do rely on a centralschedule to keep robots from getting into conflicts. It is unclear how these schemeswould scale to larger environments or larger number of robots. Most systems, therefore,rely on some form of local (i.e. decentralized) collision avoidance to ensure robot safetywhile moving in the environment.

Examples of systems or techniques for local avoidance abound. Some systems haveexplicit models of types of conflicts and methods of resolution, including [Causse95],[Arai96], [Li94], and [Alami95]. Others rely on more ad hoc or heuristic methods to ensurerobots pass by each other successfully ([Lumelsky97], [Minami96]). No system has aprovably complete method for ensuring that deadlock conditions do not arise in thegeneral case for general environments. Fortunately, for real applications, robots do notneed to spend the majority of their time avoiding each other whilst maneuvering incramped spaces. For this reason, local avoidance schemes are very successful.

For applications in which task completion is the primary goal, it is reasonable to expectplenty of maneuvering room and/or large intersections. Few environments in thetargeted application areas such as construction, warehouse automation, planetaryexploration, etc., are likely to require tightly constrained motion. Since crowdedlocations are atypical, the resolution of conflicts should consume a very smallpercentage of the overall execution time. This should permit local avoidance schemesto be successful and efficient, requiring only exception-based handling of particularlypathological cases. Azarm [Azarm96] presents one excellent example of a hierarchicalconflict resolution scheme. It is unclear how well this system would scale to largenumbers of robots. For particular environments, the Plan Merging Paradigm [Alami95]

might provide an exceptionally scalable and robust solution.

It is important to note that many systems assume this problem away by utilizing robotsystems for which collision is a normal and non-threatening activity. Examples include[Mataric97], [Parker96], and [Kube97]. This assumption greatly simplifies many aspects ofsystems design because deadlock conditions involving several robots need not beaddressed directly. Rather, the problem is resolved by “Brownian motion” of the robots,i.e. robots bumping into each other until they free themselves. However, this approachsignificantly limits the scale (in terms of mass and velocity) of robots which can be usedin these paradigms without risking damage. For applications such as construction orhazardous waste cleanup, it may be impractical to build machines which can bothaccomplish the task and survive occasional forceful collisions.

Origins of Cooperation 2.1.4

There are two general sources of cooperation in multi-robot systems. Local cooperationschemes typically involve a subset of all robots and include such behaviors as mutualavoidance and assisted manipulation. Global cooperation (implicit in systems withsome degree of centralization) arises when the group shares information in order toimprove the efficiency of performing the given task. For example, if one robot observesthat a door is closed and broadcasts this knowledge to other agents, they may adjusttheir actions to take this change into account, rather than having to discover thisinformation for themselves. The result is increased system performance.

Background

15

The problem addressed by this thesis focuses primarily on global cooperation. Mapinformation is shared among all agents, allowing each agent to continually compute thecost of paths to goals. These costs are shared, allowing the central planner to continuallyinstruct each robot how to best contribute to the mission as a whole. Other forms ofglobal cooperation are implicit in the mission statement: if manipulation is needed attwo remote locations, the mission statement is specified by the operator to ensure bothlocations are reached by a robot. The cooperation possible in this framework is limitedby the expressiveness of the grammar used to define missions. These approaches areappropriate for the problem because they enable explicitly-defined complex missions tobe executed efficiently by the robot team.

The advantage of this explicitly-designed cooperation over more emergent cooperationfound in some behavior-based systems ([Parker94a], [Mataric92]) is that this type ofcooperation allows optimized mission completion on large-scale tasks. Furthermore,more complex tasks require a somewhat more symbolic view of the system state. TheGOFER system [LePape90] utilizes a more traditional-AI mechanism of cooperation, butis not particularly concerned with optimizing performance for efficient missionexecution.

Learning 2.1.5

Few cooperative mobile-robot systems utilize learning techniques to improve theirperformance. Exceptions include systems by Parker [Parker96] and Mataric [Mataric97].In the context of cooperative robotics, learning can be more generally regarded astechniques by which feedback during execution improves future execution. Using thisbroader perspective, systems which build maps, determine average traversal times invarious locations/terrains, or introspect about their performance can also be consideredlearning systems. For example, the FIRST system [Causse95] uses statistical models ofeach robot’s performance in particular hallways to model expected future performance.

Learning is a valuable aspect of a cooperative robotic system which operates inunstructured environments, in that it allows robots to more accurately estimate theircapabilities and the costs of completing mission components. Learning capabilities aretherefore not essential for a solution to the problem addressed by this thesis, but goodmechanisms for learning and adaptation can only serve to improve system performance.

Since unstructured environments frequently force robots to operate in areas where apriori map information is unavailable, a major part of the system intended for theseenvironments must involve sharing of maps between robots. Each robot’s perceptionsystem should be responsible for interpreting viewed regions and transmitting to otherrobots estimates of the cost of traversal for those regions. Costs are more thoroughlydiscussed in Chapter 3 (What is Cost?, page 45). This map-building behavior is a formof learning, though of more an external, rather than internal, state.

Task Domain 2.1.6

Demonstrated tasks in cooperative robotics loosely fall into 5 categories:

• Box pushing: A number of items in the environment need to be pushed by groups ofrobots to goal locations. Negotiation and “requests for help” play a large part of theinternal structure of these systems. Examples include ALLIANCE [Parker94a],ACTRESS [Ishida94], and systems by Lin [Lin97] and Kube [Kube97].

Background

16

• Foraging: Items scattered randomly around the environment need to be found andpossibly brought to a central location. Examples include systems by Mataric [Mataric97],Arkin [Arkin92], and Brooks [Brooks85]. This domain is particularly amenable tobehavioral approaches, as the bottom behavior in most such systems is “wander.”

• Formation Marching: A group of robots needs to move from one location to another,possibly avoiding obstacles along the way, maintaining a fixed formation (line, column,etc.). Applications for this range from emulation of flocking behaviors in animals[Mataric97] to execution of military maneuvers [Mackenzie97].

• Traffic Control: Rather than attack an entire application, many systems are concernedwith the local avoidance rules which necessarily play a part in many larger tasks suchas dockyard automation ([Azarm96], [Li94]) and hospital delivery [Causse95]. Others viewthe problem independently from a particular domain, including [Arai96] and [Minami96].

• General: Systems which do not address a particular task domain have a language inwhich instructions, commands, or behaviors may be assigned to robots. They are bestcategorized by ability of the language to express real applications. AI-motivatedsystems typically exhibit generality in task domains, such as GOFER[LePape90], andFIRST [Causse95], as well as work by Alami [Alami95] and Ingrand[Ingrand96]. Behavioralsystems are typically weak in this area, as tasks are designed into the robots’ intentionsfrom the ground up. A notable exception is ALLIANCE [Parker94a] which has beenutilized in a large number of the previous domains.

This overview demonstrates that while many particular tasks have been successfullyperformed with cooperative systems, few actually attempt to generalize to a widespectrum of task-applicability. Those that do tend to suffer from lack of concern withefficiency, or are not intended for unstructured environments. The task domainaddressed by GRAMMPS is general, permitting execution of any mission which maybe expressed in its grammar.

Another aspect of task domain is the environment in which the robots act. Almost allsystems discussed in this section work indoors on flat floors. The degree to which theenvironment is controlled is somewhat unclear, but several systems ([Mataric97],[Parker96], [Kube97]) show carefully confined regions with only intentionally-placedobstacles. Others appear to operate in unmodified office environments ([Alami95],[Ishida94]). While some systems that were tested in controlled indoor environments areintended for eventual deployment outdoors in dockyards ([Vidal96], [Li94], [Alami95]) orin the relatively unstructured hospital environment ([Causse95]), none has actually beendeployed or tested in fundamentally unstructured environments. This implies that thisresearch represents perhaps the first demonstrated multi-robot system intended foroutdoor unstructured environments.

Mission Decomposition 2.1.7

Surprisingly, Cao [Cao97] (in his survey paper on cooperative robotics) dismisses theimportance of task decomposition and allocation, stating:

One important mechanism in generating cooperation, namely, taskdecomposition and allocation, is not considered a research axis since (i) veryfew works have centered on task decomposition and allocation (with the notableexceptions of [[Noriels93], [Lueth94], [Parker94a]], (ii) cooperative robotic tasks

Background

17

(foraging, box-pushing) in the literature are simple enough that decompositionand allocation are not required in the solution, and (iii) the use ofdecomposition and allocation depends almost entirely on the group architecture(e.g. whether it is centralized or decentralized).

However, besides the above references, other examples of multi-robot work concernedwith mission decomposition include [Vidal96], [Causse95], and [LePape90]. GRAMMPSdistinguishes itself by handling complex instances of task decomposition and allocationin an ongoing optimized fashion. In this way, GRAMMPS represents an advance in thetype of tasks which can be handled by multi-robot systems. This thesis will also discussthe importance of task allocation and reallocation in terms of performanceimprovements in dynamic environments.

Summary 2.1.8

This section has discussed a wide variety of alternative mobile robot systems,comparing systems based on a taxonomy proposed by Cao [Cao97]. Throughout thisdiscussion, existing systems have been found lacking in three needed capabilities:

• General, complex task descriptions

• Optimized mission planning and execution

• Demonstrated operation in outdoor unstructured environments.

For cooperative mobile robotic systems to exhibit utility for a wide range of targetapplication areas, these capabilities must be developed more completely. The systempresented in this thesis, GRAMMPS, is intended to address these particular issues.

Supporting Technologies & Architecture 2.2

Overview 2.2.1

Most multi-robot systems are designed to solve a particular task and are built from theground up, including purpose-built navigation and perception components. However ageneral cooperative robotic system should operate in tandem with those basic roboticcapabilities, independent from the particular implementation. Rather than insisting ona particular underlying architecture, it is appropriate to make a set of interfaceassumptions, providing the potential to work with a variety of local navigators, pathplanners, and system architectures. This section first discusses architectural issues, thengives examples of other autonomous outdoor navigators and map-making systems,discussing their utility with respect to the problem of coordinating multiple robots innatural terrain. Outdoor, natural-terrain robotic systems are discussed specificallybecause this is the domain in which this work is demonstrated.

System Architecture 2.2.2

Introduction 2.2.2.1

The literature presents a huge variety of architectures proposed for robotic systems (e.g.TCA [Simmons94], NASREM [Albus89], RAPS [Firby89], ATLANTIS [Gat91], andSubsumption [Brooks86]) The architectural requirements for a task-oriented multi-robotsystem for unstructured environments can be summarized into four items: support forreactive behaviors, support for inter-vehicle communication, explicit environment

Background

18

modeling, and a loose coupling of planning to acting. This subsection discusses thereasons for those requirements in the context of the need to support dynamic missionplanning with general task applicability.

An Architecture for Dynamic Planning 2.2.2.2

For robust operation of a mobile robot in an unknown environment, planning must besecondary to the moment-to-moment tasks which maintain the safety of the robot as itmoves through its workspace. Clearly, it is a mistake to instruct the robot to destroyitself by driving off of a cliff just because the goal destination is at the bottom - perhapsa safer path exists! The planner must therefore operate in a supervisory mannerregarding whatever control system is actually moving the robot. The planner cannotassume that its command will be followed, nor it can it assume a static world model. Asnew information becomes available, or as the state/location of the robot changes, theplanner must notice these changes and continue to act accordingly, without requiringunreasonable computational bandwidth3. An example of a system which meets thesecriteria for operating in a dynamic environment is the D*/Smarty System[Stentz94]. Thissystem layers a dynamic replanner with a local obstacle avoidance system to permitgoal acquisition in unknown terrain.

The ability to operate in this supervisory fashion should not be considered an extrafeature to be added to a planning system. Since, at every instant, the robot may not actthe way the planner dictated, the planner cannot incur a significant computationalpenalty to re-adjust its plans. Instead, it must react to these changes as a part of itsintrinsic design, subsuming the planning to the demands of a real world control systemwhich must ensure the safety of the mechanism. This layered architecture andsupervisory role of the central planner has been very successful during operation inunknown and changing environments. While this architecture has not been rigorouslyshown to be necessary, empirical evidence to date indicates that this approach issufficient to permit this type of operation ([Keirsey88], [Langer94b], [Langer93], [Stetntz95b]).

The difficulties with perception for a planning system in a dynamic world cannot beunderestimated. Every perception system can introduce unavoidable noise into thesystem, “surprise” the planner with unexpected terrain, limit the motion of the robot dueto a narrow field of view, and “change its mind” about terrain when viewed from adifferent, frequently closer, position. These problems in perception imply that estimatedcosts of all possible mission plans may change frequently, and furthermore, that therobot may not follow a previously open (and recommended!) path to the goal. Thus, themission planner must be able to function effectively in a world in which its informationis rapidly changing and where its recommendations are frequently being ignored.

The strength of a system which operates dynamically is that a single piece of newinformation can cause modifications to the plan not only for the robot which noticed thechange, but also for all other robots whose actions are coupled to this robot through thehighest-level mission plan. For instance, if one robot realizes it is trapped and cannotreach any of the goals assigned to it, it can notify all other robots of this fact, enabling

3. Replanning whenever new information about the environment arises is as much as 300 times slowerthan efficient dynamic planning[Stetntz95b]. Dynamic planning is memory intensive, but one canalways buy more memory -- time isn’t so cheap!

Background

19

them to redirect their plans to ensure that the mission goals can still be satisfied -- or tonotify the operator that the mission can no longer be completed. Since each item ofperceptual data can cause replanning all the way up to the mission level, it is essentialthat an efficient mechanism for replanning be designed into any system which attemptsthese tasks.

Finally, in order to support optimal behavior, it is necessary that the system be able tomodel the terrain explicitly and pass this information among participants in the mission.Purely reactive architectures (Subsumption [Brooks86], Aura [Arkin97]) do not permit thistype of operation, eschewing all symbolic planning tasks in favor of emergentintelligence. By utilizing an appropriate amount of symbolic reasoning and modeling,it is possible to couple the robustness of reactive systems with the increasedperformance of reasoning systems.

Maintaining General Applicability 2.2.2.3

For a wide range of application domains (e.g. post office automation, construction,planetary exploration, hazardous waste site remediation, military reconnaissance) thereexists a need for efficient multi-robot systems capable of handling complex missions.However, in each of these domains, the demands on the mobility aspects of the systemcan be quite different. Unlike most multi-robot systems discussed earlier in this chapter,GRAMMPS is designed to work with the underlying navigator, provided certainconstraints are met. This aspect of robot system design is not essentially part of multi-robot systems, but applies to any intelligent planning component intended to work in areal environment. To ensure general applicability, the navigator should be responsiblefor dynamic interactions with and measurements of the environment. For this reason,the planning component of GRAMMPS has the following rough structure:

GRAMMPS represents the first demonstrated general multi-robot system intended tocombine optimal mission planning with a mostly-reactive navigation layer. Other

Figure 2-1: Simplified GRAMMPS System Architecture

Mission Planner

pathplanner

localnavigator

pathplanner

localnavigator

pathplanner

localnavigator

goalassignments

steeringadvice

pathcosts

terraincosts

robot 1 robot 2 robot n

Background

20

systems (e.g. PRS [Chatila95], D*/Smarty [Stetntz95b], Intelligent Reactive Systems[Kaelbling87]) also utilize this reason-over-reactivity hierarchy, but fail to permitoptimization of general missions or operate with a general class of navigators. As longas the I/O demands outlined in Figure 2-1 can be satisfied, GRAMMPS should be ableto be easily ported to different applications. Furthermore, GRAMMPS should fit instraightforwardly with general-purpose architectures, such as TCA [Simmons94] or PRS[Chatila95], acting as an optimal mission planning & execution module.

Summary 2.2.2.4

This subsection has outlined the general intentions of the architecture appropriate forthe problem addressed by this thesis, and has also very roughly described thearchitecture of GRAMMPS. This work does not represent a fundamentally newarchitecture. Rather, it recognizes that robot architectures exist to ease the design andimplementation of robotic systems which meet the demands of their application areas.

The next two subsections detail available local navigation systems and map-buildingsystems, both essential supporting technologies for autonomous robots operating innatural terrains.

Outdoor Autonomous Mobile Robot Systems 2.2.3

These systems, as a group, support the notion that the technology currently exists forrobots to maintain their own safety while moving. These systems will be compared onthe basis of the supported vehicle speed, the length of demonstrated traverses, the typeof environment in which they operate, and their method of goal specification. The factthat these systems demonstrate the ability for robots to move in outdoor terrain withoutendangering themselves indicates that it should now be possible to expect a higher levelof mission performance from such systems, as demanded by applications ripe forautomation.

Stanford Cart [Moravec83] 2.2.3.1

Moravec’s work with the Stanford cart was the first to use an outdoor robot. The cartused a camera for obstacle detection, operated in a parking lot with scattered sparseobstacles, and took several hours to traverse the lot.

FMC [Parodi87] 2.2.3.2

The FMC Mobile robot program used a tread-driver all-terrain vehicle to perform a 2km autonomous traverse avoiding local obstacles. Off-line route planning wascombined with local obstacle avoidance performed whilst travelling along the route.4 Acamera and ultrasonic sensors provided obstacle detection. A single location wasspecified as the goal.

JPL Robby [Wilcox87] 2.2.3.3

This JPL rover drove at 4 cm/s on outdoor terrain using stereo data to avoid obstacles.

4. Most systems follow the “local-avoidance” strategy to follow a pre-planned path with unknownobstacles. These systems will experience difficulty reaching a goal when the sparse-obstacle environ-ment assumption is violated.

Background

21

CMU FastNav [Feng90][Singh91] 2.2.3.4

FastNav was focussed on tracking a pre-planned route and stopping when deviationsfrom flat terrain were detected in front of the vehicle. A single scan-line laser rangefinder was used for obstacle detection. FastNav achieved speeds of up to 30 km/hr withpath tracking, but only 10 km/hr with obstacle detection. Goal specification and routeplanning were not integral parts of this system.

Hughes ALV [Daily88][Keirsey88][Olin91][Payton90] 2.2.3.5

The Hughes ALV system used a route planner to determine a global path to the goallocation. This path took into account the nature of the terrain, and other factors such asvisibility for radio communications. A more “reactive”5 system was used to selectbetween steering options, and the route was followed by aiming towards particular sub-goal points along the route. Obstacles were detected using a 2-D laser range finder. Thesystem achieved runs at 3.5 km/hr over distances exceeding 500m.

CMU Full Geometry Navigator (FGN) [Brumitt92][Stentz92] 2.2.3.6

This autonomous cross-country navigation system used a planner which was intendedto be superior to the Hughes system in cluttered environments. It achieved a 5 km runat 5 km/hr following a circle on largely flat terrain using a 2-D laser range finder forlocal obstacle avoidance. The system was limited by poor fidelity of terrain maps, poorvehicle control, and planning time overruns. No goal definition beyond path trackingwas ever attempted.

CMU RANGER [Kelly94] 2.2.3.7

RANGER was designed to address the deficiencies in the FGN system above. It uses amore reactive approach, similar to the Hughes work but operating at a faster cycle timeand with a more validated control-based approach. This system has demonstrated anunprecedented level of reliability and speed on more complex terrain. It is provablylimited primarily by the resolution and range of the laser range finder used to detectobstacles.

CMU SMARTY/Ganesha [Langer94b][Langer93] 2.2.3.8

Several other systems using a reactive approach have been built for outdoor navigationat CMU. These systems follow a prescribed path with local obstacle avoidance. Themap manager detects obstacles early on, and does not use a Cartesian elevationrepresentation at any time. A local planner votes on the quality of arcs in front of thevehicle, a path-following module votes likewise based on which arcs will take thevehicle along the global path, and an arbitrator determines which direction is actuallydriven. 1 km runs at 10 km/hr have been achieved. By replacing the “path-following”voting module with the D* Dynamic Planner [Stentz94], this architecture has been usedto seek goals in unknown terrain without a pre-planned route [Stetntz95b].

LAAS-CNRS Systems [Lacroix95][Nashashiba94][Schalit92] 2.2.3.9

This outdoor system uses a laser range-finder to acquire terrain, a 2-D Cartesianelevation map representation, a heuristic terrain classification scheme, and multiple

5. “Reactive” is used here to describe local motion planners which can determine an appropriate courseof action (steering direction) quickly, without having to stop vehicle motion or rely on a path trackerto follow paths planned at longer intervals.

Background

22

planners depending on the complexity of the perceived terrain. It is limited to speeds of3 km/hr, and is also limited by 2-3 minute planning cycle times. The system’s authorsargue for an adaptive approach to planning, using faster planners when possible.However, the RANGER system in particular demonstrates that a reactive approach maybe sufficient, even for difficult terrain. Goals are specified by sighting visible landmarkswith a camera. (The landmarks are assumed to be visible.)

ESPRIT II PANORAMA [Vacherand94] 2.2.3.10

This outdoor system uses a local reactive planner operating on a Certainty Grid [Elfes90]

map representation. It has achieved speeds of 1 km/hr on outdoor terrain.

On-Road Systems [Pomerleau92] 2.2.3.11

Work by Pomerleau on neural-network-guided road following promises to eventuallybe combined with intersection detectors to permit long-distance driving on realhighways. GRAMMPS could be used with this system as a route planner, utilizingcommercially-available road maps. Many other on-road systems exist; this system isperhaps the best example of road followers.

Map Building Systems 2.2.4

For a group of robots to operate in a unstructured environment, it is helpful for them toshare a map representation. In this way, information collected about different portionsof the environment may be shared between the robots, improving their overallknowledge, and therefore their overall efficiency of operation. As any robot movingautonomously in this environment must have some mechanism for perceiving theterrain and estimating the safety of movement between regions, it is appropriate for amulti-robot coordination system to assume that both a local obstacle avoidance moduleand a map-building module will be available for any robot which is to be controlled. Tomaintain generality, it is preferable not to overly restrict the type of map which is used.Rather, to ensure efficient operation, it is useful to insist that there be a numericalestimate of the cost for travelling from one state in the map to another. To allow goalacquisition, it is also necessary to require that the local obstacle avoidance module becapable of attempting to drive toward a nearby state. If a planner can learn about theenvironment and direct action, then it has the necessary capabilities to allow goal-drivenbehavior.

Many different map representations have been used for both local planning (obstacleavoidance) and global planning (route selection). Most successful implementations areamenable to use within GRAMMPS, whether grid-based or graph-based.

Grid-Based Map Representations 2.2.4.1

Planetary exploration systems (Ambler [Kweon90], JPL Robots [Thompson77]) and otheroutdoor systems (CMU UGV [Brumitt92][Gowdy90][Hebert88][Kelly92], Hughes ALV[Mara92] [Olin91], LAAS-CRNS Systems [Chatila92] [Chatila95] [Lacroix95] [Nashashiba94]

[Schalit92]) have primarily used 2-1/2D cartesian-grid elevation maps for terrainrepresentation. Various metrics have been developed to determine the cost of traversingsuch terrain. Work at CMU and Hughes has used a suspension model and simulatedkinematic traverses of the terrain to determine safe paths. Lacroix [Lacroix95] has usedterrain classification to provide a rough determination of cost, and then applied different

Background

23

planners to different classes of terrain, preferring flat to uneven terrain. In most cases,a metric based on the variance of elevation or the average slope [Langer94b] of terrainserves as a viable cost metric. Evidence (or “occupancy”) grids are also usable maprepresentations [Elfes90]. Cost can be computed using a variety of metrics based on theprobability that each location in a 2-D grid is occupied.

Graph-Based Map Representations 2.2.4.2

GRAMMPS is not limited to grid-based representations. Distance is a viable metric,and use of this metric optimizes travel to the degree that the distance estimates betweenlocations are accurate. Brooks [Brooks85] argues for the use of a graph to representlocations, based on the assumption that world observation and robot control are bothuncertain. By adding a cost estimate to transitions (based, perhaps, on a statisticalaverage of previous traversal costs), this system is directly usable. Leonard, Durrant-Whyte, and Cox [Leonard90] demonstrate an autonomous cartographer which usesKalman-filtering techniques and feature tracking to produce 2-D maps. These maps aredirectly usable by GRAMMPS.

Basye [Basye89] and Kuipers [Kuipers88] also use graphs to represent the environment.Both demonstrate that maps can be learned by the robot even when sensor errors andsignificant control uncertainty is present. These maps are represented as graphs of“distinct locations.” A GRAMMPS system could specify goals as states in the graph,and could optimize the travel within this map according to estimates of the distancesbetween locations. Work by Rugg-Gunn [RuggGunn94] uses a graph representation forits map, and can plan for multiple moving robots. However, a pre-specified graph isnecessary, and only one robot can traverse a link in a given direction at a time.

Other planning systems 2.3

In robotics literature, the term “planning” has two distinct meanings. First, from the AIperspective, planning refers to the autonomous generation of a plan, which consists ofa sequence of actions that change the state of the world to a specified goal state. Second,from a mobility perspective, planning refers to robot motion planning; that is, finding apath which the robot may follow which ensures that it reaches the goal state withoutcolliding with obstacles in its environment.

AI planning systems began with STRIPS [Fikes71], and have since been improved andapplied to a variety of domains from simple robot control [Nilsson69] to naval logistics[Tate85] to job shop scheduling [Fox84] to recipe generation [Hammond86]. These plannerstypically attempt to be domain independent, and frequently focus on increasinglycomplex methods for searching for the appropriate sequence of operators (actions bywhich the robot may affect the world). Planning is viewed as a heuristic search, withmore advanced planners having greater ability to modify, adjust, and learn from partialplans while building up a global plan. Few of these systems have demonstrated thecapability to plan tasks for multiple autonomous agents, nor have they effectivelydemonstrated functionality in a dynamic world. Planning as it is typically defined is anNP problem [Chapman87] and thus, any attempt to solve it must use a set of heuristicsappropriate to the problem at hand, in order to reduce the complexity of the search task

Background

24

to something which is computationally feasible for most instances of plans in the givendomain.

Motion planning systems have ranged from simple local control schemes to avoidnearby obstacles to omniscient systems which reason about the entirety of the robotworkspace. This thesis is concerned with tasks that range over the robot workspace, andas such, local planning systems6 do not solve the essential problems. An excellentsummary of systems in the latter category can be found in Latombe, Robot MotionPlanning [Latombe91]. The basic motion-planning problem considers moving a singlerobot from a start location to a goal location amidst a bounded workspace of polygonalobstacles. This problem can be complicated by considering an unknown world, achanging world, multiple robots, non-point robots, nonholonomic robots, non-polygonal obstacles, uncertainty in motion, and so forth. For most real robotics tasks,the robot is nonholonomic, motion control introduces uncertainty, perceptioninformation is unreliable, the state of the world is not known (and may be changing),and, ideally, it would be beneficial to permit the use of multiple robots in the sameworkspace. Even the basic motion-planning problem is PSPACE-hard [Latombe91]; mostsolutions rely on appropriate heuristics to retain feasibility. In addition, these plannersare almost exclusively concerned with achieving a single goal state, with little concernfor sequencing multiple goals together.

Thus, AI-planners are good at sequencing actions, while motion-planners are good atkeeping the robot safe while achieving a single goal. It is necessary to connect these twoworlds so that more complex tasks can be completed. Task completion should minimizenot just the cost to a single goal or a sequence of goals, but rather the cost of entire taskswhich may involve multiple goals and multiple robots.

Recently, planning as an ongoing process during plan execution has become a moreclosely studied topic. Any system or algorithm which supports search interleaved withexecution may be considered a type of on-line searching.

The following two sections discuss examples of AI- and motion-planning systems,describing their strengths and weaknesses with regard to the problem addressed by thisthesis. The final section similarly addresses several on-line search paradigms.

Domain-Independent AI-Planners 2.3.1

An excellent broad collection of papers on AI planning can be found in Readings inPlanning [Allen90]. The first two papers in this book provide a brief summary of thehistory of planning ([Georgeff87a], [Tate85]). The planners discussed below are not meantto be a complete “spanning set” of planners; rather, they are presented to demonstratethe deficiencies typical of AI planning systems with respect to multiple-goal multiple-robot dynamic-environment mission planning problems.

STRIPS - Pure AI Planner 2.3.1.1

STRIPS [Fikes71][Nilsson69] is the first and perhaps best-known AI planner. The worldstate is described as a set of statements in first-order predicate calculus. The operationsthe robot can perform on the world are defined by preconditions, an ADD list, and a

6. Local navigation systems are perhaps more accurately considered “controllers,” rather than “plan-ners.” This work assumes that such a controller already exists for all robots to be addressed.

Background

25

DELETE list. Planning is a process of determining a sequence of operations which maybe applied such that a goal state is reached. The robot then performs these actions toachieve the goal. The drawbacks of such systems are well known; they suffer from theFrame Problem, expensive replanning, and a failure to address real-world difficultiesdue to their abstraction from the physical world. The costs of alternative actions are notdifferentiated, and optimality is not a concern. Finally, there is a fundamental paradigmmismatch between STRIPS-type planners and mobile tasks involving groups of robots;the latter is concerned with the optimization of mobile missions, while the formerattacks logic problems. While a mobile mission planner is likely to be unable todetermine a proper sequence of actions to stack blocks on top of each other, it isexpected that problems of this sort will be solved in advance by the operator beforepassing a mission (or action) specification to the cooperative robot planner.

Utility (Cost) Planner 2.3.1.2

Feldman and Sproull [Feldman77] added the notion of costs to planning sequences ofactions, frequently as a “utility” of performing certain actions. Planning is thenperformed with the intent to maximize utility of the robot’s actions. Actions which mayresult in failure due to incomplete knowledge are assigned a lower utility based on anestimate of the probability of failure. Plans are generated with tests to increase theknowledge of the world, which reduces the probability of failure, which subsequentlyincreases the utility of the plan. Despite the inclusion of cost in the planning process,this type of AI-planner still fails to perform adequately in a dynamic environment, andstill suffers from the paradigm mismatch described above.

Dynamic and Reactive Planners 2.3.1.3

A notable deficiency of the above planners is their inability to work in dynamicenvironments. Work in planning for mobile autonomous systems has progressedbeyond the first-order predicate calculus paradigm, and several “planning”architectures exist which are designed to be used on mobile robots. At one extreme,Brooks [Brooks85] suggests abandoning planning in favor of purely reactive systemswhich by their nature work well in dynamic environments. However, the use of “stateinformation”, such as terrain maps, is not permitted in the subsumption architecture.This makes it difficult to optimize the performance of these systems. Thus, while theyexhibit excellent performance on a limited set of tasks, it is unclear how to engineerthem for more ambitious missions. Kaelbling [Kaelbling87] suggests a hybridarchitecture to control a mobile robot, with reactive behaviors forming the bottom layer,and more competent and involved reasoning (planning) modules overriding thesebehaviors where appropriate. It is this sort of architecture which is used in GRAMMPSwith one particular exception: the higher level planner does not override the low-levelbehavior. Instead, it influences it towards mission-oriented goals. The low-levelbehavior is most capable of keeping the robot safe, so the higher-level planner shouldonly make suggestions, not issue commands, to the low-level behavior.

Georgeff [Georgeff87b] proposes PRS (Procedural Reasoning System) as a system for“reasoning about and performing complex tasks in dynamic environments [for] anautonomous mobile robot.” (Also see [Chatila95]). PRS recognizes the importance ofnever committing too fully to a plan or expecting that the robot will follow the directionof the planner. PRS also introduces the notion of metalevel (or reflective) capabilities

Background

26

that are used to decide when it is appropriate to change the current plan. PRS does not,however, abstract itself from the environment in as complete a manner as might bedesirable for a general system. PRS integrally depends on a set of particular behaviorsand sensor actions. Any new robot would need precisely those same abilities to be usedwith PRS. GRAMMPS is general; any local-motion planner/obstacle-detection systemwhich can provide cost estimates for terrain, maintain its position in a graph oflocations, and attempt to follow directions from a mission planner can be used. PRSdoes add the extra capabilities of looping, conditional, and recursion constructs.However, given certain conditions (such as loop exit conditions) the process ofoptimizing such a plan is undecidable -- equivalent to the halting problem! On the otherhand, it is appropriate to have a planning system which can optimize as large a portionof the problem as is computationally feasible.

Multi-Agent Planners 2.3.1.4

None of the above systems are designed to work with multiple robots. Pednault [Pednault

87] demonstrates that some multi-agent dynamic-world problems may be reformulatedas single-agent static-world problems, thereby permitting them to be solved by classicalplanning techniques. However, this system suffers from same paradigm mismatch asthe STRIPS planner discussed above.

Motion Planners 2.3.2

An excellent summary of motion planning systems can be found in Latombe, RobotMotion Planning [Latombe91]. “One-Shot” planners are not applicable to GRAMMPSbecause of the dynamic environment in which real robots operate. Efficient replanningis essential to ensure adequate performance in real-world applications.

Multiple Robot Planners 2.3.2.0.1

Few planning systems which are capable of addressing problems involving multiplerobots optimize the motion when multiple goals are available. These systems aretypically only capable of directing a set of robots from a single start state to a singlegoal state. Pages 356-402 in [Latombe91] address environments where there are multiplemoving objects. These planners are concerned with scenarios where robots arefrequently in close proximity to each other, and where mutual avoidance is ofparamount concern. GRAMMPS is designed primarily to work in less clutteredenvironments, which are typical of field scenarios.

Parsons and Canny [Parsons90] provide a complete solution to the problem ofcoordinating the motion of several independent mobile robots (modeled as convexpolygons) moving in a bounded planar workspace which contains polygonal obstacles.For several robots, the exponential running time of the algorithm, its lack ofoptimization for use in dynamic environments, and its failure to address multiple goalsmakes it unsuitable for use within GRAMMPS. Erdmann and Lozano-Perez [Erdmann87]

present a complete planner for multiple moving robots modeled as polygons. Thiswork, like the above work, is not designed for use in dynamic environments or formissions with multiple goals. Work by Warren [Warren90], using potential fields to planfor multiple robots, is able to find solutions rapidly but also fails to address the multiplegoal scenario. In addition, since planning for each robot is done in a prioritized manner,optimality is not guaranteed. Buckley [Buckley89] investigates reordering the robot

Background

27

planning priorities, which improves the computational performance of both the abovealgorithms. However, the other deficiencies of those algorithms are not addressed.

As discussed earlier in this chapter, most cooperative robotic systems do not utilizecentral planning frameworks to resolve motion conflicts.

Dynamic Planners 2.3.2.1

Dynamic planners address the problem of efficiently replanning paths when newknowledge of the environment is obtained. D* [Stentz94][Stentz95a] is a general-purposedynamic replanner which generates optimal paths through the planning space. Itsreplanning operation is especially efficient if changes in the map occur primarily aroundthe robot’s location. A survey of other dynamic replanners and a detailed discussion oftheir deficiencies can be found in the introduction of [Stentz94], and it is not repeatedhere.

On-Line Search 2.3.3

On-line search is motivated by the need to plan and act in the face of uncertainty. Thisuncertainty can be due to a lack of domain knowledge, multiple agents affecting changein the world, an excessively large search space, or an inability to act in a deterministicfashion. In any of these cases, it is necessary to act before it is known that a given actionis optimal or even correct with respect to the task at hand. Approaches to on-line searchhave ranged from the theoretical[Korf90] to the eminently practical[Singh97]. TheProceedings of a AAAI workshop on On-line Search[Koenig97] provide exampleapproaches to on-line search problems from a wide range of perspectives.

Many varieties of heuristic search have been employed to solve large searchingproblems in real-time scenarios. All involve the need to make decisions in a real-timeenvironment. The problem of determining optimal plans for multiple robots in dynamicenvironments clearly falls into this domain. Unfortunately, no single perspective in thisarea of research has adequately addressed this question. This section discusses threebroad lines of inquiry applicable to this problem.

Local Search 2.3.3.1

One approach to this problem is to generate a heuristic search algorithm which allowsboth rapid commitment to a local course of action as well as proven global convergenceto a solution. Two classes of algorithms which behave in this fashion are theRTA*[Korf90] and GenSAT[Selman92] algorithms. RTA* (Real Time A*) provides a localdecision making process by examining and updating costs and cost-estimates totransition to nearby nodes in the graph, then moving in the locally-best direction. Byrepeating the process at each node, convergence to the goal is ensured. The class ofGenSAT algorithms is concerned with solving the Propositional Satisfiability problemin a local hill-climbing manner. RTA* fails to provide global optimality in a typicalnavigational scenario with regularly provided sensor information to update state-to-state cost estimates. The GenSAT algorithm does not easily map onto large path-planning problems, prohibiting its use for this component of the problem. Additionally,finding a satisficing solution is frequently less important than finding an optimal (ornear-optimal) solution for problems in the domain addressed by this thesis.

Background

28

Efficient On-line Search 2.3.3.2

An alternative to the locally optimal approaches detailed above is to search for aglobally optimal solution while ensuring that updates to this solution can happenquickly when a problem arises with the intended plan. This is most similar to the classof planners called “Dynamic Planners” referred to above[Stentz94]. An alternativeapproach to providing rapid mission-oriented response to changing problems isproposed by Nourbakhsh[Nourbakhsh97]. By providing a formal abstraction frameworkin which problems can be cast, the computation needed to maintain efficient action canbe minimized. The approach taken by this thesis falls into this general domain.

Planning Planning 2.3.3.3

A meta-approach to these problems have also been explored. In such works, theobjective is to actively evaluate the appropriate amount of computation needed for eachstep. Generally, such approaches require an analysis of the likely reward as a functionof computational time, something which can be challenging to design or generate ingeneral. Example of work in this area includes: [Good71], [Goodwin94] and [Dean88].

Summary 2.4

• A wide variety of alternative mobile robot systems were evaluated with respect toapplicability to the problem statement in Chapter 1 (Problem Statement, page 5), inaccordance with a taxonomy proposed by Cao [Cao97]. This discussion demonstratedthat existing systems have failed to address this problem due to lack of support forgeneral complex tasks, optimized mission planning, and/or operation in outdoorunstructured environments.

• The general system architecture recommended for this class of problems is one that hasbeen tested and utilized on a variety of single and multiple mobile robot systems. Thisarchitecture is different from that used by most other multi-robot systems in that itsupports the utilization of a general class of navigation, dynamic planning, and map-making components.

• While existing AI- and path-planners are capable of reasoning about either costs ormotion separately, they fail to address the needs of dynamic planning for multiplerobots and multiple concurrent goals. To address the problem at hand, it is important toreason about efficient motion in largely mobile missions.

29

Chapter 3

Mission Planner: Design & Implementation

This section details the essential central planning components of GRAMMPS. Beforedelving into the internals of GRAMMPS, an overview of the entire mission planner willbe given. The central planner takes as input a mission statement describing the task tobe completed by the robot team. The discussion will follow the path taken by themission as it flows through the processing and decision-making modules. The pathbegins with an understanding of the syntax and semantics of the grammar in whichmission statements are made, proceeds to the compiler which interprets and transformsthe mission statement, and concludes with the actual planning and replanningcomponents and subcomponents.

Conceptual Overview 3.1

In Figure 2-1 (page 19), a rough diagram of the GRAMMPS demonstration system wasgiven. This chapter is solely concerned with the internals of the “Mission Planner” boxin that figure. Abstracting the mission planner away from the details of the pathplanners, map sharing modules, and local navigators, allows GRAMMPS to begenerally applicable to a wide range of mobile robot designs and implementations. Thisgenerality is extended by a mission grammar which describes the class of directlyexecutable and optimizable missions.

Figure 3-1 shows the insides of the “Mission Planner” box. The bold arrows in thisfigure indicate the primary flow through the system. At the top, the operator provides adescription of the mission (i.e. a mission statement) which is to be performed. Thecompiler turns the statement into a form which is more naturally usable by the centralplanner. The planner generates the initial plan and plan-structure; plans are comparedusing path costs from the cost manager. The replanner uses the plan-structure to replanas costs change. When a robot reaches a goal (the cost to a currently-required goalbecomes zero), the replanner passes the plan and the completed goal to the pruner,

Mission Planner: Design & Implementation

30

which removes the goal from the mission. This reduced mission statement goes backinto the planner, and the process repeats. When the mission statement is empty, thesystem halts execution. Both planners utilize the services of sub-planners, shown aboveas “TSP” (Travelling Salesman Problem) and “MTSP” (Multiple Travelling SalesmanProblem).

Mission Grammar 3.2

Motivation 3.2.1

Many single- and multiple-robot systems have used languages or grammars to expresspossible missions ([LePape90], [RuggGunn94], [Coste-Maniere95], [Thomas95]). Thealternative to using a general language is to design a system which is only capable ofone particular task, requiring some degree of reprogramming or reorganization fordifferent tasks. Many applications cannot tolerate such requirements; there must be away to describe a wide space of missions without requiring redesign, recompilation, orany fundamental reworking.

A large class of planners [Latombe91] exist which can direct one robot from a startlocation to a goal. These have been extended to the multiple robot case ([Parsons90],

Figure 3-1: Central Planner Component Breakdown

grammarcompiler

planner

replanner

prunercost

manager TSP MTSP

Operator

Path Planners, Local Navigators

help!

pathcostqueryand

reply Robot-GoalAssignment

MissionStatement

GR

AM

MP

S C

entr

al P

lann

er

Mission Planner: Design & Implementation

31

[Erdmann87]) by giving each robot a start location and its own goal designation.However, these are not capable of reasoning about ongoing missions in which morecomplex decisions about goal selection must be made. Instead, they focus on theavoidance of inter-robot collisions, which may be reasonably ignored as a minor part ofmission planning and optimization as addressed in this thesis.

GRAMMPS is designed to reason primarily about mobile missions: moving robotsbetween locations and making decisions based on operator-specified constraints inorder to minimize the cost of the mission. The type of optimizing decisions the missionplanner should make are:

• Should Robot 1 go to Goal A or Goal B?

• Should Robot 1 or Robot 2 go to Goal A?

• Should Robot 1 go to Goal A then Goal B, or the other way around?

This structure allows GRAMMPS to reason about the essentially mobile parts of themission. Rather than expressing what is to be done at each goal, it allows the operator(or higher-level planning system) to specify the constraints on the mobile componentof the mission, i.e. which robot can/should do each task, in what order to do tasks, andwhich tasks are viable alternatives for each other. This assumes that, once a goal isreached, other software or control modules will control the robot to perform a neededtask1. For tests and demonstrations of this system, there was no task specified at eachgoal, as this does not affect the reasoning done by the planner. The use of mobile robotsimplies a mobile mission: the grammar of GRAMMPS is designed to address this need.

Grammar Definition 3.2.2

Syntax 3.2.2.1

The grammar used to specify missions in GRAMMPS is given by the followingproductions2:

Semantics 1 3.2.2.2

The symbols in this grammar can be loosely interpreted as follows:

1. For example, image acquisition in a military reconnaissance scenario, or soil sampling in a hazardouswaste scenario.2. Given the difficulty of interpreting grammar definitions, for clarity all grammar production rules omitthat any term may be parenthesized, e.g. is used instead of

Eqn. [3-1]

Table 3-1: Intuitive Grammar Interpretation

Expression Meaning

A AND B

A OR B

MG1: m M r g,( ) m m∧ m m∨ m m⇒→r Ri r r∧ r r∨→g G j g g∧ g g∨ g g⇒→

r Ri r r∧ r r∨→ r Ri r r∧ r r r( )∨→

A B∧A B∨

Mission Planner: Design & Implementation

32

A robot in this grammar refers to an actual robot, and a goal refers to a particularlocation within the robots’ workspace. Before giving a more rigorous interpretation ofthis it is helpful to consider several example expressions in this grammar.

Example 1 3.2.2.2.1

This expression is the find-path problem in motion planning: One robot is to reach aparticular goal as efficiently as possible.

Example 2 3.2.2.2.2

This expression is the find-path problem in motion planning for multiple mobile robots:each robot is to reach its own independent goal as efficiently as possible.

Example 3 3.2.2.2.3

This states that either Robot 1 or Robot 2 should move to Goal 1, then Robot 2 is to visitGoal 2 and Goal 3 in that order. This could correspond to the data gathering scenariowhere either robot must visit one location (Goal 1), and then Robot 2 (which is perhapsequipped with a sensor that Robot 1 lacks) should go to Goals 2 and 3.

Example 4 3.2.2.2.4

The problem consists of N robots initially at different locations, M goals which must bereached by any robot in any order3, and 1 base to which all robots must return once theirportion of the mission is completed.

3. While this will be discussed in detail later, it is helpful to note nowthat: , as the latter would imply the robots cannotsplit up the goals, which is not the intention of the former statement.

A THEN B(alternatively, A SEQUENCE B)

Robot i

Goal j

MOVE robot r TO goal g(alternatively: MISSION involving r and g)

Eqn. [3-2]

Eqn. [3-3]

Eqn. [3-4]

Eqn. [3-5]

Table 3-1: Intuitive Grammar Interpretation

Expression Meaning

B⇒

Ri

G j

M r g,( )

M R1 G1,( )

M R1 G1,( ) M R2 G2,( ) … M Rn Gn,( )∧ ∧ ∧

M R1 R2∨ G1,( ) M R2 G2 G3⇒,( )⇒

M R1 … RN∨ ∨ G1 … GM∧ ∧,( ) M R1 … RN∧ ∧ Gbase,( )⇒

M R1 R2∨ G1 G2∧,( ) M R1 G1 G2∧,( ) M R2 G1 G2∧,( )∨≠

Mission Planner: Design & Implementation

33

Semantics 2 3.2.2.3

While the basic semantics of this grammar are given above (and, or), the exactinterpretation of the and operators is not obvious. This section willclarify the semantics of expressions using these constructions.

1. : All robots used within should complete their (current) share of themission before proceeding on their assignments within . Note that this impliesthat components of could happen before all components of have completed.

2. : This is equivalent to the Travelling Salesman Problem(TSP), except that the robot does not start at one of the “cities” on the tour. Theplanner here should select the optimal tour for the robot. In general, an AND of goalsmeans all goals need to be reached by any of the robots .

3. : This is a simple selection; whichever robot can reach Goal 1most cheaply will be instructed to do so. In general, an OR of robots means that anyrobot may contribute by visiting some or all the specified goals.

4. : This is N instances of the TSP, where each robotmust visit all the M goals, but in any order. For instance, one robot might visit Goal1, Goal 2 then Goal 3, while another might visit Goal 3, Goal 1, then Goal 2. Ingeneral, an AND of robots means all robots should perform the entire set of goalsassigned to them.

5. : This is a slightly more complex selection. Anyrobot must visit some goal. As discussed in simpler examples above, some goal mustbe reached, any robot may perform the task. In general, an OR of goals implies thatat least one of them must be reached.

6. : This is equivalent to the MTSP (MultipleTravelling Salesmen Problem), in the same way examples 2 and 4 above wereequivalent to the TSP. Consistent with the above, all goals must be reached, and allrobots are permitted to contribute to this task.

Axioms 3.2.3

While the semantics of the above examples should be clear, what is less clear at thispoint is how to optimize complex missions constructed arbitrarily in this grammar. Anexpression with 50 sub-expressions could be very complicated to interpret andoptimize. The solution to this problem lies in the recognition that there are equivalentways to say the same thing in this grammar. For example, based on the semantics above,it is clear that is equivalent to . The validtransformation rules for this grammar are referred to as axioms. Like any axioms in alogical structure, they are assertions and are made without proof.

It is helpful to think of expressions in this grammar as a sequence of assertions whichbecome true during execution. A goal in an expression becomes true when a (valid)robot reaches that goal. An M() becomes true when all goals contained within it arereached. An expression involving multiple M() operators becomes true when theequivalent statement in first-order logic becomes true.

Note that while this grammar (and the following axioms) clearly resemble first-orderlogic, there is not a one-to-one correspondence between the two. The lack of a NOT

M r g,( ) B⇒

M1 M2⇒ M1

M2

M2 M1

M R1 G1 … GM∧ ∧,( )

M R1 … RN∨ ∨ G1,( )

M R1 … RN∧ ∧ G1 … GM∧ ∧,( )

M R1 … RN∨ ∨ G1 … GM∨ ∨,( )

M R1 … RN∨ ∨ G1 … GM∧ ∧,( )

M R1 R2∧ G1,( ) M R1 G1,( ) M R1 G2,( )∧

Mission Planner: Design & Implementation

34

operator is perhaps the most obvious omission. Furthermore, the logical interpretationof “A implies B” is not exactly the same as the meaning of , despite thelexicographical similarity. Viewing the execution of the mission as a series of logicalassertions of truth can lead to confusion. In logic, an implication is true whenever either1) A is false or 2) A is true and B is true; for GRAMMPS a mission is only complete(or “true”) when both A and B are true. The SEQUENCE operator in GRAMMPS( ) is thus a loose ordering constraint on the completion of goals contained withinits operands.

All this notwithstanding, the following axioms are surprisingly similar to the usualAssociative, Commutative and Distributive laws. Note that lowercase terms (e.g. ) inthese axioms refers to a substatement in the grammar which follows the productionrules in Eqn. [3-1], while the uppercase symbols (e.g. ) refer to particular robots, goalsor missions.

Commutative Axioms 3.2.3.1

For :

Eqn. [3-6]

Eqn. [3-7]

M1 M2⇒

⇒

a

Ri

a b c, , R1 R2 … RI, , ,{ }∈( ) a b c, , G1 G2 … GJ, , ,{ }∈( ) a b c, , M1 M2 … MK, , ,{ }∈( )∨ ∨

a b∧ b a∧=

a b∨ b a∨=

Mission Planner: Design & Implementation

35

Identity Axioms 3.2.3.2

Associative Axioms 3.2.3.3

Distributive Axiom for Missions 3.2.3.4

Mission Expansion Axioms 3.2.3.5

Discussion 3.2.3.6

The first seven axioms (Eqn. [3-6] - Eqn. [3-12]) are the most straightforward, expressingthe natural associative and commutative laws plus the natural identity relationships. Eqn.

[3-13] is an intuitive application of the distributive law to MOVE operators in anexpression. The Mission Expansion Axioms (Eqn. [3-14]-Eqn. [3-18]) define therelationship between the AND and OR operators applied to robots and goals, and thesame operators applied to MOVEs. The first three of these axioms (Eqn. [3-14]-Eqn. [3-

16]) are also clear, expressing that an AND of robots or goals within a mission isequivalent to an AND of missions containing the component robots or goals.

One might expect that OR could replace AND in Eqn. [3-14] above, making this (invalid)axiom: Unfortunately, this is not the case.Consider the example where and in Eqn. [3-14]. This gives

Eqn. [3-8]

Eqn. [3-9]

Eqn. [3-10]

Eqn. [3-11]

Eqn. [3-12]

Eqn. [3-13]

Eqn. [3-14]

Eqn. [3-15]

Eqn. [3-16]

Eqn. [3-17]

Eqn. [3-18]

a a∧ a=

a a∨ a=

a a⇒ a=

a b∧( ) c∧ a b c∧( )∧=

a b∨( ) c∨ a b c∨( )∨=

m1 m2 … mn∨ ∨( )∧ m1 m2∧( ) … m1 mn∧( )∨ ∨=

M r g1 … gm∧ ∧,( ) M r g1,( ) … M r gm,( )∧ ∧=

M r1 … rn∧ ∧ g j,( ) M r1 g j,( ) … M rn g j,( )∧ ∧=

M r g1 … gm⇒ ⇒,( ) M r g1,( ) … M r gm,( )⇒ ⇒=

M r1 … rn∨ ∨ g1 … gm∨ ∨,( )

M r1 g1 … gm∨ ∨,( ) … M rn g1 … gm∨ ∨,( )∨ ∨=

M R g1 … gm∨ ∨,( ) M R g1,( ) … M R gm,( )∨ ∨=

M ri g1 … gm∨ ∨,( ) M ri g1,( ) … M ri gm,( )∨ ∨=

ri R1 R2∧= m 2=

Mission Planner: Design & Implementation

36

. The left side of this expression statesthat each of and should visit either or . Unfortunately, the right side statesthat they must visit the same goal, rather than being able to go to either goal. Since theapplication of this axiom in this case produces a result inconsistent with the semantics,this axiom is not included. Instead, Eqn. [3-17] and Eqn. [3-18] define expansion rules toaddress missions which contain OR’s of goals.

An Intuition Interlude 3.3

The stated purpose of GRAMMPS is to address applications which benefit from theefficient execution of multi-robot tasks. While the grammar described above details thespace of tasks which may be planned for and executed by GRAMMPS, it is less obviouswhat these missions look like. This section describes potential tasks in a variety ofapplication areas, and presents the statement in the mission grammar for each task.

Excavation 3.3.1

Assume there are three robots, one which is digging and two which are receiving thedirt and driving to a dump point. While the digging robot remains relatively stationary,the other robots must take turns receiving and dumping dirt. It is necessary tocoordinate their motions such that the task is completed in the shortest possible timewithout conflicts between robots.

where:

• R1: Digging Robot

• R2, R3: Transporting Robots

• Gdig: Digging site

• Gdump: Dump site

Comment: The latter half of the statement could be repeated as necessary until thedigging robot was finished at one site, then Gdump could be changed to a new location,and the process repeated. The grammar itself lacks a looping construct, though it ispossible to provide a supervisory layer which adds terms to the mission statement asneeded to peform missions with repetitive components. This results in a system whichis effectively ‘greedy’, only optimzing the next step to be taken.

Military Reconnaissance 3.3.2

Consider three robots equipped with IR cameras. There are five sites which must bevisited by any of these three robots so that images can be taken and returned tooperations command. After the sites have been visited the robots should return to theirbase. This task could be performed to optimize time (so that the pictures are receivedas soon as possible, to optimize fuel consumption, to optimize safety (so the robots

M R1 R2∧ G1 G2∨,( ) M R1 R2∧ G1,( ) M R1 R2∧ G2,( )∨=

R1 R2 G1 G2

M R1 Gdig,( ) M R2 Gdig Gdump⇒,( ) M R3 Gdig Gdump⇒,( )∧( )⇒

Mission Planner: Design & Implementation

37

travel as often as possible on the safest possible terrain), or some combination of allthree.

where:

• R1 - R3: Robots

• G1 - G5: Observation points

• Gbase: Base site

Warehouse Automation 3.3.3

Consider two robots which must pick up three items in any order and then deposit themon a conveyor belt which will take them to their final destination. This problem wouldlikely be optimized with respect to minimizing the time for the task.

where:

• R1, R2: Robots

• G1 - G3: Object retrieval points

• Gconv: Conveyor belt site

Central Post Office Automation 3.3.4

Large batches of mail are distributed from sorting points to delivery trucks by human-driven trucks. These trucks could potentially be made autonomous, and missionscoordinated with GRAMMPS. For example, assume two bags of mail bound for Duluthare at two locations and need to be loaded onto trucks bound for Duluth. However, bothtrucks bound for Duluth have room for only one bag. Also, one bag of mail is bound forAkron and needs to be loaded onto yet another truck. Three robots exist to do the job.However, the third robot isn’t capable of carrying either of the bags intended for thetruck bound for Duluth.

where:

• R1, R2, R3: Robots

• Gs1,Gs2: Sorting point with mail bound for Duluth.

• Gsa: Sorting point with mail bound for Akron

• Gd1, Gd2: Mail truck bound for Duluth

• Ga: Mail truck bound for Akron

M R1 R2 R3∨ ∨ G1 G2 G3 G4 G5∧ ∧ ∧ ∧,( ) M R1 R2 R3∧ ∧ Gbase,( )⇒

M R1 R2∨ G1 Gconv⇒( ) G2 Gconv⇒( ) G3 Gconv⇒( )∧ ∧,( )

M R1 R2∨ Gs1 Gd1⇒( ) Gs2 Gd2⇒( )∧( ) Gs2 Gd1⇒( ) Gs1 Gd2⇒( )∧( )∨,(M R1 R2 R3∨ ∨ Gsa Ga⇒,( )∧

Mission Planner: Design & Implementation

38

Planetary Exploration 3.3.5

Planetary exploration robots wish to minimize the distance travelled over rough terrainwhilst moving to different locations to collect scientific data. Such a mission could haveits mobile components expressed in and optimized by GRAMMPS. Consider 3 siteswhich need to be visited by particular robots, and then 4 sets of 2 other sites of whichonly one of each pair need be visited by any robot. There are 5 robots available.

where:

• R1, R2, R3, R4, R5: Robots

• G1, G2, G3: First three goals

• Ga1,Ga2; Gb1,Gb2; Gc1,Gc2; Gd1,Gd2: Pairs of alternative goals

Summary 3.3.6

This section has described a variety of tasks and applications. Many of these tasksrequire some initial decision-making process outside of GRAMMPS, for example, todetermine which mailbags need to go where. Once a human or an automatic systemdecides which set of actions need to be given to the robotic fleet, the mission can bepassed along and executed by GRAMMPS. In return, GRAMMPS can providecontinual estimates for time-to-completion for all components of the mission andensure efficient mission execution within the given constraints.

Grammar Compiler 3.4

The grammar compiler takes as input a mission statement given in this missiongrammar. It then applies the axioms and transformations defined above to change thismission statement into one which has the same semantics but is more straightforwardto optimally plan. Before it is possible to explore the methodology for generating thistransformation, a few definitions are needed.

Definitions 3.4.1

AM(X) (atomic mission) 3.4.1.1

The set of all substrings of X which can be expressed in MG2 where:

Eqn. [3-19]

M R1 G1,( ) M R2 G2,( ) M R3 G3,( )M R1 R2 R3 R4 R5∨ ∨ ∨ ∨ Ga1 Ga2∨( ) Gb1 Gb2∨( ) Gc1 Gc2∨( ) Gd1 Gd2∨( )∧ ∧ ∧,( )

∧ ∧ ∧

MG2: m M r g,( )→r Ri r r∧ r r∨→g G j g g∧ g g∨ g g⇒→

Mission Planner: Design & Implementation

39

PAM(X) (plannable atomic mission) 3.4.1.2

The set of all substrings of X which can be expressed in MG3 where:

R-INC(X) (robot included) 3.4.1.3

If X is expressible in MG1, then this is the set of all strings “ ” within X, otherwise.

M-AND(X): 3.4.1.4

This is the set of all substrings of X expressible in MG4 where:

PM(X) (plannable mission): 3.4.1.5

True if: X is expressible in MG5 and:

where MG5 is given by:

Eqn. [3-20]

Eqn. [3-21]

Eqn. [3-22]

Eqn. [3-23]

MG3: m M Ri go,( ) M Ri gs,( ) M r ga,( )→

r Ri r r∨→

go Gi go go∨→

gs Gi gs gs⇒→

ga Gi ga ga∧→

Ri ∅

MG4: m M Ri go,( ) M Ri gs,( ) M r ga,( ) m m∧→

r Ri r r∨→

go Gi go go∨→

gs Gi gs gs⇒→

ga Gi ga ga∧→

A∀ M-AND(X),∈B C,∀ PAM(A)∈ B C R-INC(B) R-INC(C)∩ ∅=( ),≠,

MG5: m M Ri go,( ) M Ri gs,( ) M r ga,( ) m m∧ m m∨ m m⇒→

r Ri r r∨→

go Gi go go∨→

gs Gi gs gs⇒→

ga Gi ga ga∧→

Mission Planner: Design & Implementation

40

UM(X) - Unit Mission 3.4.1.6

The set of strings in X which can be expressed by:

Language 3.4.1.7

L(G) is the set of all strings that can be generated by the grammar G, or the Languageof G. Note that it is straightforward to show that:

In other words, any expression generated by G1 can be generated by G5, any expressiongenerated by G5 can be generated by G4, and so forth.

Motivation 3.4.2

Recall that the purpose of the Grammar Compiler is to transform a given missionstatement into a form which is easier to plan. Now, consider L(MG3). Any expressionin this set is a very simple mission statement which is either the find-path problem, theTSP, the MTSP, a series of find-path’s for one robot, a selection of the shortest find-pathfor a group of robots with a single goal, or selection of the shortest find-path for a singlerobot and a group of goals. Because of the existence of known algorithms (plus trivialextensions thereof) which solve this class of problem, it simplifies the planning processto reduce the mission statement into a form which only contains statements and simplerelations between statements which are in L(MG3). L(MG5) is such a language. Onepurpose of the Grammar Compiler is therefore to transform statements in L(MG1) intostatements in L(MG5), in such a way that the semantics of the statement does notchange.

Unfortunately, statements like: present a particular challenge toa planner: it is impossible to consider the cheapest way to perform the two sub-missionscomponents of this mission independently, as Robot 1 is involved in both parts. ShouldRobot 1 visit both Goal 1 and Goal 2? In which order? Or should Robot 2 visit Goal 1instead? This type of constraint is made explicit in Eqn. [3-22]: given a mission statementin L(MG5) (i.e. what is produced by the Grammar Compiler), no subcomponent of thatstatement which is in L(GM4) (i.e. is composed of AND’s of plannable atomicmissions) can contain subcomponents which are in L(GM3) (i.e. are plannable atomicmissions) that contain the same robot. Therefore, the Grammar Compiler must alsoproduce a particular statement in L(MG5) which avoids conflicts between robots for theplanning stage.

Reduction Algorithm 3.4.3

Rather than give a line-by-line explicit breakdown of the algorithm used to transform astatements in L(MG1) into one with the same semantics usable by the planner, thissection will give an outline of the algorithm by subdividing it into 4 components. Thereare two types of subexpressions which need to be eliminated from a statement in thegrammar. First, any Atomic Mission (element of L(MG1)) which is not an Plannable

Eqn. [3-24]

Eqn. [3-25]

MG6: m M Ri G j,( )→

L MG6( ) L MG3( ) L MG4( ) L MG5( ) L MG1( )⊆ ⊆ ⊆ ⊆L MG3( ) L MG2( ) L MG1( )⊆ ⊆

M R1 R2 G1,∨( ) M R1 G2,( )∧

Mission Planner: Design & Implementation

41

Atomic Mission (element of L(MG2)) needs to be broken down into an expressioncontaining only Plannable Atomic Missions. Second, any expression which contains anconjunction of Plannable Atomic Missions that contain the same robot (i.e. theconstraint in Eqn. [3-22]) must broken down and then rearranged to avoid this problem.Elimination of these problems comprises the first two subdivisions of the ReductionAlgorithm - both utilize the same procedure for breaking down expressions, but targetwhich expressions to break down differently.

This subdivision of this algorithm is called Simplification. Between each processingstep, the Identity, Commutative, and Associative Axioms are regularly applied to keepthe expressions as simple as possible, easing additional manipulation. For example

would be transformed into ; andwould be transformed into .

The final subdivision of this algorithm recombines expressions (without introducingany new conflicts or non-Plannable Atomic Missions) to make more concise plannablemissions which can be more efficiently planned. For example,would be transformed into .

Breaking-down Expressions 3.4.3.1

The rules which permit breakdown are the axioms given by Eqn. [3-6] to Eqn. [3-19]. Forany Atomic Mission X (i.e. a member of L(MG2)) which is not a Plannable AtomicMission,(i.e. a member of L(MG3)) it is possible to show some Mission ExpansionAxiom may be applied to transform X into a group of related Atomic Missions, each ofwhich contains fewer terms that the original expression. By applying axiomsrecursively, eventually only Plannable Atomic Missions will remain. Breaking astatement down via this process ends when only Plannable Atomic Missions remain.

For example, consider the following mission statement in L(MG1):

Applying Eqn. [3-16] yields:

Applying Eqn. [3-17] twice yields:

Applying Eqn. [3-15] yields a plannable mission, i.e. a member of L(MG5):

Resolving AND Conflicts 3.4.3.2

The second step, removing conflicts within AND components of the statement issubstantially trickier than the statement breakdown process outlined above. When a pairof subexpressions are found to conflict, they are broken down further until only Unit

Eqn. [3-26]

Eqn. [3-27]

Eqn. [3-28]

Eqn. [3-29]

M R1 R1∧ G1 G2∨,( ) M R1 G1 G2∨,( ) M R1 R2 R∧3

( )∧ G1 G2∨,( )M R1 R2 R∧

3∧ G1 G2∨,( )

M R1 G1,( ) M R1 G2,( )∧M R1 G1 G2∧,( )

M R1 R2∧( ) R3∨ G1 G2 G3∨( )⇒,( )

M R1 R2∧( ) R3∨ G1,( ) M R1 R2∧( ) R3∨ G2 G3∨,( )⇒

M R1 R2∧ G1,( ) M R3 G1,( )∨( ) M R1 R2∧ G2 G3∨,( ) M R3 G2 G3∨,( )∨( )⇒

M R1 G1,( ) M R2 G1,( )∧( ) M R3 G1,( )∨( )M R1 G2 G3∨,( ) M R2 G2 G3∨,( )∧( ) M R3 G2 G3∨,( )∨( )

⇒

Mission Planner: Design & Implementation

42

Missions remain. This limits conflicting terms within an AND of subexpressions to 6classes: UNIT-UNIT, OR-OR, SEQ-SEQ, SEQ-UNIT, UNIT-OR and SEQ-OR.

For example, the following is a conflicting expression of the OR-OR type:

This expression can be transformed into the following non-conflicting expression4:

Similar transformations are applied for different types of conflicting expressions inorder to transform them into expressions which contain only Plannable AtomicMissions that do not have conflicts between robots. The process going from Eqn. [3-30]

to Eqn. [3-31] uses repeated applications of the Distributive Axiom for Missions (Eqn. [3-

13]).

Recombining 3.4.3.3

Understanding why subexpressions are combined relies on an understanding of theplanning system which will be discussed in the next section. For purposes herein, let itsuffice to note that a single Plannable Atomic Mission with many robots and/or goalsinvolved is substantially more efficient to plan for than a semantically equivalentexpression involving Unit Missions. By using the axioms given by Eqn. [3-6] to Eqn. [3-

19], and by ensuring that no conflicts or non-Plannable Atomic Missions are introduced,planning can thus be simplified. The following is an example mission statement madeup of many Unit Missions:

This can be combined using Eqn. [3-6] and Eqn. [3-19]:

4. Notice that this is quite like a cross-product operation, or a conversion from a product-of-sums to asum-of-products.

Eqn. [3-30]

Eqn. [3-31]

Eqn. [3-32]

Eqn. [3-33]

M R1 G1,( ) M R2 G2,( )∨( ) M R1 G3,( ) M R2 G4,( )∨( )∧

M R1 G1 G3∧,( ) M R1 G1,( ) M R2 G4,( )∧( )M R2 G2,( ) M R1 G4,( )∧( ) M R2 G2 G4∧,( )

∨ ∨∨

M R1 G1,( ) M R1 G2,( ) M R2 G4,( ) M R1 G3,( )∧ ∧ ∧

M R1 G1 G2 G3∧ ∧,( ) M R2 G4,( )∧

Mission Planner: Design & Implementation

43

Algorithm Outline: 3.4.3.4

GRAMMPS Central Planner 3.5

The central planning engine (“planner” in Figure 3-1) takes as input the plannableexpression from the Grammar Compiler, and a matrix of costs. This matrix of costsincludes estimates of the cost to move a Robot to any Goal, and to move a Robot fromone Goal to any other Goal. The GRAMMPS central planner (GCP) is tasked withproducing a representation of all possible ways in which the mission could becompleted which both indicates the current optimal plan and facilitates quickreplanning upon a change in costs. This section will address motivation andimplementation of this planner, as well as providing an analysis of it in traditionalplanning terms.

Motivation 3.5.1

GCP is designed with three primary characteristics: dynamic operation, gracefuldegradation, and extensibility. This subsection discusses these aspects of the design ofGCP with respect to providing reasonable performance. Reasonable performance refersto the ability of this planner to be successfully used in a wide class of real-world tasks,rather than strictly in a theoretical setting. For example, it is reasonable for a multi-robotsystems to have trouble with scenarios involving many hundreds of subtasks; there arevery few applications likely to arise in the near future requiring close coordination of afew robots to such ends. Therefore, while there there are pathological situations inwhich this method will fail, it is designed to be robust enough to handle reasonable real-world scenarios.

A planner designed to operate successfully in a dynamic world must be able to providea plan regularly, even though its knowledge of the world may be changing regularly, andits plans may not be executed exactly. This planner is not explicitly responsible formission replanning, however, it does create a planning structure to facilitate fasterreplanning. More importantly, it is impossible to expect the mission planner to respondas quickly as the path planner or the local navigator to a changing situation. Thus, therewill always be some delay between the acquisition of information and the incorporationof that information into the plan.

Alg. 3-1

compile(X):#input: Mission Statement X in L(G1).A=Simplify(X)B=Breakdown_Atomic_Missions_with_And_Conflicts(A)C=Simplify(B)D=Breakdown_Non-Plannable_Atomic_Missions(C)E=Simplify(D)F=Recombine(E)Y=Simplify(F)return(Y)#output: Mission statement which has the same semantic# as X, and satisfied PM(Y)

Mission Planner: Design & Implementation

44

Graceful degradation refers to the ability of GCP to cease providing optimal plans whenthe computational complexity becomes excessive. When this occurs, GCP will utilizerandomized search routines for the expensive sub-components of the mission,producing good quality but potentially suboptimal solutions. Given that this planner isdesigned for robots operating in a dynamic environment, it is acceptable to loseoptimality during the initial execution of a large mission, as the information being usedto reach decisions is likely inaccurate. Furthermore, as the mission progresses, theplanning problem will become sufficiently small so that the planner will revert tooptimal decision making processes. The trade-offs between exhaustive (optimal) searchand randomized (suboptimal) search are discussed more completely later in this chapter(Comparison of Exhaustive Search to Simulated Annealing, page 56).

GCP is designed to permit straightforward extensibility. If an additional cooperativeoperation, such as area coverage or robot-meeting is required, the only changesnecessary are a dynamic planner capable of providing costs and paths for each involvedrobot, and a corresponding modification to the grammar to allow specification of sucha task. Though not able to solve or address every foreseeable multi-robot task, theGRAMMPS mission grammar and GCP together provide a solid framework forbuilding mission-capable mobile robot teams.

GCP Analysis 3.5.2

A planning system can be analyzed in terms of the completeness, soundness, andoptimality of the plans it computes, as well as the assumptions it makes about the world,and the complexity of the algorithm[Stetntz95b]. This section analyzes the GRAMMPSCentral Planner in these terms, including a discussion of the utility of these metrics withrespect to real-world applications.

A path planner which is complete will always find a collision-free trajectory if oneexists. A resolution-complete planner will always find such a trajectory if a world/robotrepresentation with sufficient resolution is used. The GCP is only as complete as theplanner which is actually computing the paths (and costs) between robots and goals.However, an essential assumption in GRAMMPS is that inter-robot collisions are arelatively small part of the planing problem because 1) the environment is likely tosupport local collision schemes and 2) the cost of executing local avoidance will besmall relative to the whole mission cost. Therefore, in a very cluttered environmentwhere inter-robot collisions were frequent, this planner would not be able to find aparticularly tricky path, thus losing completeness. In the live demonstration system(which is more thoroughly discussed in Chapter 5), the dynamic path planner wasresolution-complete, and therefore GCP was also resolution-complete, excluding issuesof inter-robot avoidance. In the simulation system, the dynamic path planner wascomplete, and therefore, so was GCP, subject to the same limitations as above.

A path planner which is sound guarantees that any path found is actually collision free.GCP is, again, only as sound as the dynamic planner producing paths and costs. Likeabove, inter-robot collisions are possible, and thus GCP is does not produce strictlysound paths. In real scenarios, local-inter robot avoidance schemes typically suffice toavoid collisions. While GCP is not sound in the strict sense, it is functionally sound formany environments given sufficiently robust local avoidance schemes.

Mission Planner: Design & Implementation

45

A path planner which is optimal guarantees that the path found is the cheapest path toreach the goal. The “cheapness” of a plan might be defined by length, safety, orsmoothness of the path. For GRAMMPS, if the dynamic path planners provide optimalpaths between locations, then these paths will be executed. In the case where theenvironment is not known or is changing, a planner can strive to be knowledge-optimal.The notion of “optimal” in dynamic planning is different from that in static planning.In static planning, the environment is fully known and the optimal path, once planned,remains constant during execution. When the state of the world is not fully known, amission plan is optimal if each robot R, at each point PR along its traverse given theaggregate information available at PR, follows the lowest cost path to its goal such thatthe mission is completed with the cost of the longest path any robot traverses isminimized. This is consistent with the notion of mission-cost as discussed earlier in thissection. GCP does deviate from optimal in that local collision avoidance is notaccounted for in the cost metric. This is a reasonable assumption, as these costs aretypically small. However, for very large problems, GCP will stop trying to produceoptimal costs, and use randomized search techniques to produce a near-optimal solutionquickly. Given the NP-complete nature of the TSP and MTSP, it is not reasonable toexpect actual optimal performance for large instances of these problems; therefore, anear-optimal approach is the best one can expect.

The functional computational complexity of this planner is somewhat hard to analyze.It uses an exhaustive search technique for small problems, and then reverts torandomized search for particularly expensive subproblems. For example, in the case ofa 5-robot, 25-goal MTSP, use of randomized search is essential. As components of thisplanner are NP-complete, the entire planner is likewise NP-complete. However, forreasonable sized missions (10’s of goals), involving reasonable numbers of robots (1-10), GRAMMPS provides performance which gracefully degrades optimality in returnfor usable computational complexity.

To conclude, GCP is neither strictly complete, sound, nor optimal. However, under theassumptions which are made concerning the environment and the performance of thedynamic path planners, GCP is very close to providing ideal performance in thesecategories for real applications.

What is Cost? 3.5.3

In the previous subsection, the notion of an “optimal plan” for a group of robots waspresented. This section explores what cost means in several scenarios and for twodifferent multi-robot cost metrics.

There are two very intuitive metrics for judging the efficacy of a multi-robot plan. First,one plan is better then another if the average cost per robot is smaller. Alternatively, twoplans could be compared on the basis of the most expensive portion of each plan, i.e.,strictly on the basis of the cost of robot whose share of the plan has the highest cost.The first one of these metrics can be thought of as minimizing distance, while thesecond can be thought of as minimizing time.

Mission Planner: Design & Implementation

46

Given a plan involving N robots, and an cost for each robot , a metric forcomparison using the distance metric is given by:

Thus, given two vectors of costs, C1 and C2, C1 is preferred over C2 if D(C1) < D(C2).

For the time metric, it is easiest to express the mechanism for comparing two cost arraysin a slightly different manner. Given an vector of costs C as above, define MAX(C) andSUM(C) as:

Using those equations, the following logic defines the ordering of two arrays of costsC1 and C2: in terms of a cost metric T(C):

To understand these metrics, imagine a mission which can be accomplished in 4different ways. For each option, the ith element of the cost vector is the cost of onerobot’s contribution to the mission. The following table gives an example of 4 differentcost vectors,and their ordering for the two different metrics above:

The shaded entries in this table demonstrate that different cost metrics can result indifferent choices being made for how a mission should be accomplished, and, inparticular, how much effort each robot should put towards the mission.

How D(C) and T(C) relate to the actual concept of time and distance depends on howcost is provided to GCP. If cost is directly related to the distance a robot travels, thenD(C) accurately minimizes distance for the entire mission; in this case, however, T(C)only accurately minimizes time for the mission if robots travel at equal speed. On theother hand, if cost is directly related to the time it takes a robot to complete it’s mission,then T(C) accurate minimizes the time for the slowest member to complete the mission;however, in this case, D(C) only accurate minimizes distance if the robots travel at a

Eqn. [3-34]

Eqn. [3-35]

Eqn. [3-36]

Table 3-2: Different Cost Metrics and the effect on the preferred choice.

Cost VectorCM

Robot 1’sCost

Robot 2’sCost

Robot 3’sCost

Orderingusing D(C)

Orderingusing T(C)

(1=best, 4=worst)

C1 12 10 8 4 4

C2 10 4 2 2 3

C3 9 7 9 3 2

C4 2 3 4 1 1

Ci i i 1 N,( )∈,

D C( )Ci

N∑

N------------=

MAX(C) C j j 1 N,( )∈, i 1 N,( ) Ci C j≤,∈∀=

SUM(C) CiN∑=

T C1( ) T C2( )< MAX C1( ) MAX C2( )<( )MAX C1( ) MAX C2( )=( ) SUM C1( ) SUM C2( )<( )∧

∨↔

CM1 CM2 CM3

Mission Planner: Design & Implementation

47

equal speed. So, while these metrics apply easily for the case where robots travel atidentical speed, in the case where they do not, care must be taken to provide costs scaledaccordingly given the relative expected speeds of each vehicle.

Beyond simply measuring time and distance, these two metrics for comparing costvectors could be used to prefer mission plans which minimize risk. If the robots usedwere very expensive, or carried humans on board, it might be appropriate for the costpassed to the planner to be in terms of the total risk expected to be accrued duringexecution. In this case, the distance metric could result in some participants beingexposed to much higher risk, but the total risk would be lower. The time metric wouldminimize the maximum risk to which any participant, but the total risk could be higher.

These examples should elucidate the fact that determining the meaning of cost, and thenotion of the “best” plan are subject to a deeper understanding of the intended missiontask, and the definition of cost as provided by the dynamic mission planner. For thepurposes of this work, rather than support every possible general metric, it is assumedthat the dynamic planners will provide cost as an estimate of the time for a robot toaccomplish a task at a fixed speed. GCP will weigh these costs by the estimated averagevelocity of the each robot before comparing these costs using the time metric. It wouldbe a straightforward task to switch to another metric, however, it is not a part of thisresearch.

Implementation 3.5.4

As addressed in the previous section (Grammar Compiler, page 38), the input to theplanner is a modified, but semantically equivalent, form of the original missionstatement. This statement is guaranteed to consist of AND’s, OR’s and SEQUENCE’sof Plannable Atomic Missions. This situation greatly simplifies the design of theplanner, allowing straightforward search and cost-propagation techniques to be used.This subsection discusses the basic search algorithm used in GCP.

Helpful Definitions 3.5.4.1

Define a mission statement M that has the following properties:•LEN(M): The number of PAMs or sub-statements within a mission statement, e.g.

LEN(M)=2 for M= .•M(i): The i+1th sub-statement within a mission statement, e.g. for the above

example, M(1)= .•TYPE(M): The type of expression relating the sub-expressions in the mission

statement, defined to be NONE, AND, OR, or SEQ. e.g. for the above exampleTYPE(M) = OR, TYPE(M(1)) = NONE.

•R-TYPE(M) / G-TYPE(M): If TYPE(M) is None, then this is the type ofexpressions relating the robots / goals in this plannable atomic mission, undefinedotherwise, e.g. for the ongoing example, G-TYPE(M(1))=AND, and R-TYPE(M(1))=NONE.

Define a unit plan p with the following properties:•LIST(p): an ordered sequence of goals for each robot, e.g.: for two robots,

[[2,3],[1,4,5]] means robot 1 to goals 2 then 3, and robot 2 to goals 1, 4, then 5.

M R2 G2,( ) M R1 G4,( )∧( ) M R2 G2 G4∧,( )∨

M R2 G2 G4∧,( )

Mission Planner: Design & Implementation

48

•STATE(p): A list of ordered pairs for each robot containing the final goals visitedby each robot, and the total cost accrued so far by the robot to reach that goal.Thisis referred to as the “Search State” of a unit-plan.

•NEXT(p): The plan node (definition follows) which follows this unit-plan, ifnone exists.

Finally, define a plan node P consisting of a set of unit-plans that has the followingproperties:

•P(i): The i+1th plan-node in the set P.•LEN(P): The number of unit-plans in this plan node.•P1+P2: The sum of two plan nodes is a plan node containing all unit-plans from

each plan node. For example, if LEN(P1) = 2, and LEN(P2)=3, LEN(P1+P2) = 5•P1*P2: The product of two plans nodes is a plan node containing one entry

P(((i*LEN(P2))+j) for each P1(i) and P2(j). Each entry contains the concatenationof each robots list within each unit plan. For example, if LEN(P1) = 2, andLEN(P2)=3, LEN(P1*P2) = 6. Also5, if P1(1)=[[3,4,2],[]], P1(2)= [[0,1],[]],P2(1)=[[],[2,9]], P2(2)=[[],[4,7]], and P3=P1*P2, then P3(1)=[[3,4,2],[2,9]],P3(2) = [[3,4,2],[4,7]], P3(3)=[[0,1],[2,9], P3(4)=[[0,1],[4,7]].

Atomic Mission Planning 3.5.4.2

Inspection of grammar G3 (Eqn. [3-20]) reveals that there are 6 classes Plannable AtomicMissions (PAMs). These classes can be categorized by their G-TYPE and R-TYPE.These classes each have a straightforward method for generating a plan node consistingof the possible alternative plans for this plannable atomic mission for which the entiremission could be optimized. Given that the planner takes as input the costs from allrobots to all goals, and from all goals to all other goals, many of the following methodsreduce to simply using the optimal path and cost for a given robot-goal or goal-goal, asprovided by the dynamic planner.

Unfortunately, merely picking the optimal solution for a given Plannable AtomicMission is not sufficient. Since this is only one component of a larger mission, for eachPAM, it is necessary to generate an optimal solution for all possible final states of allinvolved robots, as it is impossible to know at this point at which goal a robot shouldfinish so as to be most helpful for the rest of mission. For example, if the missionstatement is: , it is impossible to know if a goal ordering of(2,4,3) or (4,2,3) will be preferable when independently planning the first PAM in thisexpression. For this reason, both alternatives need to be explored.

The following table lists the classes of plannable atomic missions, and an upper-boundon the number of alternative plans which must be generated. Define M to be a plannable

5. Note that the unit plans of plan nodes involved in a product have empty plans for at least one of theirrobots. This is because of the nature of the AND-resolution as described earlier in this chapter (ResolvingAND Conflicts, page 41).

∅

M R2 G2 G4∧,( ) M R2 G3,( )⇒

Mission Planner: Design & Implementation

49

atomic mission, R to be the number of robots in the Robot portion of the PAM and G tobe the number of robots in the Goal portion, e.g. for , R = 1 and G = 2:

The exact algorithm which performs the generation of possible plans for a PlannableAtomic Mission is fairly straightforward. However, the TSP and MTSP components aremuch more involved. They will be discussed in detail in the next section of this chapter.

Mission Recursion 3.5.4.3

Given a search_atom() procedure which takes a plannable atomic mission andgenerates all needed alternatives as unit plans, the recursive algorithm which searchesthe space required by the mission statement follows:

To start planning, ‘plan’ is called with M equal to the full mission statement, S equal tothe current state of the robots (i.e. at their current locations, with zero cost), and N equalto zero. This algorithm is an implementation of a depth-first search on the missionstatement. The branching factor (i.e. the multiplicative growth of alternatives which

a. This expression is not intuitive and will be discussed in the next section of this chapter.

Table 3-3: Classes of Plannable Atomic Missions

Name R-TYPE(M) G-TYPE(M) MethodBranching Factor

(upper bound)

UNIT-UNIT NONE NONE none 1

UNIT-AND NONE AND TSP G

UNIT-OR NONE OR select shortest path G

UNIT-SEQ NONE SEQ add shortest paths 1

OR-UNIT OR NONE select shortest path R

OR-AND OR AND MTSPa

Alg. 3-2

M R2 G2 G4∧,( )

G R 1–+

R R!

plan(M,S,n):P = {}if TYPE(M)=NONE:

P = search_atom(M)else if TYPE(M) = SEQ:

if (n<LEN(M):P= plan(M(n),S,0)for i in LEN(P):

NEXT(P(i))=plan(M,STATE(P(i)),n+1)else if TYPE(M) = OR:

for i in LEN(M):P = P + plan(M(i),S,0)

else if TYPE(M) = AND:for i in LEN(M):

P = P * plan(M(i),S,0)return(P)

Mission Planner: Design & Implementation

50

need to be explored) of each plan node depends on TYPE(M), where BF(M(i)) is thebranching factor of the ith subexpression of M, and is given in following table:

The method for keeping track of the “optimal” plan within a plan node is not detailedin this algorithm, as it substantially complicates the presentation. The method for doingthis involves recording best unit plan for each plan node, updating this whenever newplans are added to the node. Extracting the optimal plan is then a process of looking atthe “best” unit plan, and following any NEXT pointers which may exist to the next plannode, and so forth.

Replanning 3.5.5

Rapid replanning is facilitated by the initial construction of a structure which representsthe entirety of the search space. This structure is built up as an artifact of Algorithm 3-2 above. Replanning then consists of traversing this structure, adding costs, and callingthe optimization routines on components as needed. The observation that mission plansshould not change very often, as they reflect large scale changes in world-knowledge,allows this simple replanning technique to suffice. During replanning, all alternativesare compared to continuing with the previously determined plan. An alternative mustbe significantly superior (cheaper) than the current plan before a switch will be made.This avoids the problem of thrashing on goal selection due to slight lags in costinformation as it flows between modules. On average, replanning is approximatelytwice as fast as the initial planning, though this varies substantially depending on themission statement.

Pruning 3.5.6

As the mission completes & goals are reached, it is necessary to remove possibilitiesfrom the mission structure. When a goal is reached, it is removed from the missionstatement, and the planning structure pruned appropriately, leaving only the unfinishedportions of the mission. When pruning, either a plannable atomic mission is madesmaller (i.e. the number of goals reduced), or the plannable atomic mission has only asingle goal which has been reached, and then the expression involving a number ofplannable atomic missions is reduced. Consider the following example:

If Robot 1 visits Goal 1, then that atom is reduced, making the mission statement:

Table 3-4: Branching Factor for Mission Statements

TYPE(M) Branching Factor

NONE See Table 3-3:

SEQ

OR

AND

Eqn. [3-37]

Eqn. [3-38]

BF M i( )( )∏BF M i( )( )∑BF M i( )( )∏

M R2 R1∨ G1 G2∧,( ) M R2 G3,( )⇒( ) M R3 G4,( )∧

M R2 R1∨ G2,( ) M R2 G3,( )⇒( ) M R3 G4,( )∧

Mission Planner: Design & Implementation

51

The other type of pruning is illustrated by the change made when Robot 3 reaches Goal4:

Changes in the mission statement map directly and easily into changes made in theplanning structure. Reductions in an atom changes the method of optimization of theatom, while reduction in the statement can remove whole portions of the search tree.For simplicity reasons, the current implementation reduces the mission statement, andthe wholly regenerates the planning structure, as this facilitates memory managementissues.

Component Planners 3.6

Given the enormous volume of research into solutions to the TSP and MTSP[Lawler85],it is reasonable to solve these plannable-atomic-missions separately from the others,and outside of the above framework. Furthermore, since the TSP and MTSP canpotentially introduce the largest number of additional solutions to the missionstatement, it is profitable to offer randomized algorithms for larger instances of theseproblems. This section discusses the implementation of exhaustive and randomizedsolutions to the TSP and MTSP, as well as their relationship to the GRAMMPS CentralPlanner, described above.

Exhaustive Search 3.6.1

An exhaustive search on an instance of the TSP or MTSP is a very computationallyexpensive proposition. This process is made even more expensive given the fact thatthese problems are only components of a much larger mission. It is necessary not onlyto find a single best solution for the problem given the start state, but also for all possibleending states of the robots. The total computational cost of an exhaustive TSP or MTSPsearch therefore is the product of the number of possible end states and the cost ofperforming a single instance of the search.

Complexity Analysis: Terminal States 3.6.1.1

For the TSP, the problem of end states is straightforward. Consider a problem with 1robot and 5 goals. There are only 5 possible locations the robot could finish it’s tour.Therefore, for the purposes of GCP, solving 5 instances of the TSP, one with each of the5 possible terminal goals pre-specified.

For the MTSP, the problem becomes quite non-linear in the number of robots and goals.(For this discussion, assume a problem with R robots and G goals). First, it is possiblethat up to R-1 of the robots may not be involved in any tour. This can be thought of asadding R-1 possible terminal goals. The problem of enumerating all sets of the terminalgoals is therefore of size .6 This expression does not specify which robot ends

6. is defined as “m choose n”.

Eqn. [3-39]M R2 R1∨ G2,( ) M R2 G3,( )⇒

G R 1–+

R

m

n

Mission Planner: Design & Implementation

52

at each goal. Including this increases the number of instances of the MTSP which needto be performed by a factor of R!, yielding a total of

For the relatively modest case of G=6 and R =4, this would imply that the MTSP wouldneed to be solved 72 times!

Fortunately, it is frequently possible to greatly improve this. By searching the fullmission statement in advance, and determining which goals are possible for each robotto go to reach next, the MTSP could be performed specifying all possible sets ofterminal goals for each robot from their sets of possible next-goals. For example, givena mission statement of: , insteadof performing 7 MTSPs only a single MTSP where each robot is forced to end at Goal7 would need to be performed. More generally, if is the number of next-goals possiblefor the ith involved robot, and N is the total number of robots involved in the MTSP, thenthe number of instances of the MTSP which need to be performed is . For theTSP, this reduces to simply .

While the latter methodology for enumerating terminal states is generally superior, it ispossible that fewer sets of terminal states will need to be checked if the formed methodis used. Therefore, when determining the number of instances of the TSP/MTSP whichneed to be performed for a give instance of the problem, both two alternatives arechecked, and the one yielding the smaller search space is utilized.

Complexity Analysis: Alternative Tours 3.6.1.2

[Hogg93] states that the number of unordered samples of size r that can be selected fromN objects with replacement (i.e. the same object can appear in two samples) is:

For the MTSP, it is necessary to assign a robot to each goal, and each robot may beassigned to more than one goal. The above formula enumerates goal partitions, i.e. themanner in which G goals may be partitioned among R robots, when n=R and r=G, or inother words, the allocation of goals among the robot.s For example, if (ABBC) meansRobot A should visit 1 goal in its tour, Robot B should visit 2, and Robot C should visit1, then the following lists all partitions for R=3 and G=4:

However, this says nothing about the order in which the goals are to be visited by therobots. To include this in the total count of all possible MTSP tours, it is necessary tomultiply this by the number of permutations of G goals ( ). Continuing the above

Eqn. [3-40]

Eqn. [3-41]

Table 3-5: Example goal partitioning

AAAA AAAB AAAC BBBC AABC

BBBB AABB AACC BBCC ABBC

CCCC ABBB ACCC BCCC ABCC

G R 1–+

R R! G R 1–+( )!

G 1+( )!------------------------------=

M R1 R2 R3∨ ∨ G1 G2 G3 G4 G5∧ ∧ ∧ ∧,( ) M R1 R2 R3∧ ∧ G7,( )⇒

Fi

FiN∏

F1

n 1– r+( )!n 1–( )!r!

---------------------------

G!

Mission Planner: Design & Implementation

53

example, if “3241” means Goal 3 should be visited first, then goal 2, etc., then the goalpermutations are:

So, for each of the above enumerated partitions, each of the permutations given definesa separate tour. For example, he two bold entire in the tables, ABBC and 3241, yields atour where robot A visits goal 3, robot B visits goal 2 then goal 4, and C visits goal 1.

Therefore, the product of the number of partitions and the number of permutationsyields the number of possible tours, i.e.:

where R is the number of robots and G is the number of goals. For the (relatively)simpler TSP, this equation reduces as expected, setting R=1, yielding .

Summary 3.6.1.3

Exhaustive search can be terribly expensive. However, for small numbers of robots andgoals, it is feasible to search for the optimal tour within the mission context in a shortperiod of time. As the size of the problem gets larger, it is necessary to rely onalternative search methods whose computational complexity does not grow nonlinearly.Additionally, the solution to the TSP and MTSP in the context of a larger missionimplies that multiple searches will need to be performed, based either on the number offuture goals for involved robots, or on the number of possible terminal goal states.

Randomized Search 3.6.2

A vast amount of research exists into methods for solving the TSP via randomizedsearch techniques including genetic algorithms[Chatterjee96], neural nets[Hopfield85], andsimulated annealing[Jeong90]. For the purposes of this work, it was necessary to select amethod which performs well on relatively small instances of the problem. Huge TSPsare “solved’ using randomized searches; for example, tours of thousands of cities arepart of optimizing the order of holes to be drilled into printed circuitboards[Kirkpatrick84].

Polynomial-time algorithms exist for the TSP which produce tours which are within of optimal, however, the order of the polynomial which determines the complexity

of the algorithm is very large even for fairly large , e.g. ~ for , where Nis the number of cities in the tour[Arora96]. The best alternative bounded solution for theTSP is Christofides algorithm[Lawler85], which is for . However, for caseswhere this algorithm could run faster than an randomized search, it is still likely toproduce an inferior solution.

While a variety of search techniques could be used to provide good solutions to theseNP-complete problems, simulated annealing was selected because of its ease of

Table 3-6: Example goal permutations

1234 1243 1324 1342 1423 1432

2134 2143 2314 2341 2413 2431

3124 3142 3214 3241 3412 3421

4123 4132 4213 4231 4312 4321

Eqn. [3-42]R 1– G+( )!

R 1–( )!------------------------------

G!

1 ε+

ε O N60( ) ε 0.5=

O N3( ) ε 0.5=

Mission Planner: Design & Implementation

54

implementation and the demonstrated high-quality of results in similar applications.This subsection discusses the implementation of simulated annealing for the TSP andMTSP, and discusses the decision making process for determining when to utilizerandomized over exhaustive search in this application.

Simulated Annealing for the TSP 3.6.2.1

Numerical Recipes in C[Press88] provides an excellent introduction to the conceptsbehind simulated annealing. It states the following elements are required to make useof the traditional algorithm for simulated annealing:

1. A description of possible system configurations.2. A generator of random changes in the configuration; these changes are the“options” passed to the system.3. An objective function E (analog of energy) whose minimization is the goal ofthe procedure.4. A control parameter T (analog of temperature) and an annealing schedulewhich tells how it lowered from high to low values, e.g., after how many randomchanges in configuration is each downward step in T taken, and how large isthat step. The meaning of “high” and “low” in this context and the assignmentof a schedule may require physical insight and/or trial-and-error experiments.

The implementation of the TSP for this application follows that in [Press88] very closely.A system configuration is described by an ordered list of goals to be visited. Therandom changes are those proposed by [Lin65], and consist of “reverse” and “transport.”The former takes a section of the tour and reverses its order. The latter selects a sectionof the tour, removes it, and re-inserts it into a different location in the tour. They arechosen randomly, with equal likelihood. The initial solution used to start the process isa random ordering of the goals.

The objective function is identical to the distance metric described in earlier (What isCost?, page 45)

where T is a tour with as the ith goal in the tour, N is the number of goals involved inthe tour, with N=0 as the current location for the robot, and C(i,j) is the currentestimated cost from location i to location j. This can be intuitively thought of as the totaldistance to be driven during the tour. Note that, unlike many TSP implementations,there is no requirement for the tour to end where it began.

The annealing schedule is empirically determined, as is the norm for this class ofalgorithm. The temperature begins at 0.5, and is reduced by 10% for every temperaturestep, with a maximum of 100 temperature steps. No more than 100 random solutionsare tried at every step. Regaudless of the number of solution tried at a given temperatureso far, a step down is made in temperature if 10 improved solutions are found at a giventemperature. An improvement is defined as a 2% decrease in path length. If 6temperature steps are passed with no improvement, the annealing is halted. Figure 3-2shows a sample tour generated by this algorithm for 45 goals. Execution time was under

Eqn. [3-43]E T( ) C T i T i 1+,( )i 0=

N

∑=

T i

Mission Planner: Design & Implementation

55

1 second. While it is not known how close this solution is to the optimal tour, the lack

of edge crossings is a good first indicator of a satisfactory tour.

Simulated Annealing for the MTSP 3.6.2.2

The MTSP uses a similar set of control parameters. The system configuration is definedby a list of tours R, where is jth step in the ith robot’s tour. The random changes arethose used in the TSP, plus two additional methods, “transplant” and “swap.” Theformer removes a section from one robot’s tour, and inserts it into the tour for anotherrobot. The latter selects a section from two robots’ tours and exchanges them. Each ofthe 4 methods for changing one solution into another equally likely to be selected. Theannealing schedule used is also similar to that for the TSP, with identical startingtemperatures, reduction factors, and termination conditions. However, the number ofsteps to be tried at each temperature is multiplied by the number of involved robots.This reflects the greater difficulty in determining a solution as the number of robots isincreased.

The objective function for the MTSP is much more complex. If a distance-like metricwere chosen, the sum of the costs of all the tours would suffice. However, given thetime-like metric being utilized, the objective function must reflect that the cost of themost expensive tour is dominant term, and that the sum of the remaining terms is thesecond order effect. In this discussion, the following definitions apply: n is the numberof robots involved, C,C1, and C2 are arrays of costs, where is the cost of the ith

robot’s tour, and is the cost most expensive tour.

Figure 3-2: Sample TSP solution for 45 cities

-10 -5 0 5 10-10

-5

0

5

10

Rij

Ci

CL

Mission Planner: Design & Implementation

56

Two observations allow derivation of the appropriate form for energy function E. First:

where A is some positive integer. This is because C1 and C2 are two “neighboring”tours: there is no possible cost array with an intermediate value. Second, the form ofE(C) should be:

This implies that E is some function of the largest cost, plus the total length of all tours.This satisfies the constraint given above that a change in cost be reflected in a changein energy, as a unit change in any tour will increase the energy by a unit. Therefore, toexplicitly define E(C), the form of is needed. Plugging the constraints from Eqn.

[3-44] into Eqn. [3-45] and reducing:

Solving the final recurrence relation in Eqn. [3-45] gives the following expression for:

Substituting this solution back into Eqn. [3-45] gives the following expression for :

This equation is intuitively satisfying as grows with the square of the largest cost.If non-integer costs were used, a similar derivation could be performed using slightlydifferent constraints to determine an appropriate objective function, the largestdifference arising because of the need to use differential calculus to solve .

Figure 3-3 shows a tour found using the above algorithm for 4 robots and 24 goals.

Comparison of Exhaustive Search to Simulated Annealing 3.6.2.3

For even relatively small instances of the TSP and MTSP, exhaustive search techniquesbecome far too computationally expensive to perform. Figure 3-4 shows a comparisonfor the TSP between randomized and exhaustive search for a number of goals between3 and 18. The break-even point in terms of computation is at about G=8.

Similar comparisons for the MTSP, with G between 3 and 15, are shown forR=G(Figure 3-5), R=G/2(Figure 3-6) and R=G/4(Figure 3-7).

Eqn. [3-44]

Eqn. [3-45]

Eqn. [3-46]

Eqn. [3-47]

Eqn. [3-48]

for: C1 A 0 0 ... 0, , , ,[ ]= C2 A 1– A 1– ... A 1–, , ,[ ]=

E C1( ) E C2( )– 1=

E C( ) f CL( ) Cin∑+=

f CL( )

f A( ) A+( ) f A 1–( ) n A 1–( )+( )– 1=

f A( ) f A 1–( ) n A 1–( ) A– 1+ +=

f A( ) f A 1–( ) n 1–( ) A 1–( )+=

f A( )

f A( )CL CL 1–( ) N 1–( )

2----------------------------------------------=

E C( )

E C( ) 12---C

LCL 1–( ) N 1–( ) Ci

N∑+=

E C( )

F A( ) F A ε–( )–

Mission Planner: Design & Implementation

57

These graphs demonstrate clear computational advantage of simulated annealing ascompared to an exhaustive search. However, it is also necessary to determine if there isever an advantage to use a substantially slower search method in order to reach acheaper-to-execute solution. If the optimal solution to a problem takes an appreciableportion of the tour length to compute, then it is likely to be of little advantage to performthat computation. For most missions likely to be executed by GRAMMPS, missionsexceeding a 100,000 seconds (>24 hours) are not expected. For problems which takeapproximately 1000 seconds to compute optimally, the simulated annealing approach

Figure 3-3: Sample MTSP solution for 4 robots and 24 goals

Figure 3-4: Comparison of Exhaustive to Randomized Search for TSP

-10 -5 0 5 10-10

-5

0

5

10

3 6 9 12 15 180.000010

0.001000

0.100000

10.000000

1000.000000

Pro

cess

ing

Tim

e (s

ec)

# Goals

ExhaustiveRandomized

Mission Planner: Design & Implementation

58

Figure 3-5: Comparison of Exhaustive to Randomized Search for MTSP, R=G

Figure 3-6: Comparison of Exhaustive to Randomized Search for MTSP, R=G/2

Figure 3-7: Comparison of Exhaustive to Randomized Search for MTSP, R=G/4

3 6 9 12 150.000010

0.001000

0.100000

10.000000

1000.000000

Pro

cess

ing

Tim

e (s

ec)

# Goals

ExhaustiveRandomized

3 6 9 12 150.000010

0.001000

0.100000

10.000000

1000.000000

Pro

cess

ing

Tim

e (s

ec)

# Goals

ExhaustiveRandomized

3 6 9 12 150.000010

0.001000

0.100000

10.000000

1000.000000

Pro

cess

ing

Tim

e (s

ec)

# Goals

ExhaustiveRandomized

Mission Planner: Design & Implementation

59

is exceptionally successful, finding the optimal solution 95% of the time. Given this, amore complex decision process which trades computation for performance is unlikelyto improve performance.

Summary 3.6.3

The TSP and MTSP arise from the Mission Grammar and are the most computationallyexpensive portion to search. By selecting between exhaustive or randomized searchmethods, it is possible to achieve near-optimal solutions for reasonably sized instancesof the problems.

Summary 3.7

• The mission planning performed by GRAMMPS occurs in the GRAMMPS MissionPlanner. The GCP accepts mission statements from an operator and path-costs from agroup of path planners. The GCP outputs robot-goal assignments to the local navigator,and can request help from the operator if the mission becomes intractable.

• The GRAMMPS mission grammar provides a general method for defining mobilemissions involving multiple mobile robots. Statements in this grammar can bemanipulated without changing the semantics of the statement via a group oftransformation rules similar to those in formal logic systems.

• The grammar compiler accepts statements in the mission grammar and transforms themusing the aforementioned transformation rules into a representation which makesexplicit potential conflicts in robot allocation. This representation is also designed tofacilitate planning by reducing the problem to a set of easily-solved subproblems ofreduced complexity

• The mission planner uses the output of the grammar compiler to generate an optimalplan for execution of the mission statement. When first planning, a complete structurerepresenting the possible mission alternatives is generated which is later used tofacilitate rapid replanning during execution. As goal in the mission are reached, thisstructure is pruned to represent only the remaining tasks of the mission.

• The mission grammar allows expression of missions which involve TravellingSalesman Problem-like components. As these problems are computationally intractable(NP-complete) for sufficiently large instances, simulated annealing is utilized as analternative search methodology as needed.

Mission Planner: Design & Implementation

60

61

Chapter 4

Results from Simulation

The GRAMMPS mission grammar provides a mechanism for the expression ofcomplex missions involving multiple mobile robots. The GRAMMPS Central Planner(GCP) is capable of planning optimal missions for statements in this grammar,permitting dynamic plan modification during execution. This chapter provides resultsfrom simulations of the GCP, beginning with a discussion of the simulationenvironment and the simplification and assumptions implicit therein. A variety ofsimulated runs are presented, demonstrating the utility and benefits of missionplanning. The chapter concludes with some insights on the importance of and need fordynamic mission planning.

Simulation Details 4.1

Simulation has served several purposes in this work. First, the expense (both actualmoney and time) and inconvenience of operating on the actual vehicles precludesperforming all actual development testing on the robots. Second, it is difficult to set upparticular controlled trials given the vagaries of actual positioning and perception.Third, having only two robots prevents testing of missions or tasks which require thecoordination of three or more agents. This section discusses the simplifications andassumptions made for simulation and the design differences between the two differentsimulation environments from which results are presented.

Assumptions & Simplifications 4.1.1

First, assume the existence of a dynamic path planner which uses the current map togenerate optimal paths to goals. This path planning component will be discussed indetail in the next chapter. For purposes of presenting the results from mission planning,it is sufficient to understand that there is one planner per goal location which isresponsible for maintaining optimal paths to that goal, constantly incorporating map

Results from Simulation

62

information from the robot(s), providing cost estimates to the GRAMMPS CentralPlanner.

Second, perfect perception is assumed. It is difficult to effectively simulate perceptionerrors Given that world knowledge is always being accumulated, the addition ofchanging map information adds little to the fidelity of the simulation as changinginformation is handled identically to new information - the map is updatedappropriately. The world map can initialized with both know and unknown obstacles.Whenever one robot sees an area, this information is shared between all robotsimmediately. Obstacles, when perceived, are placed into the grid-representation worldand expanded by half of the vehicle’s width. This corresponds to a mapping intosomething close to configuration space. Additionally, these regions are always boundedby a “caution zone” equal to approximately half of the vehicle’s width. This biases thepath planners to selection of paths which leave a safe distance between the robot andthe obstacle.

The communication system, too, is assumed to be perfect. Effective inter-robotcommunication is viewed for this work as an engineering necessity, rather than aresearch area. All robots are assumed to be able to communicate information withouterror. In simulation, no limitation is placed on communications bandwidth. This turnsout to be a reasonable assumption as the inter-robot communications bandwidth wasobserved to be quite low (< 4800bps) in the demonstration system (See Chapter 5.)

Idealistic vs. Realistic Simulation 4.1.2

The higher the fidelity of a simulation, the greater the effort and computation whichmust go into it’s production and execution. For GRAMMPS, two different simulationenvironments are used, each with differing degrees of fidelity. The GRAMMPSUniverse Idealistic Simulation Environment (GUISE) removes several layers ofcomplexity from simulation, providing only a mechanism to demonstrate and testcomplex missions. The other environment, GREASE (GRAMMPS REAlisticSimulation Environment), retains more features of the actual on-robot system. Whileboth GUISE and GREASE share the assumptions made in the previous section, theydiffer in how the address synchronization, mobility, and perception.1

GUISE provides perfectly synchronized operation, operating as a single process exceptfor an external GUI for display. The central loop first simulates perception for eachrobot, applies the newly sensed information to the shared map, instructs the pathplanners to update, uses those newly-updated costs to replan the mission plan, and themoves each robot along the optimal path to the appropriate goal. GREASE, on the otherhand, is much closer to the live system on the robots as will be described in the nextchapter. Each robot has its own process which perceives and then moves according toits goal assignment. The GCP and path planners operate asynchronously, acceptinginformation from the simulated robots and sharing that information between each otheras appropriate.

Concerning mobility, the robots in GUISE are circular and omnidirectional. Theyalways move precisely along the optimal path to the goal as provided by the path

1.Thank goodness there isn’t a GRAMMPS Robot Operation Simulation Suite, orGROSS.

Results from Simulation

63

planners. Additionally, no effort is applied to address inter-robot collisions. Robots inGREASE are rectangular, and have a limited turning radius. As path information isprovided asynchronously from the path planners, they may not always choose the mostup-to-date path to follow, allowing them to make significant errors in control. Therobots in GREASE can also become trapped, because they, like the robots used for livedemonstrations, lack the ability to reverse. However, by selecting appropriateenvironments, this eventuality can be prevented. GREASE also uses a simple fixed-priority stop-and-wait heuristic for avoiding inter-robot collisions. If one robot becomestoo close to another with a higher priority, the former stops until the latter leaves thearea, unless the latter is no longer involved in the mission. In that case, the first robot isallowed to continue moving. In any case, the stopped robot is treated as an obstacle bythe path planners, avoiding actual collisions. Once the danger is passed, that pseudo-obstacle is removed from the map.

Robots in GUISE have a simulated 360-degree field of view sensor with limited range.As mentioned above, perception errors are not modeled. The simulated sensor forrobots in GREASE has a trapezoidal field-of-view footprint, similar to one generatedby stereo-vision or older models of laser range finders. An 100 degree by 50 degree(horizontal by vertical) field of view is used. Neither environment models one obstacleobscuring the visibility of another. While this is a simplification, the limited sensorrange and relatively large scale of obstacle regions imply that this does not significantlyaffect the fidelity of the simulation with respect to live performance.

The differences between GUISE, GREASE and the actual demonstrated system aregiven below. The demonstration system is described in detail in the next chapter, andinformation is provided here for comparison purposes only.

Table 4-1: Comparison of simulation environments & demonstration system

Category GUISE GREASE Demonstration System

Communications unlimited band-width, zero latency

unlimited bandwidth,small (<10ms) latency

105Kbps, small (<100ms)latency

Mobility Omnidirectional Non-holonomic, limitedturning radius

Non-holonomic, limited turningradius

PositionEstimation

Perfect Perfect <20cm errors

OrientationEstimation

N/A Perfect 1-2 degree errors

Sensor Footprint Omnidirectional,fixed range

100o FOV Omnidirec-tional, 25m

range

50o FOV on apan/tilt unit

Sensor Errors None None Occasional spurious obstaclesdetected

Steering Control Plan followedprecisely

Latencies modeledplus imprecise path

following

Latencies, plus imprecise pathfollowing

Inter-robotCollision

Avoidance

Not supported Stop-and-WaitHeuristic

Stop-and-Wait Heuristic

Results from Simulation

64

Justification 4.1.3

The danger in using any simulation system is that the actual difficulties of the problemto be addressed will be abstracted away, resulting in a simulation which bares littlerelationship to the actual version. GREASE provides simulation of substantially higherfidelity than GUISE, though there are two primary simplifications which should bejustified to ensure that the simulation remains reasonable.

First, the assumption of zero perception noise is quite unrealistic. On the other hand,the system is designed to accept changing perception information at any time, accurateor not. If knowledge of inaccurate information could be provided, the planners couldaccommodate paths which traded-off likelihood of failure for willingness to drive intopotentially troubled regions. Therefore, though perception noise is not modeled, themanner in which perception is handled implies that reasonable noise would not affectthe system, and thus need not be introduced into simulation

Second, a perfect communications medium does not exist. For this system, it is assumedthat a sufficient communication system can be built, with latencies, bandwidth, andmessage verification specification acceptable for this task. The dynamic nature of theplanning system will allow a certain degree of latency, though complete loss ofcommunication between robots will necessarily halt further coordination of the robots.Note that while this system is intended to run solely on the robots with no external hub,it is possible to move a large portion of the planning software off-vehicle, if anapplication demanded this type of architecture.

Results and insights 4.2

The preceding chapters have discussed in detail the design and implementation of agrammar for mission expression, plus the GRAMMPS Mission Planner which operateson this grammar. This section illustrates several runs within this framework.demonstrating the capabilities and advantages of mission planning.

Single Robot: Dynamic Path & Mission Planning 4.2.1

The first example is a single robot in a completely unknown environment usingGREASE as the simulation environment. The mission statement is example of the TSP:

Figure 4-1 shows four snapshots of this simulation. Snapshot 1 shows initial pathplanned for the robot, visiting goals A, D, C, and B in that order. The second snapshot(2) shows accumulated map information during the drive to Goal A. Note that missionplan is still the same (i.e. the goal ordering is the same), though the planned path haschanged to account for now-known obstacles. The dark areas are obstacle regions,

SoftwareArchitecture

Monolithic,synchronous,

planning latenciessimulatable.

Distributed,asynchronous

Distributed, asynchronous

Eqn. [4-1]

Table 4-1: Comparison of simulation environments & demonstration system

Category GUISE GREASE Demonstration System

M R1 GA GB GC GD∧ ∧ ∧,( )

Results from Simulation

65

while the light border around the obstacle area indicated an added “caution zone”, aspreviously described. Snapshot 3 shows that a change in the mission plan because thelatest perception information means that it is very expensive to continue with thecurrent mission plan. Therefore, the goals have been reordered to B, C, then D, insteadof D,C,B as was determined originally. Concluding this run is a snapshot showing allgoals reached.

This series demonstrates the advantages of dynamic path planning (optimization of pathto goal given current map information), and mission planning (optimization ordering ofgoals as path-costs change). Additionally, this series illustrates the integration of grid-based world representation with a nonholonomic robot.

Results from Simulation

66

Figure 4-1: Single robot TSP simulation

1.

2.

3.

4.

Results from Simulation

67

Two Robot Multi-goal Simulation 4.2.2

Figure 4-2 gives snapshots of a two-robot multi-goal simulation, given the followingmission statement:

Snapshot A shows the actual map of the world, though all obstacle regions are unknownto both robots at the start. Snapshot B shows the initial plan, with Robot 0 assignedGoals 1and 2, and Robot 1 assigned Goals 4 and 3. Snapshots C and D show Robot 0discovering a larger number of obstacles preventing it from reaching its goals easily. Toreduce the total cost of the mission, the goals are swapped and reordered, resulting inRobot 0 with Goals 4 and 3, and Robot 1 with Goals 2 and 1. Unfortunately, by snapshotE, Robot 0’s plight is fully clear, indicated the reassignment of Goal 3 to Robot 1. Notethat, for example, path for Robot 0 to Goal 4 uses map information provided by bothrobots. The final snapshot (F) shows this mission nearing completion, with both robotsreturning to Goal 5 as required by the mission statement.

This simulation demonstrates reordering of goals, exchange of goals between robots,and map sharing between robots, all yielding improved mission performance. Withoutdynamic path planning, mission replanning, and map sharing, the cost of this missionwould have been substantially higher; Robot 1 would have had to wait at Goal 5 forRobot 0 to complete a circuitous route to visit its original goals.

Eqn. [4-2]M R0 R1∨ G1 G2 G3 G4∧ ∧ ∧,( ) M R0 R1∧ G5,( )⇒

Results from Simulation

68

Figure 4-2: Two-robot multi-goal simulation

C. D.

B.A.

E. F.

Results from Simulation

69

Two robot collision avoidance simulation 4.2.3

Figure 4-3 shows a series of snapshots from a two-robot simulation, demonstrating anexample of stop-and-wait collision avoidance. The mission statement for thissimulation is:

Snapshot A shows the two robots heading for a collision. In snapshot B, Robot 1 hasstopped, allowing Robot 0 to pass by. Snapshots C and D show the conclusion of themission. This example demonstrates the effectiveness of stop-and-wait collisionavoidance for some circumstances.

Eqn. [4-3]

Figure 4-3: Two robot collision avoidance simulation

M R0 G0,( ) M R1 G1,( )∧

D.

B.A.

C.

Results from Simulation

70

Single-Robot Complex-Mission Simulation 4.2.4

Examples up until now have used GREASE, the more realistic of the two simulationenvironments. For this simulation, involving a much more complex map, GRIPE is usedto simplify execution of the mission. This mission involves a single robot given thefollowing mission statement:

This statement corresponds to a mission in which 4 goals (the ‘A’ Goals) have higherpriority that the ‘B’ goals, and therefore should all be visited first. Figure 4-4shows thesnapshots from this complex mission.

Eqn. [4-4]

Figure 4-4: Single-robot complex-mission simulation

R1 GA1 GA2 GA3 GA4∧ ∧ ∧,( ) M R1 GB1 GB2 GB3 GB4∧ ∧ ∧,( )⇒

A. B. C.

D. E. F.

G. H. I.

Results from Simulation

71

In snapshots A and B, the robot achieves its first goals without (much) difficulty. Thefuture plan of the robot in this simulation is not indicated by paths it intends to follow,but rather just by the order of goals it intends to visit. Difficulty in reaching one of theA goals has resulted in a new mission plan in which the order of A goals has changed.The sequence of B goals is almost the same, merely reversed from that chosenpreviously. In snapshot D, the robot has now visited all of the A goals, and is proceedingonto the B’s. Snapshots E and F show two changes in the goal the robot is to visit next.This occurs because it is continually thwarted trying to find a straightforward path toeither goal. G and H show another pair of next-goal changes. In snapshot I, the missionhas completed.

This simulation demonstrates both the extent to which mission replanning can benecessary in a sufficiently complex world, and the utility of GRAMMPS for operationin such environments.

Multi-robot Multi-Goal Simulation 4.2.5

GRAMMPS is intended to be applicable to a wide class of missions. The followingsnapshots (Figure 4-5) of a 4-robot 18-goal instance of the MTSP demonstrates thatlarge scale missions involving many robots and complex decisions between goal can beaccomplished with this system. Snapshot A shows the initial plan, while Snapshot Bshows the completed mission.

Importance of Mission Planning 4.2.6

The mission statement wassimulated using two different methods 1000 times for random environments similar tothe one shown in Figure 4-6. The grey obstacles are unknown to the robots while theblack diagonal obstacle is known in advance.

The two methods (static-planning and dynamic planning) differed in the way in whichmission planning was performed. For the static-planning method, the robots alwaystook the shortest path to goals but were unable to replan the mission once the initial plan

Figure 4-5: 4-robot 18-goal MTSP

A. B.

R1 R2 R3∨ ∨ G1 G2 G3 G4 G5∧ ∧ ∧ ∧,( ) M R1 R2 R3∨ ∨ G6,( )⇒

Results from Simulation

72

was given. The dynamic-planning method allowed the goals to be dynamicallyreassigned during the run. Dynamic mission planning completed the mission morequickly than a static planner over two-thirds of the time, and, on average, it improvedthe mission completion time relative to a static plan by approximately 25%. In morecomplex environments, or in situations when one robot may fail or become stuck,dynamic mission planning is even more essential as other robots must replace the failedone or else the mission will never be completed.

Results Summary 4.2.7

This section has demonstrated the effectiveness of the GRAMMPS Central Planner atcontinually optimizing the mission plan for a group of mobile robots in a complexunknown/partially-known environment. These capabilities arise through anunderstanding of the current expected cost to complete the mission, and by thesubsequent goal reallocation and reordering. Map sharing, inter-robot collisionavoidance, and graceful degradation of optimality via randomized search provideessential support for these capabilities. Additionally, the performance advantages ofdynamic mission planning is verified by comparison to static mission planning.

Observation of this type of multi-robot planning and cooperation has produced twoprimary insights. First, large scale structure is needed in the environment for theadvantages of mission planning to become apparent. If the operating environment ismerely a collection of small, independent obstacles, then the original mission plan islikely to be very close to the optimal mission plan, as robots will not deviatesubstantially from their initial path to necessitate mission replanning. Second, latenciesin mission planning (i.e. the time recompute the optimal plan given the informationknown at the beginning of the planning process) tend not to substantially affect the

Figure 4-6: Typical random environment for performance testing

Results from Simulation

73

overall improvement provided by mission planning until those latencies become largerelative to the time to execute the mission. These two observations together imply thatlarge missions involving many robots and goals are possible within this frameworkbecause time required to acquire perception information of large structures balances thetime required to replan for complex tasks, producing relatively small delays betweenthe time when plan-change is needed and when the change is actually computed.

Summary 4.3

• Two simulators are used to demonstrate and test the GCP and GRAMMPS. Thissimulators differ in terms of the fidelity of the simulation in areas of mobility,perception, and synchronous operation.

• Using this simulators, GRAMMPS is shown to support a wide variety of missions insignificantly complex environments. It effectively permits the cooperation of multiplemobile robots as allowed by the mission statement by permitting dynamic pathplanning, map sharing, goal reordering, goal reallocation, and inter-robot collisionavoidance.

• While this chapter has covered the simulation environments for GRAMMPS, real-world implementation of these concepts requires significant additional design andengineering effort. The next chapter will cover the required additions for and the resultsfrom the field testing of this system.

Results from Simulation

74

75

Chapter 5

Demonstration System

GRAMMPS was successfully demonstrated on two outdoor autonomous mobilerobots. Field testing was essential, as GRAMMPS is intended for use in field scenariosand many of the challenges in mobile robot systems only come to light when actual runsare performed. To discover and meet these challenges, the planning componentsdescribed in the previous chapter cannot exist in isolation or be tested solely insimulation. They must be coupled to real vehicles with all the complications foundtherein.

The success of the live demonstration required addressing a substantial number of real-world issues including position estimation, perception, obstacle avoidance,communication, etc. This chapter describes the architecture of the demonstrationsystem, the supporting component technologies, and the advances made to existingsubsystems to permit multi-robot operation. The chapter concludes with detaileddiscussion of a live run.

Architecture Overview 5.1

The twin demands of operation in unstructured environments and with multiple mobilerobots greatly affect the design of the system architecture. Operation in naturalenvironments implies unknown and partially-known terrain, which necessitates bothquick reaction to avoid just-seen hazards as well as deliberation to ensure optimalbehavior. The coordination of multiple mobile robots requires distributed computationto improve reliability and to communicate important information between the robots.The architecture chosen for GRAMMPS is intended to address those demands. Thissection introduces the architecture, outlining the nature and capabilities of eachcomponent as related to these demands.

Demonstration System

76

Demonstration System Block Diagram 5.1.1

Figure 5-1 shows a block diagram of the system as implemented on two vehicles. TheGRAMMPS Mission Planner (GCP) (described in Chapter 3) plus the User Interfaceconstitute the Mission Planning component. Both vehicles utilize a similar Mobilitycomponent, composed of a local navigator (i.e. an obstacle identification and avoidancemodule), a steering arbiter, and a vehicle controller. Both vehicles also have an identicalDistributed Planning component, each composed of path planning module and an inter-robot communications module. The shaded components represent the fundamentalcomponents of GRAMMPS; the remaining components are the essential mobilitycomponents required to support robust mobility in natural terrain. If operation withmore than two robots is desired, the Mobility and Distributed Planning componentsmay be duplicated on each robot, as required. Much of this chapter is devoted todiscussing the components shown in Figure 5-1. For clarity, each section begins withthe relevant portion of this diagram.

Mission Planning Components Overview 5.1.2

• Mission Planner: This is the GRAMMPS Central Planner described in Chapter 3.

• User Interface: The user interface is the mechanism for display of map, vehicles, andmission status. It is utilized for both simulated and live runs, communicating with themission planner and the Distributed Planning components.

Distributed Planning Components Overview 5.1.3

• Path Planners: These path planners receive goals from the GRAMMPS CentralPlanner. Map updates and robot locations are provided by the Intercom module(described below). Paths to goals are replanned efficiently with changing robotlocations and map information. The paths are used to guide the robots to their assignedgoals, and costs of these paths are returned to the GCP to permit mission replanning.

• Intercom: This module is the catch-all for all essentially distributed activity. It handlesmap sharing, inter-robot collision avoidance, and other tasks related to maintainingdistributed state.

Mobility Components Overview 5.1.4

• Local obstacle detection and avoidance: A robot operating in natural terrain mustreact quickly to perception information to prevent collision or damage to the robot. Thismodule receives perception information from the terrain sensor and couples it withposition information from the vehicle controller to build and maintain a local obstaclemap. Based on this map, speed and steering advice is provided to an arbiter, responsiblefor ultimately controlling the vehicle.

• Steering Arbiter: Given the conflicting demands of local obstacle avoidance and goalacquisition, this module determines the actual steering commands executed by thevehicle.

• Vehicle Controller: At the bottom level of the robotic system, this module isresponsible for connecting the software to the speed and steering actuators, as well asfor maintaining an ongoing estimate of vehicle position. As these activities have thestrongest real-time requirements, they are implemented on a separate set of processorsrunning a real-time OS, VxWorks.

Demonstration System

77

Architectural Issues 5.1.5

Each small box in Figure 5-1 corresponds to a separate process, rather than to a modulewithin a single program. The processes run on Sparc 5’s and 20’s on each vehicle, underSunOS 4.1.4. The advantage of this arrangement is that it facilitates easy transfer of lab-tested code into a field environment. Additionally, the operating environment performssome degree of load-balancing within each machine automatically. Difficulties arise inbalancing the load between machines, as it is unclear a priori which processes willconsume the most CPU. The solution for this system was to manually divide theprocesses among the available CPU’s until an acceptable arrangement was found.

Figure 5-1: Block diagram of demonstration system

Path Planners

Intercom

Local

Steering Arbiter

Vehicle Controller

path costs

goal

votes

map

raw map

positions

votes

votes

speed/steeringcommands

assignments

changes

data

goalassignments

votes,map changes

positions

Inter-robotCommunication

Rob

ot A

User Interface

obstacledetection

andavoidance

Mob

ility

Mis

sion

Pla

nnin

gMission Planner

Dis

trib

uted

Pla

nnin

g

Path Planners

Intercom

Local

Steering Arbiter

Vehicle Controller

path costs

votes

map

raw map

positions

votes

votes

speed/steeringcommands

changes

data

Rob

ot B

obstacledetection

andavoidance

Mob

ility

Dis

trib

uted

Pla

nnin

g

Demonstration System

78

Inter-process communication uses the IPT communications package[Gowdy95]. Thispermits a natural message-passing and Publish/Subscribe relationship betweenmodules. However, given that the OS can introduce unexpected latencies and thatsystem processes have limited inter-process communications buffers, it was possiblefor the system to slow unacceptably in some configurations. Redistributing processes toavoid this scenario was the usual approach, but this should be automated in futureimplementations. Alternatively, porting to a real-time OS would make it possible tobalance the load more precisely.

All processes operate asynchronously, implying that they cycle at a rate related to theshare of the CPU on which they run. Heuristic methods to avoid excessivecommunication and processing were used to avoid one process sending excessiveuninteresting information or performing unnecessary computation. For example, theIntercom module would not send position updates to the Path Planner faster than twiceper second (since the path planners could only keep up with 2Hz voting in any case),and the Arbiter would not compute new steering commands any faster than 5Hz (as thelocal navigator could only update its steering preferences at that rate). It is critical toensure that the arbiter and local obstacle avoidance modules always operate as quicklyas possible (in this case at 2-5Hz). Failure to do this risks mission success, as itintroduces the potential for collision, rather than just affecting mission performance.Hence this is the tightest constraint when evaluating system performance.

To summarize, while asynchronous operation allows each process to workindependently on its share of the computation at a rate appropriate for its task, the issuesof CPU and communications balancing (even within a single robot) necessitate carefuldesign decisions to ensure successful operation. In future work, a more preciseapproach to this meta-problem is recommended.

The Local Navigator 5.2

A strong requirement for any mobile robot is the ability to movesafely in its environment. This might not apply to a group ofnanorobots of insignificant unit cost, but for currently envisionedfield robotic applications, damage to the robot is an unacceptableeventuality. The likelihood and amount of damage a robot isexposed to depends on the operational environment. A robotoperating on a flat floor in a silicon wafer processing facility islikely exposed to little risk, as its environment is carefullycontrolled and monitored. A mail delivery robot operating in anoffice building is exposed to somewhat more risk, as stairs, amissing elevator, or malicious passerby could significantly damage it. An outdoor robotis exposed to similar risk, except that the environment lacks the implicit structure of atypical human-inhabited building. As indoors, any deviation from flat terrain ispotentially treacherous; but in an outdoor environment a much wider variety of hazardsexist, including rollover, high-centering, and sliding. This lack of structure significantlyincreases the complexity of the robot’s local navigation challenges. In addition, thegreater power required to move an offroad vehicle enables it to cause damage to itself

Local

raw map

votes

data

obstacledetection

andavoidance

positions

Demonstration System

79

much more readily. Typical indoor robots never acquire enough momentum to damagethemselves if they run into a wall, chair, or desk. For this discussion, local navigationrefers to the ability of the robot to move short distances (within its sensor horizon)without damaging itself. This is similar to the “wander” behavior found in morereactive architectures[Brooks85].

These constraints on robust, reliable local navigation imply that the performance of themission by the robot must come second to the moment-to-moment demands ofmaintaining robot safety. Therefore, the local navigator on the robot is tasked withmeasuring the environment, classifying the world as safe/unsafe (or occupied/empty),and evaluating the space of actions which the robot may undertake.

The demonstration environment for GRAMMPS is an industrial waste site (a slagheap), where by-products of the steel production process have been dumped fordecades. This terrain is largely barren, with piles of debris, areas of dense vegetation,gullies, extremely sharp dropoffs, puddles, slopes, and other natural features. It is quitepossible for an out-of-control robot to destroy itself by rolling over or tumbling down acliff. While this may be extreme for a robotics application1, it illustrates the demandsplaced on a local navigator and the accompanying perception system.

GRAMMPS only requires that the local navigator be able to provide map updates,move itself safely, and accept driving suggestions when possible. The demonstrationsystem utilizes SMARTY[Hebert94] for local navigation. Besides determining safedriving directions, it is responsible for determining the maximum safe vehicle speedgiven the current terrain. Two different terrain sensors are used: a new, high-speed laserrange-finder and a video-rate stereo machine on a pan-tilt head.

Rather than internally accepting driving advice, Smarty uses an external arbiter(Steering Arbiter, page 92) which accepts votes for 21 different turning radii between-7m and 7m. A vote of “1” indicates a totally safe arc, “0” is a minimally safe arc, anda negative vote indicates a “veto” -- an arc which should never be driven. In particular,steering choices are vetoed if they would lead the vehicle outside of the area currentlyvisible to the sensor. Figure 5-2 shows SMARTY in action, including the vehicle, thearcs to be evaluated, and a number of obstacles on both sides of the vehicle.

Terrain Sensors 5.2.1

Each vehicle is equipped with a different type of range sensor. This subsectiondescribes and compares the stereo and laser sensing systems.

A video-rate stereo machine with a three-camera system is used on the first robot forrange sensing. The machine generates 100x256 range images at up to 15Hz. A newimaging laser range-finder, used on the other robot, is capable of acquiring range dataup to 50m in a 360o by 30o swath [Froelich98][Hancock97]. Because of mechanicallimitations, the rotational speed of the scanner is set to a maximum of 2400Hz. As aresult, although a new laser design used in this sensor is capable of measuring points at500kHz, the acquisition rate was limited to two images per second for 60x1000 images.More recent, faster versions of the scanner are described in [Froelich98]. The stereo andlaser sensors are shown in Figure 5-3 and Figure 5-4, respectively.

1.Or, may not, e.g. Mars exploration

Demonstration System

80

Figure 5-2: The SMARTY local navigator

Figure 5-3: Trinocular vision system mounted on pan/tilt unit - two of the five visible cameras are not used

Figure 5-4: High speed scanning laser range-finder

Demonstration System

81

The two sensors have very different characteristics. In particular, the stereo system isfaster but has a narrow field of view (approximately 50o; this was extended somewhatby using a pan-tilt head), while the laser range-finder can sense all the way around thevehicle. In practice, each sensor has its strengths and weaknesses. The laser range-finder suffers from specular reflections off of water or other glossy surfaces, however,the ability to see to the sides of the vehicle greatly simplifies driving through narrowareas, as the vehicle does not “lurch” from side to side in the belief that a clear areamight be just out of the field of view. Without the pan unit on the stereo system, the fieldof view precluded any sharp turns and prevented effective operation in narrow areas.However, the stereo machine offered a higher useful data-rate than the laser range-finder, allowing slightly faster driving, as would be predicted by research into the natureof cross-country driving[Kelly97a][Kelly97b]. Additionally, the laser range-finder allowsnight operation. Figure 5-5 shows images from these sensors.

The use of these two very different sensors illustrates also the flexibility of thearchitecture. Both sensors used the obstacle detection and avoidance system describedin [Langer94a] and [Hebert94], each with a different sensor model. Thanks to the use of thebehavior-based approach, the change in sensor is limited to the obstacle detectionmodule, and the rest of the system remains identical on both vehicles.

Speed Control 5.2.2

Three sources contribute to vehicle speed control: mission directives may alter vehiclespeed, for example by stopping at goals; maximum speed may be limited depending onthe current steering radius in order to avoid tipover; and terrain complexity requiresspeed modification, i.e., the more cluttered the terrain, the lower the speed.

In the current implementation, speed-based mission directives are binary directives,that is, the vehicle is either stopped (at a goal or waiting for the other vehicle), or it isdriven at the speed commanded by the mobility system. Because of the low vehiclespeeds used in the experiments, adaptation of speed as a function of turning radius wasnot necessary. Hence, the source of speed control is the obstacle avoidance system,which operates on the principle that if the environment is cluttered, or, equivalently, ifthe steering votes have low values, then the speed should be reduced.

Figure 5-5: Sample stereo data (image + disparity map) and laser data (surface)

Demonstration System

82

In the current speed-control algorithm, the speed is the maximum desired speedmultiplied by a speed factor sO which is computed as: , where vmaxis the maximum steering vote in the current vote distribution, rmax is the proportion ofvotes that are close to vmax, and is a proportionality constant. This algorithm controlsspeed with the desired behavior, as illustrated by the three main cases shown in Figure5-6:

•If both vmax and rmax are large, the vehicle can maneuver over a wide range of arcs and,as a result, sO is close to 1 and the commanded speed is close to the maximum speed.

•If vmax is high but rmax is small, the vehicle has a clear path but it has less room tomaneuver and sO is decreased.

•If both vmax and rmax are small, the vehicle is driving in a cluttered environment andsO is decreased even further.

Finally, this approach to speed control forces the vehicle to stop if the environment istoo cluttered, i.e., vmax and rmax are too small, even if no steering arcs are actuallyvetoed.

Position Estimation 5.3

For local navigation tasks, position estimation is only requiredto support the ability of the vehicle to avoid collision withdangerous areas in environment. The requirements for absoluteposition accuracy are very loose, with a much higher premiumplaced on relative accuracy. This is because a local map of highquality is all that is necessary for local navigation. However, formultiple robots to share information, it is necessary for thisinformation to be in some common reference frame. For the demonstration system, adiscretized world map with 1m x 1m cells was used. A finer resolution allows a moreaccurate map, at the expense of significantly higher usage of computer memory andcommunications bandwidth.

The solution chosen for global positioning in this demonstration system is DifferentialGPS (DGPS). The DGPS system chosen (a Novatel RT-20) utilized carrier phasemeasurements to achieve nominal 20cm accuracy. Unfortunately, while the DGPSprovides excellent positional information (XYZ), its measurement of orientation (inparticular, vehicle heading) has an error which varies proportionally to the inverse

Figure 5-6: Speed adaptation: three examples

SO vmax α 1 rmax–( )–=

α

large vmax rmax

sO ~ 1

large vmax small rmax

sO < 1

small vmax rmax

sO << 1

local map

steeringvotes

Vehicle Controller

positions

speed/steeringcommands

Demonstration System

83

square of vehicle speed. Therefore, when the vehicle is stopped, heading information ismeaningless. Good heading information is necessary for placing information into themap, as a small error in heading can result in placing an observed obstacle into theincorrect cell. For example, the range sensors can detect obstacles up to 20m away,which, with a mere 3 degree heading error, produces a 1m error in the position of thatobstacle when it is placed in the global map.

In the demonstration system, the DGPS provides X, Y, and Z coordinates for bothrobots in UTM coordinates. Roll and pitch are provided by a Lear Astronics MIAGInertial Navigation System (INS), which merges ring laser gyros and inclinometers toprovide accurate high-frequency readings. An encoder on each vehicle’s drive shaft isused to provide an estimates of vehicle speed, which provides zero-velocity updates todamp out small motions (<20cm) of the vehicle due to DGPS position drift. DifferentialGPS corrections are provided to the onboard GPS via 9600 baud radio modems. The2watt transmitter used to transmit these corrections has a 1mile line-of-sight range, witha much longer range available using a 35watt amplifier.

The challenge comes in providing a usable signal for vehicle heading. The DGPS aloneonly provides this information when vehicle speed is sufficient. The MIAG INS has amagnetometer and a heading gyro about the Z axis. However, this system provedwholly insufficient for globally accurate heading information. Opening the rear door onthe vehicle was observed to cause a 10 degree drift in heading, as the internal filterslaves the absolute heading to the magnetometer’s heading over a short (<30 second)period. Furthermore, the magnetometer’s readings of a given marked known headingwere not repeatable, varying by several degrees between days. Instead of undertaking acomplex calibration method for this magnetometer/gyro combination, a Kalman filtermerging the DGPS with the heading gyro information is used in the demonstrationsystem. Additionally, the magnetometer is used to provide the initial heading fed to thefilter upon start-up, as the vehicle is typically stationary at this time. This filter weighsthe relative accuracy of the updates provided by the yaw-rate gyro and the absoluteheading provided by the DGPS, merging them to allow operation even at slow (< 1m/s)speeds. Additionally, the sign of the speed from the drive shaft encoder is used todetermine the direction of motion of the vehicle, as DGPS is unable to differentiatebetween driving forward at heading H, or driving in reverse at heading H+180 degrees.

While this arrangement is satisfactory for testing, it is necessary to carefully pickoperational environments in which GPS satellites are not occluded by tall vegetation orcliffs. A more adequate solution to this problem would involve a well-integratedINS/GPS system, designed to provide both relative and absolute position to sufficientaccuracy. The inertial system could be used to provide relative accuracy until the GPSsignal was regained. A discussion of the precise demands on position accuracy for localnavigation can be found in [Kelly97b].

Demonstration System

84

Dynamic Path Planning 5.4

Dynamic planning in GRAMMPS serves two purposes. First, itprovides path-cost information to the GRAMMPS MissionPlanner. Second, it provides driving advice to the localnavigator, indicating the current route to the goal. As theproblem of operation in unstructured environments necessitatesrapid replanning, a dynamic path planning approach is favoredover traditional one-shot motion-planning techniques. Thealgorithm used within GRAMMPS is known as Dynamic A* orD* [Stentz95a][Stentz94].

D* is a planning algorithm that produces an initial plan basedon known and assumed information, then incrementally revises the plan as newinformation is discovered about the world. The revised plan is guaranteed to be optimal(given the current knowledge) and is functionally equivalent to replanning from scratch.D* is fast because discrepancies are generally discovered by sensors carried on-boardthe robot and thus impact the portion of the plan “local” to the robot’s current state;therefore, most of the time only the near-term portion of the existing plan is affected.Additionally, regardless of where discrepancies in the map are found, only portions ofthe map directly affected by the change are modified.

The D* algorithm is sufficiently general that a variety of engineering decisions must bemade when implementing it for the purposes of GRAMMPS. In particular, it isnecessary to select a search methodology, a map representation and a costrepresentation. The manner in which steering votes are provided must also bedetermined. This section discusses these aspects of dynamic path planning with respectto D*.

Search Methodology 5.4.1

D* provides two different search methods: focussed[Stentz95a] and unfocused[Stentz94].An unfocused search is equivalent to a breadth-first search starting from the goallocation and working backwards, in such a way that all paths to the goal of cost N arecomputed before computing all paths of cost N+1, and so forth. Focussed search alsobegins at the goal state, but searches much like A*, with states on the open list sortedby the current estimated cost of solution from that state is , given by

, where is the cost of the shortest path from the goal to state xand is an estimate of the shortest path from state x to the vehicle. (unfocusedsearch is equivalent to setting for all x.) Examples of focussed and unfocusedsearches-in-progress are given in Figure 5-7 and Figure 5-8. The arrows in these figuresindicate the direction of the optimal path from that cell to the goal. The robot and goalare specified by “G” and “R”.

The advantage of focussed search is that it results in the exploration of fewer stateswhen generating the initial solution. On the other hand, the current implementationassumes a single vehicle rather than multiple vehicles, and the focussed expansion isalong a narrow corridor between the vehicle and the goal. This expansion pattern resultsin slow expansion into points near the robot, but not directly between the robot and thegoal. This occurs when trying to determine votes for steering directions (as discussed

Path Planners

path costs

goal

votes

map

assignments

changes

F'(x)

F ′ x( ) G x( ) H ′ x( )+= G x( )H ′ x( )

H ′ x( ) 0=

Demonstration System

85

shortly) when the vehicle is facing away from the goal. For these two reasons,unfocused D* is preferred over focussed D* for use with multiple robots in unstructuredenvironments.

Map Representation 5.4.2

The abstract D* algorithm expects a graph representation of the world. To simplifyutilization of perception information, and given the natural cartesian coordinatesprovided by GPS, an 8-connected tessellation of cells (i.e. a grid) is used for D* in this

Figure 5-7: Partially-complete unfocused D* expansion

Figure 5-8: Partially-complete focussed D* expansion

G

R

G

R

Demonstration System

86

application. However, it is not always possible at the beginning of a run to know the fullextent of the robots’ workspace. For this reason, a dynamic map representation is usedto allow worlds of (virtually) infinite extent instead of a fixed array which either limitsworld size, or requires substantial computation to allocate and copy information into alarger representation as needed at runtime.

The approach for the dynamic map uses a two level addressing system with unsignedinteger coordinates (i,j). (x,y) signed floating-point cartesian coordinates are imposedon top of the (i,j) system. The dynamic map is a collection of submaps of fixed size (upto , though this is practically limited by memory), which are only allocated asneeded. When a map cell is requested, if the submap which contains that cell does notexist, then it is allocated and stored in a hash table. This is illustrated in Figure 5-9. This

example shows a dynamic map with 4 currently allocated submaps, a 2.0m resolution,5x5 submap cells and an indicated origin. One dynamic map cell is highlighted, alongwith three methods of indexing this cell: (1) an (i,j) index into the entire structure, (2)an (x,y) index into the structure, and (3) the (i,j) coordinates of the cell within itssubmap plus the (i,j) coordinates of the submap in which that cell is located. Each ofthe submaps which are currently in use are stored in a hash table, each keyed by itsindex. Up to a virtual array of submaps can be indexed, though in practice avastly smaller number will be used. By specifying the origin of the coordinate systemas the middle of this virtual array, concerns about “running off of the map” arecompletely eliminated. Additionally, a reasonable overestimate of the number ofsubmap cells likely to be encountered defines the size of the hash table, avoidingexcessive memory usage for each map.

Figure 5-9: Dynamic map data structure

216

216×

Submap (0,1)

Dynamic map cell

Submap cell (1,2)

J

I

X

Y

(6,2) or (4.0, 26.0)

(0,1)

(2,1)

(1,1)

(2,2)

Hash Table(key)

(0.0, 0.0)

2.0m

10.0

20.0

30.0

10.0 20.0 30.0

216

216×

Demonstration System

87

Cost Representation 5.4.3

D* supports continuous (rather than binary or discrete) costs for state-to-state traversal.As this system uses an 8-connected grid representation of the graph, the traversal costbetween two cells is given by the sum of the costs of each cell (multiplied by fordiagonal moves). The cost of a path from a cell to the goal is the sum of all the cell-to-cell costs along the path.

For the problem addressed by GRAMMPS, 3 different cell costs are used. AnOBSTACLE cell is given a cost of 0x10000 (effectively “infinity”), and a FREE cell isgiven a cost of 5. All OBSTACLE cells are bordered by POTENTIAL cells of cost 25.This implies that paths consisting of more than ~210,000 cells are equivalent to a pathgoing through a single OBSTACLE cell. Therefore, with a 1m map resolution, paths arelimited to 210km, an relatively insignificant restriction. The POTENTIAL cells areintended to keep optimal paths from skirting too close to known obstacle regions,without causing the robot to divert its course excessively. Other implementations of thissystem have also utilized a priori costs for unseen cells, allowing initial mapinformation to be utilized. Alternatively, a fourth category of cells (UNSEEN), has alsobeen used and given a cost of 50, biasing the system towards known paths overunknown. The difficulty with either of these alternatives is that they significantly slowthe runtime speed of D*, as every single map cell seen causes a change in cost in thecorresponding cell inside D* (from UNSEEN to OBSTACLE, POTENTIAL, orFREE), causing substantial additional computation. For most unstructuredenvironments, an initial assumption of a FREE world is appropriate, as suchenvironments tend to be sparsely occupied.

Approximating Configuration Space 5.4.4

D* is designed to operate in a discretized configuration space of the robot, modeling thecost of transitioning from one state to another. Unfortunately, in a system using a cell-decomposition representation of the world, a physical vehicle can occupy more thanone cell at a time. Therefore, a path which lies near obstacle cells would cause thevehicle to collide with those obstacles, because the vehicle physically extends into theother cells. The solution chosen for this problem is similar to one first used in[Stetntz95b]. Every cell which is reported by the local navigator to contain an obstacle isgrown by half of the width of the vehicle. All of these cells marked as OBSTACLE arethen bounded a ring of POTENTIAL cells. For the demonstration system, anOBSTACLE radius of 1.5m (an overestimate of half the vehicle width) and aPOTENTIAL radius of 3m was used. Figure 5-10 shows an example of thisarrangement, with black cells indicating a cell of OBSTACLE cost, and grey cellsindicating a cell of POTENTIAL cost. An X in a cell indicates it is a cell reported as anobstacle by the local navigator. The vehicle is shown in two positions, where theobstacles were detected, and later driving between this narrow area. Note that thevehicle does not extend into any cell, indicating that it is travelling through freespace.

The limitation of this approach is that the orientation of the vehicle matters whentravelling through tightly constrained areas, as one orientation may not produce acollision when another will. In practice this is not a significant limitation, because theongoing interaction between the local navigator and the path planner prevents the robot

2

Demonstration System

88

from ever colliding with an obstacle. Additionally, it is possible in the worst case that aregion which the vehicle can actually just squeeze through will be marked as impassibleby obstacle cells. In this case, the local navigator may drive the vehicle through this areaas it is operating with a better understanding of the local state. This is as it should be,as the local navigator retains the competency in making local decisions. However, toprevent this supposedly-impassible region from being recorded in the map and sharedamong the robots, any area which a robot successfully drives over is marked as FREE.

Efficient Implementation 5.4.5

Carefully chosen data structures and a heuristic initialization procedure improve thepractical performance of D* for the target application.

D* maintains an open list similar to the open list in a standard A* search. To ensure thatD* is efficient in practice, it is important to select a data structure for the open list whichhas good performance. The original implementation of D* utilized a 2-3 tree [J. E.Hopcroft, 1970 unpublished]. To improve performance of D*, the 2-3 tree has beenreplaced with a Fibonacci heap[Cormen90]. This substitution approximately doubled thespeed of D* for typical problems.The following table indicates the relative performanceof these two algorithms:

Additionally, the knowledge that most test worlds begin with little or no a priori mapknowledge made possible a D* variant with a more rapid initial expansion of the datastructure. Examination of the standard D* expansion shown in Figure 5-11 indicatesthat there is a structure to costs and backpointers of each cell in the D* map. For an

Figure 5-10: Configuration space approximation

Table 5-1: D* Openlist Data Structure Performance Comparison

ProcedureFibonacci Heap

(amortized)2-3 Tree

Create Structure

Insert Node

Query Minimum

Extract Minimum

Decrease Node

Delete Node

cell with OBSTACLE cost

cell with POTENTIAL cost

cell with FREE cost

cell with OBSTACLE cost, actual perceived obst. location

Θ 1( ) Θ 1( )Θ 1( ) O lg n( )Θ 1( ) Θ 1( )

O lg n( ) O lg n( )Θ 1( ) O lg n( )Θ 1( ) O lg n( )

Demonstration System

89

empty map, it is possible to precompute this structure one cell at a time, rather thanperforming the standard computationally intensive expansion. A comparison of the twoinitial expansions is given in Figure 5-11. Also shown is a side-effect of this process:off-axis paths do not deviate as much from the actual straight-line path from a cell tothe goal, implying the vehicle may follow a path closer to the true-optimal straight linepath, rather than the resolution-optimal path caused by the 8-connected maprepresentation. This rapid-fill technique results in a factor of 20 improvement in systemstart-up speed.

Vote Generation 5.4.6

When a robot is assigned to drive to a goal which is handled by a particular D* search,in the framework chosen for this solution it is necessary to generate a vote vectorcomposed of one vote per steering angle which indicates the relative quality of each.Each steering angle corresponds to one arc which the vehicle might drive. These votesare scaled between 0 and 1. Unlike the local navigator (The Local Navigator, page 78),D* will never veto a steering choice, as the local navigator is presumed to have finaldetermination in arcs which cannot be driven.

To compute these votes, the number of arcs (N), the steering angle for each arc( ), andthe length of the arc (L) are fixed throughout the run. Three different approaches for

Figure 5-11: Comparison of D* initial expansions.

GG

Standard D* Expansion D* Rapidfill

Θi

Demonstration System

90

computing votes given these parameters were evaluated. Each method computes a rawvote for each of N arcs. The three methods are defined as follows:

where is the path-cost estimate to the goal provided by D* from the jth cell alongthe ith arc; is the number of cells along the ith arc, and is the length of thesegment of ith arc which intersects the jth cell along that arc. Additionally, for thepurposes of this calculation, any cell whose path-cost is greater than the cost of anOBSTACLE cell is assumed to have an infinite path-cost.

The end-point method suffers when OBSTACLE cells are located somewhere along thearc, as an arc which passes through an obstacle could receive a high vote. The cell-average method resolves this problem by checking all votes along the arc. However, thecells are all weighted identically, which causes problems when an arc just barelyintersects the corner of a cell, causing this cell to be weighted disproportionately. Thiscan make the for this arc to be slightly higher or lower than its neighboring arcs, eventhough, the arcs should actually be preferred in the opposite order. The solution to thisis the weighted-cell-average, which weights the contribution of each cell along the arcby the portion of the arc which actually passes through that cell. The resulting votes aregreatly smoothed and more accurately reflect actual driving preferences.

Before sending these votes to the arbiter, they are scaled between 0 and 1 to produce afinal vote vector , where the largest non-infinite ( ) is given a vote value of 0,the smallest ( ) is given 1, and intermediate values are linearly scaled withinthese bounds. Infinite ‘s are assigned a final vote of 0. This is more precisely definedas follows:

Interfacing to the GCP 5.4.7

The GRAMMPS Central Planner determines how many instances of D* exist when thesystem is running: one for each goal remaining in the mission statement. The costs used

Eqn. [5-1]

Eqn. [5-2]

V r i( )

End-point V r i( ) c i A i( ), 1–( )=

Cell-average V r i( ) c i j,( )A i( )

--------------i 0=

A 1–

∑=

Weighted-cell-average V r i( ) c i j,( )l i j,( )L

-----------------------------j 0=

A 1–

∑=

c i j,( )A i( ) l i j,( )

V r

V f V r V max

V r V min

V r

V f i( )

V r i( ) ∞=( ) 0

V r i( ) ∞<( )V max V min=

12---

V max V min≠V r i( ) V min–

V max V min–------------------------------

=

Demonstration System

91

by the GCP are the path-costs from D*, queried for every Robot-Goal and Goal-Goalpath possible in the mission. For example, if the mission statement is:

then there will be 5 D*’s initially, providing cost estimates for paths (from, to) (R1,G1),(R1,G2), (R1,G3), (G1,G2), (G1,G3), (G2,G3), (R2,G5), (G1,G6), (G2,G6),(G3,G6),(G5,G6). The reverse of the (Goal, Goal) paths need not be explicitly queriedas the cost of a path between two location is not direction-dependent.

It is reasonable to be concerned that those costs might actually be insufficient forcomputation of the mission plan. For example, perhaps the best way for Robot 1 to getto Goal 2 is via Goal 5, which is not queried in the example above. This is fortunatelynot the case, as all D*’s share the same map, and always provide the optimal pathbetween locations. This is equivalent to stating that the triangle inequality holds for thegoal and robot locations, where the “distance” between two locations A and B is thecost of the path connecting the two locations:

In other word, for every location A and C, there does not exist a location B for whichtravelling A to B to C is cheaper than travelling from A to C (on the paths given by C*).Therefore, the if the GCP has the cost for all possible Robot-Goal or Goal-Goal pathscontained in the mission statement, it is ensured to always be able to compute theoptimal solution for the mission.

As discussed in (GCP Analysis, page 44), the completeness, soundness and optimalityof the GCP depends substantially on the completeness, soundness and optimality of thepath planner used to provide costs to the GCP. The optimality of D* as used in thisapplication are clear: D* provides resolution-optimal paths to the goals given thecurrent knowledge of the world, except for the slight deviations caused by thePOTENTIAL cost cells added around obstacle regions, plus the deviations from thepath necessitated by the limited turning radius of the vehicle. Paths provided by D* aresound, except in the case where they imply the robot would need to drive through anarrow area oriented perpendicularly to the path through that region. In practice, this isnot an issue, as the local navigator will prevent the robot from getting into trouble.However, this does imply the path planned may be less expensive than the actual pathwhich needs to be navigated. D* is complete, i.e. if a path exists it will be found, exceptin the case where the obstructions cause a very narrow passage. In summary, while D*does not provide paths which are actually optimal, complete and sound, they are veryclose to being so, and in practice may be considered as such. The assumption of a“relatively open workspace” made in the Introduction directly addresses thisdeficiency: if the workspace is does not have any narrow passages, the system will beeffectively complete, sound, and optimal.

Summary 5.4.8

D* is chosen as the dynamic path planning algorithm for use within GRAMMPSbecause it delivers complete, optimal and sound paths in real time for targeted

Eqn. [5-3]

Eqn. [5-4]

M R1 G1 G2 G3∧ ∧,( ) M R2 G5,( )∧ M R1 R2∨ G6,( )⇒

AB

AB BC+ AC≥

Demonstration System

92

environments. To adapt D* for this application, issues of search methodology, maprepresentation, vote generation, the approximation of configuration space, and efficientimplementation have been carefully considered.

Steering Arbiter 5.5

The steering arbiter on each robot accepts votes asynchronouslyfrom both the local navigator and the appropriate path planner.The local navigator votes each time new sensor data is acquired(about 2Hz for the laser range-finder and 5Hz for the stereo visionsystem). The path planners provide votes at approximately 1Hz.21 votes are used, each corresponding to regularly spacedsteering angles between the minimum and maximum turningradii of -7m and 7m. New commands are sent to the vehicle at5Hz based on the most recent sets of votes from the obstacle avoidance and D*modules.

The votes are combined by the arbiter to generate a single driving command. Thisapproach to command-based arbitration is derived from the approach introduced in[Rosenblatt95]. A typical snapshot of the steering arbiter operation is shown in Figure 5-12. Arbitration results are for the Local Map shown at left. The votes from the obstacleavoidance module and D* are linearly combined into a single distribution. The weightfor D* is 8 times smaller than the weight for the obstacle avoidance module becausethe vehicle is in a cluttered area.

A long-standing issue with this approach is that a weighting scheme for combiningvotes between the two modules must be devised. Previous implementation of thisapproach used fixed weights, e.g., a large weight for local obstacle avoidance and asmaller weight for D*. The arbiter utilized for the GRAMMPS demonstration systemincorporates a new approach for weight adaptation based on the local obstacle map.Empirically, weight adaptation leads to tremendous improvements in performance byallowing the obstacle avoidance system to assume total control in cluttered regions andyield some control in less hazardous areas.

This implementation of the steering arbiter is similar to the one originally described in[Langer94b]. However, as indicated above, a critical difference is the ability to adjust the

Figure 5-12: Steering arbitration example

Steering Arbiter

positions

votesvotes

speed/steeringcommands

Obstacle D* CombinedLocal Map

Demonstration System

93

relative weights of voting modules depending on the environment. Specifically, thevotes are combined using a linear combination:

where & are the votes from D* and obstacle avoidance, respectively, and & are the weights. If the vehicle is in an obstacle-free area, then D* should have

control over the vehicle since the votes from the obstacle avoidance module do not carryany information except for the veto votes outside of the sensor’s field of view. On theother hand, if the vehicle is driving in a cluttered area, then the contribution of D*should be decreased, or even eliminated, in order to give control of the vehicle to theobstacle avoidance module.

The idea of dynamic weight adaptation originates in the more general concept ofadapting the driving behavior based on the environment, and shows similarities to thespeed adaptation algorithm described earlier (Speed Control, page 81). In fact, theweight adaptation algorithm used in these experiments is based on the speed factor, sOgenerated by the obstacle avoidance module. More precisely, the weights are defined as

, where f is a linearly decreasing function of sO between a non-zero minimumvalue for wO, to ensure some contribution of obstacle avoidance even if the speed isclose to the maximum speed, and a maximum value less than 1, to ensure that D*introduces a small amount of bias toward the goal even in cluttered environments, asshown in Figure 5-13.

Eqn. [5-5]

Figure 5-13: Weight adaptation example

vi wd*vid* wOvi

O+=

vid* vi

O wd*

wO

wO f sO( )=

wD* wO=0.9=0.1 wD* wO=0.66=0.33

sO

wO= f(sO)

1

01

wD* wO=0.4=0.6

Demonstration System

94

Distributed Operation 5.6

Intercom is the catch-all modulefor all system tasks which involvecommunications between thevehicles. While for thisimplementation a very reliablecommunication medium waschosen, future versions mayrequire increased robustness in thisarea. Localizing virtually all inter-robot communications to thismodule simplifies the transition to a different underlying communication infrastructure.This section discusses the capabilities of Intercom, including message passing, inter-robot collision avoidance, and map management.

Inter-robot Communications Analysis 5.6.1

Communication bandwidth between the robots is always a serious concern with multi-agent systems because of limited bandwidths of radio systems. These experiments useda FreeWave radio modem system, which has a peak bandwidth of 110 Kbaud andoperates in the 900Mhz spread-spectrum band.

The communication rate between the vehicles was recorded and analyzed. The vehiclesprimarily exchange vote distributions and obstacles map updates. Vote distributions areupdated at a maximum rate of 2Hz. The data rate for map updates can be measured inobstacle cells transmitted per second. The peak rate measured during the experimentswas 80 cells per second. This rate was observed in the most cluttered areas of the testsite. In those situations, the transmitted lists of obstacle cells are segmented into 50-cellpackets.

The aggregate volume of transmission is always below 4800 baud. No compressionalgorithm is used. Straightforward approaches to data compression can be designed toreduce the data rate by a factor of 4. In particular, the encoding of cell coordinates andvotes as floating-point numbers can be easily replaced by 1-byte encoding.

This analysis shows that this system design is suitable for use with low-bandwidthcommunication hardware.

Message Passing 5.6.2

Intercom takes responsibility for moving information as needed between robots. Somemessages are just passed through with few changes. First, each Intercom modulereceives map information from the vehicle controller running on its robot. It regularly(1Hz) publishes this information to all other Intercom modules. In this way, eachIntercom module collects position information from all other Intercoms, and canprovide this information to the path planners & user interface. Second, each Intercomreceives votes from the path planners located on its robot. If these votes are needed toguide the robot on which Intercom is located, they are passed to the Steering Arbiter;otherwise they are forwarded without delay to appropriate robot’s Intercom module.

Intercom

votes

map

votes

changes

votes,map changes

positions

Inter-robotComms.

Intercom

votes

mapchanges

raw map

positions

data

votesraw map

positions

data

Demonstration System

95

Inter-robot Collision Avoidance 5.6.3

As Intercom has the most up-to-date information about vehicle position and has directaccess to the steering arbiter, it is natural for it to manage inter-robot collision avoidanceissues. The problem addressed by GRAMMPS assumes a relatively open operationalworkspace which greatly simplifies the problem of avoiding collisions. Additionally,substantial prior work exists in this area ([Causse95], [Arai96], [Li94], [Alami95]), and couldbe incorporated into this module should an application demand greater performance.

A fixed-priority stop-and-wait heuristic is used by Intercom to resolve collisions. If arobot of higher priority comes within terrain sensor range of a lower priority one, thenthe lower priority robot stops until the other robot leaves the area, unless the latter is nolonger involved in the mission. In that case, the lower priority robot is allowed tocontinue moving. In any case, the stopped robot is treated as an obstacle by the pathplanners, avoiding actual collisions. Once the danger is past, the area under the stoppedrobot is cleared of any obstacle cells that may have been added when the moving robotsensed the stopped robot. Additionally, the stopped robot ignores perceptioninformation while it is stopped. This prevents it from perceiving the moving obstacleand marking the map cells under the moving robot as obstacles.

Map Management 5.6.4

Each Intercom receives map information from the local navigator running on the samerobot. The Intercom module reduces the resolution of this information (if needed),performs the configuration space approximation (Approximating Configuration Space,page 87), adds POTENTIAL cells (Cost Representation, page 87), determines whichmap cells have changed cost, and then broadcasts map changes to all other Intercommodules for inclusion in their world maps.

Reducing the resolution of map information is helpful for two reasons. First, the localnavigator may use a high-resolution map of the environment rather than a lowerresolution appropriate for path planning. For a grid-based world representation, a factorof 2 reduction in resolution results in a factor of 4 reduction in planning time; a valuabletrade-off. Alternatively (though it was not the case for the demonstration systemdescribed here), the local navigators on the robots may use different map resolutions.Therefore, a conversion to a standard resolution (the one used for planning) simplifiesmap sharing.

The local navigator on each robot does not keep track of whether or not it has viewed aparticular patch of terrain earlier in a run. Therefore, it may send duplicate informationto Intercom when a previously-viewed patch of terrain is seen again. Rather than re-broadcast every piece of map information received from the local navigator, Intercombroadcasts only map changes. This greatly reduces the inter-robot communicationsbandwidth utilized for map updates. Additionally, it avoids placing an additional burdenon the D* path planners by only informing them of changed costs.

The flow of map information through Intercom is shown in Figure 5-14. Intercomeffectively maintains two maps of the environment. The first, called the “OccupancyMap” is the reduced-resolution map which records perception information, whereby acell in this map is either an OCCUPIED or EMPTY cell. The second map, called the

Demonstration System

96

“Cost Map”, contains cells which are either marked as OBSTACLE, POTENTIAL, orFREE, relating specifically to the traversal cost of the cell as described earlier.

Intercom first takes map information from the Local Navigator, and computes thereduced-resolution changes in Occupancy Map caused by this batch of information.This process is shown in Figure 5-152. The resulting changes to the Occupancy Map aresent to other Intercom modules on other robots, as was shown in Figure 5-1 (page 77).

The next step performed by Intercom is to reflect these Occupancy Map changes intothe Cost Map. Intercom processes Occupancy Map changes independently of whetherthey are received from the robot on which Intercom is running, or from anotherIntercom module on another robot. To compute the approximate configuration space,(Approximating Configuration Space, page 87) every obstacle cell within “obstacleradius” (typically half the vehicle’s width) of an obstacle is considered to haveOBSTACLE cost. Every cell around that region within “potential radius” isconsidered to have POTENTIAL cost. To perform this computation a convolutionoperation is performed in the Cost Map for each changed cell detected in the OccupancyMap. Each cell in the Cost Map contains two counters and , indicating how manyactual obstacle cells are within and how many are within . A cell is considered tohave OBSTACLE cost if . A cell is considered to have POTENTIAL cost if

and A cell has FREE cost if and . These concepts areillustrated in Figure 5-16. This example is for a particular , , and map resolution.The convolution operator could contains many more cells when the map cell size issmall relative to and .

A change from EMPTY to OCCUPIED of a cell in the Occupancy Map indicates thata convolution should be performed at the corresponding cell in the Cost Map. A changeof a cell from OCCUPIED to EMPTY indicates that a similar convolution should beperformed, but this time, subtracting from those counters instead of adding. Anexample of this process for the changes generated in Figure 5-15 is shown in Figure 5-17.

2.Only integer resolution reductions are supported in this implementation.

Figure 5-14: Map information data flow

Map Informationfrom Local Navigator

Compute changes inOccupancy Map

Compute changes inCost Map

Occupancy Map ChangesFROM other Intercom

Occupancy Map changesTO other Intercom

Cost Map ChangesTO Path Planners

Reduce Resolution & Approximate C-space &

RO

RP

CO CP

RO RP

CO 0>CO 0= CP 0> CO 0= CP 0=

RO RP

RO RP

Demonstration System

97

In the process of reflecting changes in the Occupancy Map via convolution as changesthe Cost Map, a list is made of all cells in the Cost Map touched during this process. Byexamining this list when the process is finished, and comparing the final values of thecounters and to the original values, a list of Cost Map cells which have changedis generated. This list is sent to the path planners so the cell-to-cell traversal costs canbe appropriately updated, reflecting the latest map information.

This process is efficient because typically Occupancy Map changes occur in verylocalized batches where a sensor has observed new information. When an entire groupof convolutions is performed given all the changes to the Occupancy Map, the countersof many cells in the Cost Map are changed. However, only a few cells change regions,i.e. going from OBSTACLE to FREE, or POTENTIAL to OBSTACLE, and so on.Since only these changes are sent on to other modules, the amount of data transmittedis minimized.

Figure 5-15: Computation of changes to the obstacle map

Figure 5-16: Convolution operator used to approximate configuration space

Initial Occupancy Map

Information fromLocal Navigator

New Occupancy Map Occupancy Map Changes

- =

High resolution empty cell

High resolution occupied cell

Low resolution (1/2 high resolution) cell

00

00

01

00

00

00

01

10

01

00

01

10

10

10

01

00

01

10

01

00

00

00

01

00

00

21

# of cells w/in Potential Radius

# of cells w/in Obstacle Radius

cell with OBSTACLE cost

cell with POTENTIAL cost

cell with FREE cost

Occupancy-to-CostConvolution Operator

DiscretizedRegions of OBSTACLE & POTENTIAL cost around

an obstacle

potential radius

obstacle radius

CO CP

Demonstration System

98

Field Trials 5.7

Background 5.7.1

All the components in thischapter are used together tosupport field trials of GRAMMPSon two outdoor mobile robots.The figure to the right shows theoverview of the software systemas deployed on the two robots.The local navigators, steeringarbiters, and vehicle controllercan be considered the coremobility elements of thedemonstration system duplicatedon each robot except foradjustments for the perceptionsystem. Identical DistributedPlanning components composedof Intercom for inter-vehiclecommunications and D* for dynamic path planning are used on each vehicle. Operatingon only one of the vehicles is the Mission Planner (the GCP described in Chapter 3) anda graphical user interface which allows the operator to monitor system progress. Theseare located on an arbitrarily chosen robot, but could just as easily be located at a remotebase station, or on the other robot.

The two-vehicle system was exercised in the field over a period of one month. Prior tothis however, more than a year was spent hardening positioning, map sharing, andobstacle avoidance, as well as improving pan-tilt control of the stereo sensor,integrating the radio modems, adding the laser range-finder, integrating GPS

Figure 5-17: Changing the Cost Map via a convolution operator

Initial Cost Map0

00

00

00

1

01

00

10

02

00

00

00

00

01

10

00

02

11

20

20

11

02

00

10

01

00

00

00

00

02

10

00

01

01

00

00

00

00

00

00

00

00

01

01

10

00

00

01

00

00

01

01

10

21

21

20

30

11

01

11

01

00

01

00

00

12

12

01

01

01

00

00

00

New Cost Map Cost Map Changes

Obstacle Map Changes

- =

the convolution operator is applied 3 times

path

goalassignments

goalassignments

Robot A Robot B

User Interface

path costs

Mobility Mobility

Mission Planning

Mission Planner

votes,map changes

positions

Inter-robotComms.Distributed Distributed

PlanningPlanning

positionsmap

votes

changes positionsmap

votes

changes

costs

Demonstration System

99

positioning into the vehicle controller, and so forth. The demonstration system involvedresearch code from at least a dozen contributors. The total code produced forGRAMMPS alone was approximately 25,000 lines of C and 7,000 lines of Python[Lutz96].

Approximately a year of effort was put into preparing the vehicle and infrastructure forfield trials. The addition of a differential GPS system was driven by the need for bothvehicles to share a common coordinate frame. The integrated INS/GPS systemsprovided by Lear Astronics for both vehicles proved unworkable, though ongoingefforts were made over a two+ year period to successfully integrate them into thesystem. The addition of these components required upgrading of the controllerhardware to support the additional data input lines, as the existing processors did nothave sufficient serial ports. An additional processor was also needed to handle the high-speed I/O from the INS/GPS. Software drivers also had to be written for the DifferentialGPS and INS. The perception systems on both vehicles were prototypes with all thecomplications associated therewith. Both required regular attention and maintenanceby appropriate staff. The existing primary computing in the vehicles was insufficient tohandle the extra I/O and processing load imposed by inter-vehicle communicationrequirements, thus it was necessary to add extra Sun workstations to each vehicle. TheSun workstations’ implementations of PPP were also problematic requiring addition oftwo small Linux laptops to handle the PPP connection. The addition of all this hardwareput a substantial load on the vehicle’s power system, resulting in regular (monthly)burnouts of the shore/on-board power switching relays and the eventual demise of agenerator. During the summer months, the cooling system became a critical piece ofhardware as the outdoor temperature regularly reached 90+ degrees F, 90%+ relativehumidity. Accidentally cracking the door to the “cool cage” could result in massivecondensation all over the computing boards in that cage; to this end several boards werereplaced over their several-year lifetime. Adding a single cable to the cold cage requiredhours of work to route behind the boards, through the gaskets sealing the cage, etc. Theoperational environment was very dusty, was doubtless caused several hardwarefailures.

Operating outdoors is also a substantial challenge. Significant rain or snow prohibitedoperation both when it occurred and during the days afterwards when the ground wouldbe too waterlogged and muddy to allow work to continue. Puddles caused problems forthe perception systems, and mud challenged the throttle and steering controller. Icecauses specular reflections which causes inaccurate perception data. Bright sunlight onthe horizon causes difficulties for the stereo vision systems, and operation at night is notan option. The heating and cooling capabilities on the vehicles was limited, requiringsignificant preparation to ensure that work could be completed on-site; it is very hardto debug code when one’s fingers are frozen or when perspiring heavily. Both vehiclesused diesel fuel, a fuel-type not commonly carried in the Pittsburgh area. A typical dayof operation began with 15 minutes of vehicle checkout in the lab, followed by another15 minutes to drive the vehicles out, start the generators, verify equipment function, andloading of goal markers, GPS equipment, etc. Driving to the test site took about 30minutes. Another hour is needed to set up the differential GPS, initialize the vehiclecontrollers, start up the sensing systems, warm-up the INS, run all the software,

Demonstration System

100

establish the radio link, set up the goals, designate the mission, coordinate drivers, andfinally get started with operation. Once completed for the day, a 20 minute drive to thegas station was needed to refuel the vehicles and generators, followed by 15 minutesback to the lab, and another 15 minutes to back-in, hook-up, and otherwise park thevehicles. This totals nearly 3 hours of overhead for any given day of operation.Forgetting a single cable, or neglecting to plug in rechargeable batteries could add anhour of wasted time to a day. Carrying a toolbox, flashlight, spare parts, etc. becameessential to avoid 1-2 hours of downtime for repairs. Of course, besides schedulingbased on the weather and personnel availability, the vehicles and sensors were used bymultiple people for several purposes and regular maintenance on both was required.

The complexity and difficulty of performing real multi-robot experiments in the fieldshould not be underestimated. The demonstration system for GRAMMPS representedan enormous amalgamation of components, including power generation, powerdistribution, and air conditioning systems; a half-dozen motors/amplifiers/PID-controllers, DGPS, INS, radio communications, radio ethernet, pan/tilt controllers,custom computing hardware, real-time operating systems, not to mention twomaintenance-intensive HMMWVs. A failure in virtually any one of these componentson either vehicle required stopping the experiment to rectify the problem. Thecomplexity of system interaction and dependencies made operation of this system asubstantial challenge. Anything from electric noise from the fan affecting encoderreadings, to video transmission disturbing radio communications, or even raindrops onthe cameras could cause an experimental run to come to a halt. Even communicatingbetween researchers was a problem; the heavy EMF from all the radios and electronicsprohibited the use of handheld radios, and a hefty cellular phone bill resulted as theywere the most reliable way of talking back-and-forth between the vehicles.

This section should serve to illustrate the amount of effort required to test even a singlealgorithm on a full robot system. Fundamentally, making any one component functionalrequires a significant amount of time; maintaining a dozen such components allfunction on a pair of vehicles at the same time was nigh-impossible. Before undertakingsuch an effort, it is essential to secure the support of dedicated software, hardware,electronic, mechanical and administrative team. Until such a time as the principalcomponents (both software and hardware) reach a much higher level of maturity,substantial effort and dedication will be required to field-test any new ideas for robotcontrol, cooperative behaviors, or autonomous navigation in an outdoor unstructuredenvironment.

User Interface 5.7.2

The GUI developed for use with GRAMMPS, called Porch, allowed a uniformenvironment to be used for simulation and for live runs. Systematically, as realhardware and/or software modules became stable, they were substituted for thesimulated version enclosed in the GUI. This allowed independent testing of thesoftware in simulation before moving to the real vehicle. Porch supports a vast array ofactivities related to developing and testing a multi-robot system, including:

• creation and display of obstacle maps with known and unknown obstacle regions• creation and placement of robots and goals

Demonstration System

101

• logging and playback of live and simulated runs• multiple robot shapes• run-time display of vehicle positions, orientations, paths, plans, and trails• full display manipulation including zooming and scrolling,• simulation of robot movement, voting, and perception• a variety of debugging messages to support testing and problem diagnosis.

An screen shot of Porch with the log-playback window and the arbiter display is shownin Figure 5-18. While less significant from a research standpoint, this comprehensive

debugging, display and analysis tool was essential for the construction, testing anddemonstration of GRAMMPS.

A Live Run 5.7.3

Twelve complete live missions, i.e., missions in which the vehicles visited all the goalsspecified in the mission description, were recorded and analyzed in detail. Each missioninvolved each vehicle driving up to 800 meters and visiting up to nine goals. The

Figure 5-18: Example GUI display

Demonstration System

102

average speed was 1 m/s in all the missions, though some patches of more complexterrain were typically driven more slowly. The robots used for these field trials areshown in Figure 5-19.

The remainder of this section describes in detail a single field trial. The examplemission consists of eight goals. The mission description provided by the user is, in thiscase, a mix of mandatory orders, i.e., specific goals that must be visited by each vehicle,and optional orders, i.e., goals which can be visited in any order and by any vehicle asdecided by the run-time system. In order to facilitate the description of the mission,each goal is designated by a name, written in UPPERCASE.) In this example, the robotsHMMWV2 and HMMWV1 are instructed to visit goals INTER and EDGE3,respectively; the remaining goals may be visited in any order, with both vehiclesfinishing at EXEUNT. In the mission grammar, this was expressed as:

During this experiment, HMMWV1 and HMMWV2 travelled 670m and 683m,respectively. A total of 592 OBSTACLE cells were added to the Obstacle Map, along

Figure 5-19: Robots used in GRAMMPS demonstration system

Eqn. [5-6]

Navlab 2(Stereo vision)

Navlab 4(Laser range-finder)

M R1 GEDGF3,( ) M R2 GINTER,( )∧M R1 R2∨ GPIPE GCIST GL-ROAD GC1 GC2 G∧ ∧

CENTER∧ ∧ ∧,( )

M R1 R2∧ GEXEUNT,( )

⇒⇒

Demonstration System

103

with an additional 1500 POTENTIAL cells. The run took a total of 16 minutes.HMMWV1’s average speed was approximately 1.0m/s, while HMMWV2 droveslightly slower at 0.8m/s.

The approximate locations of six of the goals are shown in Figure 5-20 overlaid on apanoramic image of the test area. The final goal location EXEUNT is slightly outsideof this image to the right. HMMWV2 starts on a narrow path as shown in Figure 5-20.HMMWV1’s start position is close to the final goal EXEUNT.

In order to show the major stages of this mission, displays obtained by replaying thedata recorded during the run are shown in sequence below. A short paragraph isincluded after each snapshot to explain the details of the corresponding missionsegment. In all those displays, HMMWV1’s path and vehicle icon are drawn usingshaded lines, while HMMWV2’s are drawn using black lines. Two types of paths aredrawn. The path behind the vehicle is the path actually driven by the vehicle undercombined control of D* and local obstacle avoidance; the path ahead of the vehicle isthe best path planned by D* given the current obstacle map.

The OBSTACLE cells are shown as grey squares and the goal locations are indicatedby their names. For clarity, the POTENTIAL cells are omitted from these images. Theobstacle and vehicle coordinates shown in the displays are computed by mappingdirectly GPS coordinates to screen coordinates. Each snapshot also shows the currentmission statement, pruned appropriately to reflect the accomplished goals.

Reflections from the Field 5.7.4

Through the extensive testing of GRAMMPS in a field scenario, its efficacy for fieldscenarios has been demonstrated. This may be the most complex multi-robot systemever demonstrated in an unstructured environment. The difficulty of performing fieldtrials was exceptional, as the system relied on such a wide variety of non-production-level hardware and software. During the month of trials, virtually every componentfailed at some point or another, requiring repair or replacement. While part of this is dueto the aging hardware platforms (the core mechanism, computing, power, and controlsystems were installed 5+ years previously), the sheer number of systems in use waslargely responsible.

Figure 5-20: Test site & actual goal locations for sample live run

EDGE3L-ROAD CENTERINTERCISTPIPE

EXEUNT

HMMWV2 START

Demonstration System

104

Figure 5-21: Live Run: Snapshot 1, Initial configuration

Figure 5-22: Live Run: Snapshot 2, Mission start

Initial Configuration: Obstacles are known only in the immediate neighborhood of the vehicles at theirstarting positions. HMMWV2 plans its route from the starting location to the first goal, INTER, which is imposedby the mission statement, through two intermediate goals, ending at the final goal, EXEUNT. Similarly,HMMWV1’s plan goes first to the mandatory goal EDGE3 and to four intermediate goals before going toEXEUNT. GRAMMPS generates the allocation of goals between the two vehicles.

M R1 GEDGE3,( ) M R2 GINTER,( )∧( )M R1 R2∨ GPIPE GCIST GL-ROAD GC1 GC2 G∧ ∧

CENTER∧ ∧ ∧,( )

M R1 R2∧ GEXEUNT,( )

⇒⇒

Mission start: HMMWV2 starts driving first, modifying its route based on the obstacle map accumulated sincethe start of the mission. At the same time, although it is not moving, HMMWV1 is updating its planned route,taking into account the map changes reported by HMMWV2. Specifically, the path to EDGE3 has now changedto avoid the new obstacles found by the laser system on HMMWV2

M R1 GEDGE3,( ) M R2 GINTER,( )∧( )M R1 R2∨ GPIPE GCIST GL-ROAD GC1 GC2 G∧ ∧

CENTER∧ ∧ ∧,( )

M R1 R2∧ GEXEUNT,( )

⇒⇒

Demonstration System

105

Figure 5-23: Live Run: Snapshot 3, Change in goal allocation

Figure 5-24: Live Run: Snapshot 4, Change in goal ordering

Change in goal allocation: Shortly after HMMWV2 reaches goal INTER, GRAMMPS decides that goalL-ROAD should be switched to HMMWV2’s plan. This event occurs because newly detected obstacles just pastINTER forced HMMWV2 to move closer to L-ROAD than originally expected. As the goal switching eventoccurs, the routes are immediately recomputed, leading to seamless transition between goal distributions.

M R1 GEDGE3,( )M R1 R2∨ GPIPE GCIST GL-ROAD GC1 GC2 G∧ ∧

CENTER∧ ∧ ∧,( )

M R1 R2∧ GEXEUNT,( )

⇒⇒

Change in goal ordering: Due to several detected obstacles, HMMWV2 is deflected from its path on itsway to L-ROAD, resulting in a longer-than-expected traverse. To keep the expected mission execution timeminimized, he planner re-allocates goal CENTER to HMMWV2. As a result of this event, the ordering of goalsfor HMMWV1 is also changed; the plan now calls for C2 to be visited before C1.

M R1 R2∨ GPIPE GCIST GC1 GC2 G∧ ∧CENTER

∧ ∧,( )M R1 R2∧ GEXEUNT,( )

⇒

Demonstration System

106

Figure 5-25: Live Run: Snapshot 5, Correction

Figure 5-26: Live Run: Snapshot 6, Driving back

Correction: The planner has reverted to its previous decision and restored the original goal allocation. At thesame time, the ordering of goals for HMMWV1 has also been restored, as expected. This avoids unnecessarybacktracking by HMMWV1 while driving to CENTER.

M R1 R2∨ GPIPE GCIST GC2 G∧CENTER

∧ ∧,( )M R1 R2∧ GEXEUNT,( )

⇒

riving back: Although it occupies a very cluttered area, HMMWV2 executes a path that leads it out of therea around L-ROAD (the edge of a forest.) This path is executed through the steering arbiter by combining thelobal optimal path to CIST and the local steering commands for obstacle avoidance. Because the speed arbitereduced its speed in this area, HMMWV2 has just reached its penultimate goal, PIPE, while HMMWV1 isompleting the mission. The route uses all the information accumulated since the beginning of the mission. Forxample, the path from PIPE to EXEUNT computed by D* uses the portion of the obstacle map constructed at theery beginning of the mission.

M R1 R2∧ GEXEUNT,( )

Demonstration System

107

The following is a partial list of problems which occurred in the final week of testingexcluding normal system software problems. This is not intended to present a pictureof bad engineering, or poor design, but rather to illustrate the scope of problems one canexperience with large-scale robotic systems.

•slow logins due to NFS/Authentication configuration problems•speed control difficulties due to hardware upgrade•failure of a brake actuator•unexplained problems with Inter-process communications package, resolved via frequent reboots•GPS signal loss near dense vegetation•magnetic power switch on generator failed•power relays on generator failed•generator magnetos failed, necessitating generator replacement•flaky ethernet due to faulty termination resistor•hard drive corruption on PPP server for inter-robot communication•insufficient power with all systems on - removed old unused boards•drive shaft encoder torn off when snagged on branch while under human control•trouble mounting file system on newly-added computer•drifting steering calibration•generator battery needed to be replaced•pan control unit died - swapped with tilt controller•GPS power cable broke - bad junction

These runs exercised the perception and obstacle avoidance systems substantially,performing tens of kilometers of autonomous driving. The difficulties with perception

Figure 5-27: Live Run: Snapshot 7, Mission completed

Mission completed: Both HMMWVs complete the mission. The paths ended up being substantially differentfrom those computed at the beginning of the mission. The paths shown here are optimal based on the informationavailable at the time they were generated. Were these runs to be performed again, given the complete obstacle mapshown above, the initial paths and goal ordering would be globally optimal and, therefore, very different from theones shown above. For example, the map constructed between L-ROAD, INTER and CIST would prevent futuremission from wasting time trying to cross directly from L-ROAD to CIST as HMMWV2’s initial planrecommended. Instead, using this map, a planner would now generate the correct behavior, that is, the vehiclewould follow the tree line between L-ROAD and CIST.

Demonstration System

108

are perhaps the most difficult. A single false positive (imaginary OBSTACLE) cancause the vehicle to come to a halt, a single false negative can cause the operator to abortthe run. The terrain perception system observes and evaluate thousands of terrainpatches every second; even a 99.99% success rate implies a mistake every 10 secondsof driving. Additionally, the perception systems on these vehicles are unable to handleeven moderate vegetation. High grass proves to be one of the most common, yet mostdifficult to resolve, difficulties encountered by outdoor autonomous vehicles. Thesolution currently is to either adjust the obstacle threshold to miss small obstacles andrisk collision with small (but unsafe) objects, or to avoid tall vegetation altogether. Thesolutions to these problems are not clear, but the addition of redundant sensors whichmight be used to see through vegetation and thus observe the terrain directly in front ofthe vehicle, would be a substantial help. System performance would also be improvedby the addition of proprioception, which can detect excessive speed on rough terrain orimpending unsafe configurations (e.g. tipping) and rapidly adjust vehicle behavior.

Overall, the problems facing fieldable cooperative robotic systems in outdoor terrainare a result of the incredible complexity of the hardware and software systems, plus thereliance on a single terrain-perception modality which is ill-suited for a non-negligiblesubset of the problems which are likely to be encountered.

Summary 5.8

• Operation on multiple robots demands a distributed architecture. While the missionplanner runs as a central process, the other processes run independently, allowing eachrobot the ability to react quickly, avoiding latencies in time-critical computation suchas obstacle avoidance and steering arbitration. An identical mobility element runs oneach robot, permitting straightforward addition of new robots to a robot team.

• GRAMMPS relies on an effective local-navigation component on each robot whichretains responsibility for the moment-to-moment tasks of keeping the robot safe. Thiscomponent also provides obstacle information to the path planners, and accepts adviceon how to reach a goal. Steering arbitration resolves the conflicting demands of obstacleavoidance and goal acquisition. Both laser range sensing and stereo vision were utilizedin the field trials, demonstrating the ability of GRAMMPS to support multiple sensors.

• GRAMMPS uses the D* algorithm for dynamic path planning. This component isresponsible for computing optimal paths to goals and providing steering advice for arobot trying to reach a goal. To attain robust efficient performance, substantialengineering of the D* algorithm was required. Specifically, cost representation, maprepresentation, and vote generation were tailored to suit GRAMMPS.

• Communication between robots, excluding goal assignments from the central planner,is provided by a single module on each robot, simplifying any future change in themechanism for inter-robot communications. This module also coordinates inter-robotcollision detection, map sharing, and position sharing.

• GRAMMPS has been tested on two outdoor autonomous vehicles, demonstrating theeffectiveness and utility of this system for efficient autonomous operation of inunstructured environments.

109

Chapter 6

Conclusion

This chapter provides a summary of this work, what it means, and where it might lead.Specifically, a summary is given of the contributions, accomplishments, insights, andfuture directions that have resulted from this investigation of general mission planningfor multiple mobile robots in unstructured environments.

Contributions 6.1

The purpose of this research has been to demonstrate and validate a general system ofmission planning for cooperative mobile robots in unstructured environments. In thecourse of this pursuit, there have been 5 principal contributions:

• The field trials of this system demonstrated the most complex and capable cooperativemobile robotic system to date working successfully in an unstructured environment.Two full-scale outdoor mobile robots executed dozens of missions, each involving akilometer or more of autonomous driving. Map- and position- sharing enabled missionplanning, allowing these robots to optimize mission execution, for robust mission-oriented performance.

• The GRAMMPS mission grammar provides a general mechanism for the expression ofmissions, allowing them to be explicitly optimized. This grammar fully describes theclass of missions which can be planned and executed by this system. By providinggeneral task applicability and optimal execution, GRAMMPS extends the capabilitiesand performance of cooperative mobile robot systems. The grammar enables the use ofheterogeneous robot teams allowing each robot’s ability to execute any portion of themission to be specifically defined.

Conclusion

110

• GRAMMPS provides a scalable system, allowing small- to medium- sized1 groups ofrobots to work together on missions involving tens of goals. The use of randomizedsearch algorithms for computationally intractable problems allows the system togracefully degrade from optimality while still providing reasonable performance.

• GRAMMPS is generally applicable to a wide class of robots. Any robotic systemcapable of localization, communication, terrain perception, and safe autonomousoperation can be used in this mission planning and execution framework. By separatingthe requirements of and abstracting the interface to the essential requirements ofmobility from the path- and mission- planning components, GRAMMPS provides ageneral approach towards enabling robot teams.

• This research has provided insight into the metrics of performance for multiple mobilerobots, defining “distance” and “time” metrics for optimizing mission-related grouptasks. Additionally, requirements for moving the D* dynamic path planning algorithmfrom idea to full implementation have been analyzed and described.

Accomplishments 6.2

GRAMMPS represents a significant milestone in mobile robot systems, as the firstdemonstrated outdoor robotic system capable of executing complex missions in naturalterrains. This work leveraged off existing perception, planning and local navigationsystems, adapting or incorporating as then necessary. Some significant aspects of thiseffort include:

•GRAMMPS consists of 25,000 lines of C plus 7,000 lines of Python

•Two different custom terrain-perception systems were incorporated and successfullyused both for autonomous driving and map sharing.

•The demonstration system integrated research code from over a dozen otherresearchers.

•This system was successfully demonstrated live for the US Unmanned Ground Vehiclecommunity on 9/4/97.

Insights and Lessons Learned 6.3

Work involving multiple mobile robots is both rewarding and frustrating. Mobilerobotics has a bright future enabling coordination of groups of robots whichautonomously and efficiently perform complex tasks in unstructured environments.However, the state of hardware and software for these systems is relatively immature.At this point, any robot system is necessarily dependent on a number of youngtechnologies, each with its own quirks and failure modes. Anyone attempting toassemble such systems must be prepared to cope with an outstanding array ofchallenges to see their ideas come to fruition.

Mission planning has proved to be substantially effective as a mechanism for providingcooperation and coordination of robot teams. A large class of missions can be

1.1 to roughly 10 or so. GRAMMPS has been tested on groups of up to 10 robots, and is expected toextend to a few more before fundamentally different approaches will be valuable.

Conclusion

111

expressed, and the performance of these missions can be made optimal based on theknowledge of the system at the time. However, expressing missions directly in thecurrent grammar remains somewhat unintuitive and complex. Providing a more naturalmethod for the user to express a task would permit greater ease of use of this system.

Beyond just basic complexity, the most common failure modes for GRAMMPS indemonstration directly involved difficulties with obstacle detection and avoidance. Byfar the most important and pressing areas of research for outdoor systems lie in makingthe basic mobility components more robust. Permitting operation in dense vegetation,addressing problems with specular reflection from lasers, and utilization of a more fullyintegrated positioning & proprioception system (e.g. inertial navigation plus globalposition techniques) will allow deployment of these systems in actual applications.

Future directions 6.4

While GRAMMPS addresses a large class of potential missions involving multiplemobile robots, it does not fully cover this space. This section describes some directionswhich might be taken to improvement to mission planning in mobile scenarios.

First, large groups (12-20+) of mobile robots defy a central planning approach formission involving large numbers (50+) goals. The challenge to fully-distributedsystems is to provide optimal or near-optimal performance for such missions while stillallowing both substantial fault tolerance and explicit cooperation. While some missions(such as coverage and foraging) are easily amenable to parallelization, ensuring thatthese tasks are performed efficiently in a dynamic environment is a much lessstraightforward problem. For those missions, which involve a greater number ofconstraints, some specific modeling of the tasks is required. Perhaps an intelligent,flexible and dynamic decomposition of the mission into largely independent sub-tasksmay provide a mechanism for successful and efficient execution.

In the near term, it may be beneficial to allow a a larger degree of fault-tolerance byduplicating the mission-planning component on each robot and providing periodic“checkpoints” of optimal solutions. The problem of differentiating between a failure incommunications and a failure of the robot prevents an easy solution of these problems.

A significant question remains with regard to dynamic planning: how fast is fastenough? Intuitively, a mission planner should be able to run more slowly than a pathplanner, which should be able to run more slowly than the local navigator. For example,when you go to the grocery, you don’t need to decide precisely how you will get to thegrocery while backing out of the driveway; or when you reach the grocery and find itclosed, you don’t lose too much performance by spending a little time thinking aboutwhich other store might be open before leaving the parking lot. Beyond the well-studiedproblem of trading off cognition for action, the question in a dynamic planning scenariois how often must knowledge-optimal decisions be made before the benefits ofoptimality are lost?

Finally, for a group of robots performing an ongoing task such as the movement ofsilicon wafers between processing stations, it may be impossible to plan to the “end” ofthe mission, as the process is fundamentally ongoing. In this case, uncertain processfinishing times, robot failures, changing external requests, contribute to the dynamic

Conclusion

112

nature of the environment, which can eventually overwhelms any decision makingprocess. Like predicting the weather, predicting the future state of the system is hard todo because to the number of variables and interactions which can occur duringexecution. This raises the questions: how deep (far into the future) can the plan go andstill have that computation remain useful to the immediate decision of what the systemshould be doing next? As the world becomes more dynamic and unpredictable, thelikelihood of a plan actually being executed as planned a long time prior may be quitesmall.

These future directions are intended to point out fruitful areas of research which arisewhen trying to use a group of mobile robots in a dynamic environment. While generalartificial intelligence remains far beyond our grasp, groups of mobile robots are poisedto revolutionize construction, manufacturing, planetary exploration, and a host of otherhuman endeavors. Allowing such groups to operate efficiently, capably, robustly, andreliably in unmodified environments remains a challenging agenda with solutions justout of reach. GRAMMPS has taken one step along that road, demonstrating efficientautonomous operation of multiple robots in natural terrain. Improvements in basicpositioning, perception and navigation technologies will find techniques ready-and-waiting to incorporate those innovations into fieldable autonomous systems.

113

References

Following are complete references to material cited in the text.

[Aguilar95] Aguilar, L., Alami, R., Fleury, S. Herrb, M. Ingrand, F. Robert, F. Tenautonomous mobile robots (and even more). Proceedings of the IEEE/RSJInternational Conference on Intelligent Robots and Systems (IROS), 1995,pages 260-267.

[Alami95] Alami, R, Aguilar, L., Bullata, S., Fleury, S., Herrb, M. Ingrand, F., Khatib, M.Robert, F. A General Framework for Multi-Robot Cooperation and itsImplementation on a Set of Three Hilare Robots. Experimental Robotics IV, 4thInternational Symposium, 1995, pages 26-39.

[Albus89] Albus, J. S., McCain, H. G., and Lumia, R. (1989). NASA/NBS StandardReference Model for Telerobot Control System Architecture (NASREM).NIST/TN 1235, National Institute of Standards and Technology, Gaithersburg,MD 20899.

[Allen90] Allen, J., Hendler, J., Tate, A. Readings in Planning. Morgan KauffmanPublishers, Inc. San Mateo, California, 1990.

[Arai96] Arai, Y., Suzuki, S., Kotosaka, S. Asama, H. Kaetsu, H. Isao, E. CollisionAvoidance among Multiple Autonomous Mobile Robots using LOCISS(LOcally Communicable Infrared Sensory System). Proceedings of the IEEEInternational Conference on Robotics and Automation, 1996, pages 2091-2096.

[Arkin97] Arkin, R.C. and Balch, T. AuRA: Principles and Practice in Review. Journal ofExperimental and Theoretical Artificial Intelligence, Vol. 9, No. 2, 1997.

References

114

[Arkin92] Arkin, R.C. Cooperation without communication: Multi-agent schema-basedrobot navigation. Journal of Robotic Systems, Volume 9, Number 3, pages 351-364.

[Arora96] Arora, S. Polynomial-time Approximation Schemes for Euclidean TSP andother Geometric Problems. Proceedings. IEEE FOCS, 1996, pages 2-13.

[Asada94] Asada, M., Uchibe, E., Noda, S. Tawaratsuida, S., Hosoda, K. Coordination ofmultiple behaviors acquired by a vision-based reinforcement learning.Proceedings of the IEEE/RSJ International Conference on Intelligent Robotsand Systems (IROS), 1994.

[Azarm96] Azarm, K., Schmidt, G. A Decentralized Approach for the Conflict-FreeMotion of Multiple Mobile Robots. Proceedings of the IEEE/RSJ InternationalConference on Intelligent Robots and Systems (IROS), 1996, pages 1667-1673.

[Basye89] Basye, K., Dean, T., Vitter, J.S., Coping with Uncertainty in Map Learning.Proceedings of the 11th International Join Conference on Artificial Intelligence,1989.

[Beni91] Beni, G., Wang, J. Theoretical problems for the realization of distributed roboticsystems. Proceedings of the IEE International Conference on Robotics andAutonomous Systems, 1991, pages 1914-1920.

[Brooks86] Brooks, R.A. A Robust, Layered Control System for a Mobile Robot. IEEEJournal of Robotics and Automation, April, 1986, pages 14-23

[Brooks85] Brooks, R.A. Visual Map Making for a Mobile Robot. Proceedings of the IEEEInternational Conference on Robotics and Automation, 1985, pages 824-829.

[Brumitt92] Brumitt, B.L., Coulter, R.C., Stentz, A. Dynamic Trajectory Planning fora Cross-Country Navigator. Proceedings of the SPIE Conference on MobileRobots, 1992.

[Buckley89] Buckley, S.J. Fast Motion Planning for Multiple Moving Robots. Proceedingsof the IEEE International Conference on Robotics and Automation, 1989, pages322-325.

References

115

[Cameron94] Cameron, J.M., MacKenzie, D.C. MissionLab: User Manual for Missionlabpreliminary version 0.5. Personal Communication. December, 1994.

[Cao97] Cao, U. Y., Fukunaga, A. S., Kahng, A.B. Cooperative Mobile Robotics:Antecedents and Directions. Autonomous Robots 4, 1997, pages 7-27.

[Causse95] Causee, O., Pampaagnin, L. H. Management of a multi-robot systems in apublic environment. Proceedings of the IEEE/RSJ International Conference onIntelligent Robots and Systems (IROS), 1995, volume 2, pages 246-252.

[Chapman87] Chapman, D. Planning for Conjunctive Goals. Journal of ArtificialIntelligence, Vol. 32, 1987.

[Chatila95] Chatila, R. Deliberation and reactivity in autonomous mobile robots. Roboticsand Autonomous Systems, volume 16, no. 2-4, pages 197-211.

[Chatila92] Chatila, R., Alami, R., Degalaix, B., Laruelle, H. Integrating Planning andExecution Control of Autonomous Robot Actions. Proceedings of the IEEEInternational Conference on Robotics and Automation, 1992, pages 2689-2695.

[Chatterjee96] Chatterjee, S. Carrerea, C. Lynch, L.A. Genetic Algorithms and TravellingSalesman Problems. European Journal of Operational Research, Vol. 93, No. 3,pages 490-510

[Chu92] Chu, H., El Maraghy, H.A. Real-Time Multi-Robot Path Planners Based on aHeuristic Approach. Proceedings of the IEEE International Conference onRobotics and Automation, 1992, pages 475-480.

[Cormen90] Cormen, T.H., Leiserson, C.E., Rivest, R.L. Introduction to Algorithms. TheMIT Press, Cambridge, Massachusetts, 1990.

[Coste-Maniere95] Coste-Maniere, E., Perrier, M. Mission Programming: Applicationto Underwater Robotics. Proceedings of the 4th International Symposium onExperimental Robotics, 1995, pages 402-11.

[Daily88] Daily, M. et al. Autonomous Cross Country Navigation with theALV. Proceedings of the IEEE International Conference on Robotics andAutomation, 1988, pages 718-726.

References

116

[Dean88] Dean, T., Boddy, M. An Analysis of Time Dependent Planning. Proceedings ofthe Seventh National Conference on Artificial Intelligence, pages 49-54, 1988.

[Elfes90] Elfes, A. Occupancy Grids: A Stochastic Spatial Representation for ActiveRobot Perception. Proceedings of the Sixth Conference on Uncertainty inArtificial Intelligence, July 1990.

[Erdmann87] Erdmann, M., Lozano-Perez, T. On Multiple Moving Objects. Algorithmica,No. 2, 1987, pages 477-521

[Feldman77] Feldman, J.A., Sproull, R.F. Decision Theory and Artificial Intelligence II: TheHungry Monkey. Cognitive Science 1, pages 158-192, 1977.

[Feng90] Feng, D., Singh, S., Krogh, B. Implementation of Dynamic Obstacle Avoidanceon the CMU Navlab. Proceedings of the IEEE Conference on SystemsEngineering, August, 1990.

[Fikes71] Fikes, R.E., Nilsson, N.J. STRIPS: A New Approach to the Application ofTheorem Proving to Problem Solving. Artificial Intelligence, Vol. 2., pages 199-208, 1971.

[Firby89] Firby, R.J. Adaptive Execution in Complex Dynamic Worlds,Ph.D. Thesis, YaleUniversity Technical Report, YALEU/CSD/RR #672, January 1989.

[Fox84] Fox, M.S., Smith, S. ISIS: A knowledge Based system for Factory Scheduling.Expert Systems, Vol. 1., No. 1, July 1984.

[Froelich98] Froelich, C., J. Hancock, R. Sullivan, D. Langer. “High-performance ImagingLaser Radar.” Submitted to ICRA’98.

[Fukuda93] Fukuda, T., Kawauchi, Y. Cellular Robotics, Springer Verlag, 1993, pages 588-595.

[Gat91] Gat, E., Integrating planning and reacting in a heterogeneous asynchronousarchitecture for mobile robots, in SIGART Bulletin 2, 1991, pages 70-74.

References

117

[Georgeff87a] Georgeff, M. Planning. Annual Review of Computer Science, Vol. 2., 1987,pages 359-400.

[Georgeff87b] Georgeff, M.P., Lansky, A.L. Reactive Reasoning and Planning. Proceedings ofthe AAAI, 1987. Also found in [Allen90] pages 729-734.

[Gowdy95] Gowdy, J. IPT: An Object Oriented Toolkit for Interproccess Communications,Version 6.5. Unpublished, 1995.

[Gowdy94] Gowdy, J. Object Oriented Architecture and Planning for Outdoor MobileRobots. Unpublished. Carnegie Mellon Robotics Institute Thesis Proposal,1994.

[Gowdy90] Gowdy, J., Stentz, A., Hebert, M. Hierarchical Terrain Representation for Off-Road Navigation. Proceedings of the SPIE Conference on mobile Robotics,1990.

[Hammond86] Hammond, K.J. CHEF: A Model of Cased-based Planning. Proceedings ofAAAI, 1986, pages 261-271.

[Hancock97] Hancock, J., E. Hoffman, R. Sullivan, D. Ingimarson, D. Langer, M. Hebert.“High-performance laser range scanner.” SPIE Proceedings of the IntelligentTransportation Systems Conference, October 1997.

[Hebert94] M. Hebert. Pixel-Based Range Image Processing. In Proceedings of theInternational Conference on Robotics and Automation, 1994.

[Hebert88] Hebert, M, Kanade, T., Kweon, I.S. 3-D Vision Techniques for AutonomousVehicles. Carnegie Mellon Robotics Institute Technical Report CMU-RI-TR-88-12, 1988.

[Good71] Good, I. J. Twenty-seven Principals of Rationality. In Proceedings of theSymposium on the Foundations of Statistical Inference. Rene DescartesFoundation, 1971.

[Goodwin94] Goodwin, Richard. Reasoning About When To Start Acting. Proceedingsof the Second International Conference on Artificial Intelligence PlanningSystems (AIPS-94), pages 86-91, 1994.

References

118

[Hogg93] Hogg, R, Tanis, E. Probability and Statistical Inference. McMillianPublishing Company, New York, New York, 1993, pages 80-88.

[Hopfield85] Hopfield, J.J., Tank, D.W. ‘Neural’ computation of decisions in optimizationproblems. Biological Cybernetics, Vol. 52, No. 3, 1985, pages 141-152.

[Ingrand96] Ingrand, F.F., Chatila, R., Alami, R., Robert, F. PRS: A High Level Supervisionand Control Language for Autonomous Mobile Robots. Proceedings of theIEEE International Conference on Robotics and Automation, 1996, pages 43-49.

[Ishida94] Ishida, Y., Asama, H., Tomina, S., Ozaki, K., Matsumoto, A., Endo, I.Functional complement by cooperation of multiple autonomous robots.Proceedings IEEE International Conference on Robotics and Automation,1994, pages 2476-2481.

[Jeong90] Fast parallel simulated annealing for traveling salesman problem. InternationalJoin Conference on Neural Networks (IJCNN), 1990, pages 947-53.

[Kaelbling87] Kaelbling, L.P. An Architecture for Intelligent Reactive Systems. In Georgeffand Lansky, Reasoning About Actions and Plans. Also found in [Allen90] pages713-728.

[Keirsey88] Keirsey, D. Payton, D., Rosenblatt, J. Autonomous Navigation in Cross CountryTerrain. Proceedings of the DARPA Image Understanding Workshop, 1988.

[Kelly97a] Kelly, A., Stentz, A. “Analysis of Requirements for High Speed Rough TerrainMobility: Part 1 - Throughput and Response”, ICRA 1997.

[Kelly97b] Kelly, A., Stentz, A. “Analysis of Requirements for High Speed Rough TerrainMobility: Part 2 - Resolution and Accuracy”, ICRA 1997.

[Kelly94] Kelly, A. An Intelligent Predictive Controller for Autonomous Vehicles.Carnegie Mellon Robotics Institute Technical Report, CMU-RI-TR-94-20.Further details can be found in CMU-RI-TR-94-(16-19).

[Kelly92] Kelly, A., Stentz, A., Hebert, M. Terrain Map Building for Fast Navigation onRough Terrain. Proceedings of the SPIE Conference on Mobile Robots, 1992.

References

119

[Kirkpatrick84] Kirkpatrick, S. Optimization by Simulated Annealing: Quantitative Studies.Journal of Statistical Physics, Vol 34. Nos 5/6, 1984, pages 975-986.

[Koenig97] Koenig, Sven, editor. On-Line Search, Technical Report WS-97-10, AAAIPress, 1971.

[Korf90] Korf, R. E. Real-time Heuristic Search. Artificial Intelligence, Journal, Volume42, Number 2-3) pages 197-221.

[Kube97] Kube, C.R., Zhang, H. Task Modeling in Collective Robotics. AutonomousRobots 4, 1997, pages 53-72.

[Kuipers88] Kuipers, B.J., Byun, Y. A Robust, Qualitative Approach to a SpatialLearning Mobile Robot. SPIE Vol 1003 Sensor Fusion: Spatial Reasoning andScene Interpretation, 1988.

[Kweon90] Kweon, I.S. Modeling Rugged Terrain by Mobile Robots with MultipleSensors. Carnegie Mellon Ph.D.Thesis, 1990.

[Lacroix95] Lacroix, S., Chatila, R., Fleury, S., Herrb, M., Simeon, T. AutonomousNavigation in Outdoor Environment: Adaptive Approach and Experiment.IEEE Proceedings of the International Conference on Robotics andAutomation, 1995, pages 426-432.

[Langer94a] D. Langer, J. Rosenblatt, M. Hebert. A Behavior-Based Approach to theAutonomous Navigation Systems. IEEE Transactions on Robotics andAutomation, vol.10, no. 4. 1994.

[Langer94b] Langer, D., Rosenblatt, J.K., Hebert, M. An Integrated System for Off-RoadNavigation. Proceedings of the IEEE International Conference on Robotics andAutomation, 1994, pages 414-419.

[Langer93] Langer, D., Rosenblatt, J.K., Hebert, M. A Reactive System for Off-RoadNavigation. Carnegie Mellon Robotics Institute Technical Report CMU-RI-TR-93-24, 1993

[Latombe91] Latombe, J.C. Robot Motion Planning. Kluwer Academic Publishers, 1991.

References

120

[Lawler85] Lawler, E.L., et al. The Travelling Salesman Problem, John Wiley & Sons,1985.

[Leonard90] Leonard, J., Durrant-Whyte, H., Cox, I. Dynamic Map Building for anAutonomous Mobile Robot. IEEE International Workshop on IntelligentRobots and Systems (IROS 90), pages 89-95.

[LePape90] Le Pape, C. A Combination of Centralized and Distributed Methods for Multi-Agent Planning and Scheduling. Proceedings of the IEEE InternationalConference on Robotics and Automation, 1990, pages 488-493.

[Lueth94] Lueth, T.C., Laengle, T. Task description, decomposition and allocation in adistributed autonomous multi-agent robotic systems. Proceedings of theIEEE/RSJ International Conference on Intelligent Robots and Systems (IROS),1994, pages 1516-1523.

[Li94] Li, S. Coordinating Multiple Mobile Robots through Local Inter-robotCommunication. Distributed Autonomous Robotic Systems. Springer-Verlag,Tokyo, Japan, 1994. Pages 190-198.

[Lin97] Lin, F., Hsu, J Y. Cooperation Protocols ina Multi-Agent Robotics Systems.Autonomous Robots 4, 1997, pages 174-196.

[Lin65] Lin S. Bell Systems Technical Journal, 1965, vol 33, page 2245.

[Lumelsky97] Lumelsky, V.J., Harinarayan, K.R. Decentralized Motion Planning for MultipleMobile Robots: The Cocktail Party Model. Autonomous Robots 4, 1997, pages121-135.

[Lutz96] Lutz, M. Programming Python. O’Reilley & Associates, Sebastopol, CA, 1996.Also see http://www.python.org/.

[Mackenzie97] Mackenzie, D.C., Arkin, R.A, Cameron, J. M. Multi-agent MissionSpecification and Execution. Autonomous Robots 4, 1997, pages 29-52.

[Mara92] Mara, M, Dunlay, R.T., Mathis, D. Terrain Classification Using Texture for theALV. Proceedings of the SPIE Conference on Mobile Robots, 1992.

References

121

[Mataric97] Mataric, M. J. Reinforcement Learning in the Multi-Robot Domain.Autonomous Robots 4, 1997, pages 73-83.

[Mataric92] Mataric, M.J. Minimizing Complexity in Controlling a Mobile RobotPopulation. Proceedings of the IEEE International Conference on Robotics andAutomation, 1992, pages 830-835.

[Minami96] Minami, T., Suzuki, I., Yamashita, M. Fusion of Social Laws and Super Rolesfor Coordinate the Motion of Mobile Robots. Proceedings of the IEEE/RSJ/GIInternational Conference on Intelligent Robots and Systems (IROS), 1994,volume 3, pages 1691-1698.

[Moravec83] Moravec, H. The Stanford Cart and the CMU Rover. Proceedings of theIEEE Vol. 71, No. 7, July 1983, pages 872-844.

[Nashashiba94] Nashashibi, F., Fillatreau, P, Dacre-Wright, B, Simeon, T. 3-D AutonomousNavigation in a Natural Environment. Proceedings of the IEEE InternationalConference on Robotics and Automation, 1994, pages 433-439.

[Nilsson69] Nilsson, N.J. A Mobile Automaton: An Application of Artificial IntelligenceTechniques. Proceedings of the International Joint Conference on ArtificialIntelligence, 1969.

[Noriels93] Noriels, F.R. Toward a robot architecture integrating cooperation betweenmobile robots: Application to indoor environment. The International Journal onRobotics Research, Volume 12, Number 1, 1993.

[Nourbakhsh97] Nourbakhsh, I. Interleaving Planning and Abstraction for Autonomous MobileRobots. Kluwer Academic Publishers, 1997.

[Olin91] Olin, K., Tseng, D. Autonomous Cross Country Navigation. IEEEExpert, August, 1991, pages 16-30.

[Parker96] Parker, L. Task-Oriented Multi-Robot Learning in Behaviour Based Systems.Proceedings of the IEEE/RSJ International Conference on Intelligent Robotsand Systems (IROS), 1996, pages 1478-1485.

References

122

[Parker94a] Parker, Lynne. Heterogeneous Multi-Robot Cooperation. Ph.D. Thesis,Massachusetts Institute of Technology, February 1994.

[Parker94b] Parker, L. E. ALLIANCE: An Architecture for Fault Tolerate CooperativeControl of Heterogeneous Mobile Robots. Proceedings of the IEEE/RSJInternational Conference on Intelligent Robots and Systems (IROS), 1994,volume 2, pages 776-83.

[Parodi87] Parodi, A.M. An Intelligent System for an Autonomous Vehicle. Proceedings ofthe IEEE International Conference on Robotics and Automation, 1987, pages1657-1663.

[Parsons90] Parsons, D., Canny, J. A Motion Planner for Multiple Mobile Robots.Proceedings of the IEEE International Conference on Robotics andAutomation, 1990, pages 8-13.

[Payton90] Payton, D, Rosenblatt, J.K., Keirsey, D. Plan Guided Reaction. IEEETransactions on Systems, Man and Cybernetics, Vol. 20, No. 6,November/December 1990, pages 1370-1382.

[Pednault 87] Pednault, E.P.D. Formulating Multi-agent, Dynamic-World Problems in theClassical Planning Framework. In Georgeff and Lansky, Reasoning AboutActions and Plans. Also found in [] pages 675-710.

[Premvuti90] Premvuti, S., Yuta, S. Consideration on the Cooperation of MultipleAutonomous Mobile Robots. IEEE International Workshop on IntelligentRobots and Systems (IROS ‘90), 1990.

[Press88] Press,W.H. Falnnery, B.P., Tekolsky, S.A., Vetterling, W.T. Numerical Recipesin C. Cambridge University Press, 1988.

[Pomerleau92] Pomerleau, D. Neural network perception for Mobile Robot Guidance.Carnegie Mellon Ph.D. Thesis, Carnegie Mellon Computer Science DepartmentTechnical Report CMU-CS-TR-92-115.

[Reynolds94] Reynolds, C. Cooperation, coevolution and the game of tag. In Principles ofArtificial Life IV, 1994,

References

123

[Rosenblatt95] J.K. Rosenblatt, C.E. Thorpe. Combining Multiple Goals in a Behavior-BasedArchitecture. Proceedings of IROS 1995. 1995.

[RuggGunn94] Rugg-Gunn, N., Cameron, S. A Formal Semantics for Multiple Vehicle Taskand Motion Planning. Proceedings of the IEEE International Conference onRobotics and Automation, 1994, pages 2464-2469.

[Schalit92] Schalit, E. ARCANE: Towards Autonomous Navigation on Rough Terrain.Proceedings of the IEEE International Conference On Robotics andAutomation, 1992, pages 2568-2574.

[Selman92] Selman, B., Levesque, H. Mitchell, D. A New Method for Solving HardSatisfiability Problems. Proceedings of the 10th International Conference onArtificial Intelligence, pages 440-446.

[Simmons94] Simmons, R. Structured Control for Autonomous Robots. IEEETransactions on Robotics and Automation, 10:1, February 1994.

[Singh91] Singh, S. et. al. FastNav: A System for Fast Navigation. Carnegie MellonRobotics Institute Technical Report CMU-RI-TR-91-20, 1991.

[Singh97] Singh, S., Search in the context of complex robot-world interaction, InProceedings, AAAI workshop on On-line Search[Koenig97], 1997

[Stentz95a] Stentz, A. “The Focussed D* Algorithm for Real-Time Replanning,”Proceedings of the International Joint Conference on Artificial Intelligence,August, 1995.

[Stetntz95b] Stentz, A., Hebert, M. “A Complete Navigation System for Goal Acquisition inUnknown Environments,” Autonomous Robots, 2(2), 1995.

[Stentz94] Stentz, A. “Optimal and Efficient Path Planning for Partially-KnownEnvironments,” Proceedings International Conference on Robotics andAutomation, 1994.

[Stentz93] Stentz, A. “Basic Motion Planning”, unpublished lecture notes for Introductionto Mobile Robotics, Fall 1993, Carnegie Mellon University.

References

124

[Stentz92] Stentz, A., Brumitt, B., Coulter, R., Kelly, A. An Autonomous System forCross-Country Navigation. Proceedings of the SPIE Conference on MobileRobots, 1992.

[Tate85] Tate, A., Hendler, J., Drummond, M. A Review of AI Planning Techniques.Knowledge Engineering Review, Vol. 1, No. 2, pages 4-17, June, 1985.

[Thomas95] Thomas, M.C., Dahl, V. Fall, A. Logic Planning in Robotics. Proceedings of theIEEE International Conference on Systems, Man and Cybernetics, 1995, pages2951-2955.

[Thompson77] Thompson, A. The Navigation System of the JPL Robot. Proceedings of theInternational Joint Conference for Artificial Intelligence, 1977, pages 749-757.

[Vacherand94] Vacherand, F. Fast Local Path Planner in a Certainty Grid. Proceedings of theIEEE International Conference on Robotics and Automation, 1994, pages 2132-2137.

[Vestli96] Vesti, S.J., Tschichol-Gurman, N. MOPS, a System for Mail Distribution inOffice Type Buildings. Proceedings of the IEEE/RSJ International Conferenceon Intelligent Robots and Systems (IROS), 1996, pages 489-495.

[Vidal96] Vidal, T. Ghallab, M. Alami, R. Incremental Mission Allocation to a LargeTeam of Robots. Proceedings of the IEEE International Conference on Roboticsand Automation, 1996, pages 1620-1625.

[Wang90] Wang, J, Beni, G. Distributed computing problems in cellular robotic systems.Proceedings of the IEEE/RSJ International Conference on Intelligent Robotsand Systems (IROS), 1990, pages 819-826..

[Warren90] Warren, C.W. Multiple Robot Path Coordination Using Artificial PotentialFields. Proceedings of the IEEE International Conference on Robotics andAutomation, 1990, pages 500-505.

[Wilcox87] Wilcox, B., et. al. A Vision System for a Mars Rover. SPIE Mobile Robots II,November 1987, pages 172-179.

References

125

[Yeung87] Yeung, D.Y, Bekey, G. A Decentralized Approach to the Motion PlanningProblem for Multiple Mobile Robots. Proceedings of the IEEE InternationalConference on Robotics and Automation, 1987, pages 1779-1783.

[Yoshida96] Evaluating the Efficiency of Local and Global Communication in DistributedMobile Robotic Systems. Proceedings of the IEEE/RSJ InternationalConference on Intelligent Robots and Systems (IROS), 1996, 1661-1666.

References

126