• Aucun résultat trouvé

Formal Problem Denition

ALLIANCE: The Cooperative Robot Architecture

3.3 Formal Problem Denition

It is important to note here that this report deals strictly with cooperative robot missions that are composed of loosely coupled subtasks that are largely independent of each other. By \largely" independent, I mean that tasks can have xed ordering dependencies, but they cannot be of the type of \brother clobbers brother" [Sussman, 1973], where the execution of one task required by the mission undoes the eects of another task required by the mission. Even with this restriction, however, this report covers a very large range of missions for which cooperative robots are useful.

As we shall see in this and later chapters, a wide variety of applications have been implemented and are reported that fall into this domain of loosely coupled, largely independent subtasks.

I now dene formally the problem addressed in this report. Let the set R =

fr1;r2;:::;rngrepresent the set of n heterogeneous robots composing the cooperative team, and the set T = ftask1;task2;:::;taskmg represent m independent subtasks which compose the mission. I use the term high-level task-achieving function to correspond intuitively to the functions possessed by individual robots that allow the robots to achieve tasks required in the mission. These functions map very closely to the upper layers of the subsumption-based control architecture [Brooks, 1986].

In the hazardous waste cleanup mission, the high-level functions are: nd-initial-nal-locations, move-spill, and report-progress. Table 3.1 gives examples of what I consider to be the high-level task-achieving functions of a number of previously reported robots. In the ALLIANCE architecture, the control code of each robot

3.3. FORMAL PROBLEM DEFINITION 29

Robot High-Level Functions

Allen [Brooks, 1986] Wander Attila/Hannibal [Ferrell, 1993] Keep walking Genghis [Brooks, 1989] Keep walking George/HARV [Arkin, 1990] Reactively navigate Herbert [Connell, 1989] Collect empty soda cans Hilare [Giralt et al., 1983] Map oce environment Polly [Horswill, 1993] Give 7th oor AI Lab tours

Rocky III [Milleret al., 1992] Search for soft soil; acquire soil sample;

return sample to home

Rocky IV [Gat et al., 1993] Collect soil sample; chip rocks;

deploy instruments; return sample to home RPV [Bonasso, 1991] Reactively navigate underwater

Squirt [Flynn et al., 1989] Eavesdrop

Toto [Mataric, 1992b] Map oce environment; go to goal Table 3.1: High level task-achieving functions of various robots.

is organized into groups of behaviors calledbehavior sets, each of which supplies the robot with a high-leveltask-achieving function. Thus, in the ALLIANCE architecture, the termshigh-level task-achieving function and behavior set are synonymous.

I refer to the high-level task-achieving functions, or behavior sets, possessed by robot ri in ALLIANCE as the set Ai =fai1;ai2;:::g. Since dierent robots may have dierent ways of performing the same task, we need a way of referring to the task a robot is working on when it activates a behavior set. Thus, I dene the set of n functionsfh1(a1k);h2(a2k);:::;hn(ank)g, wherehi(aik) returns the task inT that robot ri is working on when it activates behavior set aik.

I now dene the notions of goal-relevant capabilitiesand task coverage.

Denition 1

The goal-relevant capabilities of robot ri, GRCi, are given by the set:

GRCi =faijjhi(aij)2Tg where T is the set of tasks required by the current mission.

In other words, the capabilities of robot rithat are relevant to the current mission (i.e. goal) are simply those high-level task-achieving functions which lead to some task in the current mission being accomplished.

The termcoverage has been used in a number of contexts, such as DNA physical mapping in computational biology [Lander and Waterman, 1988] and in multiple robotics applications dealing with spatial distribution of robots [Gage, 1993]. Here,

I use the term task coverage to give a measure of the number of capabilities on the team that may allow some team member to achieve a given task. This is the measure that is used by human (or automated) designers to collect robots from the available pool of robots to form a team with the required capabilities to accomplish a given mission. However, we cannot always predict robot failures; thus, at any point during a mission, a robot may reach a state from which it cannot achieve a task for which it has been designed. This implies that the expected task coverage for a given task in a mission may not always equal the truetask coverage once the mission is underway.

Denition 2

Task coverage is given by:

task coverage(taskk) =Xn

Note that if any one robot has more than one way to accomplish taskk, that redundancy is included in the task coverage value. An interesting side-eect of this denition is that in homogeneous robot teams, the task coverage for all tasks in T is always a positive integral multiple of the number of robots n. That is,

8k:9(c2

N

):task coverage(taskk) =cn

where

N

is the set of natural numbers. Note that this is not a sucient condition for homogeneity, since then robots could have n dierent ways of accomplishing task taskk.

The task coverage measure is useful for composing a team of robots to perform a mission from the available pool of heterogeneous robots. At a minimum, we need the team to be composed so that the task coverage of all tasks in the mission equals 1. This minimum requirement ensures that, for each task required in the mission, a robot is present that has some likelihood of accomplishing that task. Without this minimum requirement, the mission simply cannot be completed by the available robots. Ideally, however, the robot team is composed so that the task coverage for all tasks is greater than 1. This gives the team a greater degree of redundancy and overlap in capabilities, thus increasing the reliability and robustness of the team amidst individual robot failures. Although it is often most useful to have a uniform task coverage across the mission, some missions may include a subset of tasks that are of particular importance; this subset of tasks may therefore require higher levels of task coverage than the remainder of the tasks.

Within this application domain, two key problems must be addressed. First, a control architecture must be developed that allows robots on these cooperative teams to properly select tasks during the mission such that the collective actions of the team lead to mission completion. This is the problem that the cooperative architecture