STUDIES FROM THE

DEPARTMENT OF TECHNOLOGY AT ÖREBRO UNIVERSITY ISSN 1404-7225

An Algorithm for Generating Configurations of a Group of Robots Robert Lundh, Lars Karlsson and Alessandro Saffiotti No: 24 2007-05-10

Örebro universitet Institutionen för teknik 701 82 Örebro

Örebro University Department of technology SE-701 82 Örebro, Sweden

An Algorithm for Generating Configurations of a Group of Robots ISSN 1404-7225 Author: Robert Lundh, Lars Karlsson, Alessandro Saffiotti STUDIES FROM THE DEPARTMENT OF TECHNOLOGY AT ÖREBRO UNIVERSITY Nr: 24 Örebro University Department of Technology SE 701 82 Örebro Tel: +46 30 10 00 Fax: +46 30 39 49 This technical report do not exist in print, only online at www.tech.oru.se Örebro 2007-05-10

An Algorithm for Generating Configurations of Groups of Robots Robert Lundh, Lars Karlsson, Alessandro Saffiotti AASS Mobile Robotics Lab ¨ ¨ Orebro University, 70182 Orebro, Sweden. {robert.lundh, lars.karlsson, alessandro.saffiotti}@aass.oru.se Abstract This work is about the use of artificial intelligence (AI) planning techniques to automatically configure cooperation among robots. We consider groups of autonomous robots in which robots can help each other by offering information-producing resources and functionalities. A configuration in this context, is a way to allocate and connect functionalities among robots. In general, different configurations can be used to solve the same task, depending on the current situation. Configuration generation is the problem of automatically generating a configuration for some specific purpose given a set of robotic devices possessing different functionalities. In this paper, we consider an existing configuration planner both from a theoretical point of view (soundness, completeness, and optimality), and an empirical point of view (scalability). We also present a technique to improve the scalability of the configuration planner.

1

Introduction

Consider the situation shown in Fig. 1 (top), in which a mobile robot, named Pippi, has the task to push a box across a door. In order to perform this task, Pippi needs to know the position and orientation of the door relative to itself at every time during execution. It cannot rely on odometry for this, since the wheels may slip during the push operation. Unfortunately, its camera view is covered by the box, so this cannot be used to measure the position of the door. There is, however, another solution: a second robot, called Emil, could observe the scene from an external point of view in order to compute the position of the door relative to Pippi, and communicate this information to Pippi. The above scenario is an instance of a general approach to realize tight cooperation between a group of (possibly heterogeneous) robots — or, more generally, agents. Each robot in the group includes a number of functionalities: for instance, functionalities for image understanding, localization, planning, and so on. To perform a given task, each robot may use functionalities from other robots in order to compensate for the ones that it is lacking, or to improve its own. In the above scenario, Pippi borrows from Emil a perceptual functionality for measuring the relative position between the door and itself. Informally,

1

Emil

Pippi

00 11 11 00 1 0 00 11 Environment

Figure 1: Emil helps Pippi to push the box through the door by measuring the position of the door relative to Pippi. we call configuration a way to allocate and connect the functionalities of a distributed multi-robot system (see Fig. 1 bottom). Often, the same task can be performed using different configurations. In our scenario, Pippi could perform its task by connecting its door-crossing functionality to either (1) its own perception functionality, (2) a perception functionality borrowed from Emil, or (3) a perception functionality borrowed from a static camera placed over the door. Ideally, we would like to automatically select the best available configuration for a given task, world state, and group of robots. In our work, we are interested in the possibility to automatically generate configurations of robots. Similar problems have been studied in several different research areas, e.g., in program supervision [Shekhar et al., 1998], automatic web service composition [Rao and Su, 2004], dynamic software architectures [Bradbury et al., 2004], coalition formation [Shehory and Kraus, 1998], ambient intelligence [Ha et al., 2006], and single robot task performance [Morisset et al., 2004] [Kim et al., 2006]. However, in the area of cooperative robotics, very few works address the automatic configuration problem. Two notable exceptions are ASyMTRe [Parker and Tang, 2006], and our plan-based approach [Lundh et al., 2006]. Note that configuration generation is distinct from task allocation [Gerkey and Matari´c, 2004]. The latter concerns the allocation of a given set of tasks to a given set of robots, and these tasks can be executed independently. Our algorithm on the other hand performs a search in the space of alternative configurations for solving a given complex task in a cooperative manner. In other words, configuration generation is concerned with how functionalities (which are distributed among different physical robots) are automatically selected, connected and activated in order to form one specific “distributed system” for one task. In order to perform a different task, or the same task in a different context, a different set of functionalities may be selected, connected and activated to form a different distributed system. In this paper, we start from our previous work [Lundh et al., 2006] and we extend it in two important ways. From a formal point of view, we re-formulate the approach in a way that makes it suitable to a formal analysis. This allows us 2

to prove soundness, completeness, and optimality of the configuration algorithm. From an empirical point of view, we look at the scalability of the algorithm, and present a technique to improve this by using a form of least commitment planning [Weld, 1994]. We demonstrate the scalability of the algorithm with experiments involving large numbers of available and required robots.

2

Functional configurations

In this paper, we use the definitions of functional configurations we first proposed in [Lundh et al., 2006]. We assume that the world can be in a number of different states. The set of all potential world states is denoted S. There is a number of robots r1 , . . . , rn . The properties of the robots, such as what sensors they are equipped with and their current positions, are considered to be part of the current world state s0 . A functionality is an operator that uses information (provided by other functionalities) to produce additional information. A functionality is denoted by f = r, Id, I, O, Φ, P r, P o, Cost Each instance of a functionality is located at a specific robot or other type of agent r and has a specific identifier Id.1 The remaining fields of the functionality tuple represent: • I = {i1 , i2 , . . . , ik } is a specification of inputs, where ij = descr, dom. The descriptor (descr) gives the state variable of the input data, and the domain (dom) specifies to which set the data must belong. We use dom(I) to denote ×kj=1 dom(ij ). • O = {o1 , o2 , . . . , om } is a specification of outputs, where oj = descr, dom, as above. • Φ : dom(I) → dom(O) specifies the relations between inputs and outputs. • P r : S → {T, F } specifies the causal preconditions of the functionality. P r specifies in what states s ∈ S the functionality can be used. • P o : S × dom(I) → S specifies the causal postconditions. Given the input to the functionality, P o transforms the world state s before the functionality was executed into the world state s after the functionality has been executed. • Cost specifies how expensive the functionality is, e.g., in terms of time, processor utilization, energy, etc. There are three different types of functionalities: (1) functionalities with sensor capabilities (e.g., a camera), (2) functionalities with processing capabilities (e.g., the measure door operation mentioned in the introductory example), and (3) functionalities with actuator capabilities (e.g., a manipulator with a controller). 1 When referring to a specific element in a tuple, we will freely use either a functional notation or a subscript notation, e.g., both r(f ) and rf refer to the field r in the tuple of f .

3

A channel ch = fsend , o, frec , i transfers data from an output o of a functionality fsend to an input i of another functionality frec . A configuration C is tuple F, Ch, where F is a set of functionalities and Ch is a set of channels that connect functionalities to each other. Each channel connects the output of one functionality to the input of another functionality. In the context of a specific world state s, a configuration F, Ch is admissible if and only if the following two conditions are satisfied: 1) Each input of each functionality is connected via an adequate channel to an output of another functionality with a compatible specification (information admissibility): ∀f ∈ F ∀i ∈ If ∃ch ∈ Ch, fsend ∈ F, o ∈ Ofsend : ch = (fsend , o, f, i) and descr(o) = descr(i), dom(o) = dom(i)

(1)

2) All preconditions of all functionalities hold in the current world state (causal admissibility): ∀f ∈ F : P rf (s) = T (2) A configuration also has a cost. This can be based on functionality costs, communication cost, etc, but also on performance accuracy and reliability of the configuration. Currently, we compute the cost as a weighted sum of the number of components used.

2.1

Examples

To illustrate the above concepts, we consider a concrete example inspired by the scenario in the introduction. A robot is assigned the task of pushing a box from one room to another one by crossing a door between the two rooms. The “cross-door” action requires information about position and orientation of the door with respect to the robot performing the action. There are two indoor robots (including the one crossing the door) each one equipped with a camera and a compass. The door to cross is equipped with a wide-angle camera. Fig. 2 illustrates four different (admissible) configurations that provide the information required by the action “cross-door”, which include the functionalities above. The first configuration involves only the robot performing the action. The robot is equipped with an elevated panoramic camera that makes it possible to view the door even when pushing the box. The camera produces information to a functionality that measures the position and orientation of the door relative to the robot. The second configuration in Fig. 2 shows the other extreme, when all information is provided by the door that the robot is crossing and the robot is not contributing with any information. The door is equipped with a camera and functionalities that can measure the position and orientation of the robot relative to the door. This information is transformed into position and orientation of door with respect to the robot before it is delivered to robot A. In the third configuration in Fig. 2, robot A (the robot performing the “crossdoor” action) contributes with a compass, and the second robot (B) contributes with a compass and a camera. The camera provides information to two functionalities: one that measures the position and orientation of the door, and 4

Figure 2: Four different configurations that provide the position and orientation of a given door with respect to robot A. (See text.) 5

another one that measures the position of robot A. All these measurements are computed relative to robot B. In order to compute the position and orientation of the door relative to robot A, we need to use a coordinate transformation. This in turn requires that we know, not only the relative position, but also the orientation of robot A relative to B. The later can be obtained by comparing the absolute orientations of the two robots, measured by their two on-board compasses. The fourth configuration in Figure 2 is similar to the third one, except that the orientation of robot A relative to B is obtained in another way, i.e., no compasses are used. Both robots are equipped with cameras and have a functionality that can measure the bearing to an object. When the robots look at each other, each robot can measure the bearing to the other one. By comparing these two measurements, we obtain the orientation of robot A relative to robot B. Note that the configurations in the examples above (and in general) require some reliable means for frequent communication: robots communicating directly with each other by radio would have difficulties to achieve this unless there are few of them, and they are near each other. One solution is to have a well-developed communication infrastructure that the robotic devices can take advantage of. In [Lundh et al., 2007], configurations are generated in the context of a Peis Ecology, were the robotic devices rely on a distributed middleware to communicate and cooperate. In a Peis Ecology, the term “robotic device” is taken in a wide sense, including both mobile robots, static sensors or actuators, and automated home appliances [Saffiotti and Broxvall, 2005]. Thus, Peis Ecologies and related approaches such as ubiquitous robotic systems [Ha et al., 2006, Kim et al., 2004] and network robot systems [Network Robot Forum, 2007] have the potential to support quite complex configurations.

3

Configuration Generation

We now give a formal account of the configuration planner originally proposed in [Lundh et al., 2006]. This process requires a declarative description of: (1) the functionalities and methods for connecting them, (2) the current world state, (3) the goal for what the configuration should produce. The world state declares the available robots and their physical capabilities, as well as the state of the surrounding environment. It is encoded as a set of clauses, such as robot(r1), door(d1), visible(r1, door1). The goal for the configuration generation process is to produce a desired information output. For example, in the cross-door example, the information goal is the position and orientation of the door that is required as input by the cross-door behavior. The description of available functionalities is realized using operator schemas similar to those of AI action planners. One functionality operator schema from the scenario in the previous section, measure-door, is shown in the upper half of Figure 3. We have an image taken by the camera of r as input and from that we are able to compute the position and orientation of the door d relative to r as output. The precondition for measure-door is that the door d is fully visible in the input image. Note that the Φ function is not part of the operator schema; it corresponds to the actual code for executing the functionality.

6

(functionality name: measure-door(r, d) input: (image(r, d), image) output: (pos(r, d), real-coordinates) (orient(r, d), radians) precond: visible(r, d) postcond: cost: 2 ) (config-method name: get-door-info(r, d) precond: ( camera(r), in(r, room), in(d, room), robot(r), door(d)) in: out: f2: pos(r, d) f2: orient(r, d) channels: (f1, f2, image(r, d)) body: f1: camera(r, d) f2: measure-door(r, d) )

Figure 3: A functionality operator schema, and a method schema for combining functionalities. In order to combine functionalities to form admissible configurations that solve specific tasks, the algorithm use techniques inspired by hierarchical planning, in particular the SHOP planner [Nau et al., 1999]. The configuration planner uses methods that describe alternative ways to combine functionalities (or other methods) for specific purposes. A method m has the form m = Id, Pr, I, O, B, Ch where: Id is the method id, i.e., a term of the form α(c1 , ..., cn ); Pr is the set of preconditions; I and O are specifications of inputs and outputs, given as sets of descr, dom pairs; B = {m1 , . . . , mk } is the body of the method, where each mi is either a functionality or method id; and Ch is a set of internal channels. Each internal channel ch ∈ Ch has the form m1 , o1 , m2 , i2 , where m1 , m2 ∈ B, o1 ∈ Om1 and i2 ∈ Im2 . Intuitively, {I, B, O}, Ch can be seen as a directed graph, with input nodes I and output nodes O. A method schema represents a class of methods, and has the same form as a method, but contains variables. The Id component contains parameter variables, and P r may contain additional (free) variables, which also need to be bound. The lower half of Figure 3 shows an example of a method schema with Id = get-door-info that combines the camera functionality and the measure-door functionality above with a channel on the same robot in order to obtain door measurements of a specific door. The precond field of the method schema corresponds to P rm , in to Im , and out to Om . In channels, which corresponds to Chm , a channel is specified that connects two functionalities (labeled f1 and f2). The output (pos(r, d), orient(r, d)) of f2 is declared in the out field to be the output of the entire method. Thereby, any channel that in a method higher up in the method expansion hierarchy is connected to the output of get-door-info will be connected to the output of measure-door. A method schema m with Id = α(v1 , ..., vn ) is expanded given a method Id α(c1 , ..., cn ) as follows. Let σ be the substitution that unifies the two terms. The

7

preconditions P rm σ are tested, yielding a new set of substitutions {σ1 , ...σh } also including bindings for the free variables in P rm ; if the preconditions do not hold, that set will be empty. The result of the expansion is a set of methods {mσ1 , ..., mσh }. There can be several methods with the same Id. Their total expansion is then the union of their individual expansions. Note that all method with the same Id must have the same I and O (although the elements in I and O can be connected differently.) Likewise, a functionality operator schema has the same form as a functionality, but contains parameter variables (but no free variables in the preconditions), and it is expanded in similar manner, yielding a functionality. For convenience, when m is a method/functionality Id occurring in the body of some method, we write Im and Om to refer to the Im and Om of the expansion(s) m of m. It is important to define what it means for a method m to be well specified. We say that, an output o ∈ Om is bound if its data are produced inside the method, i.e., there is some m ∈ B such that o ∈ Om . For each m ∈ B and each i ∈ Im we say that i is bound if its data are produced in the method, i.e., there is either a channel m , o, m , i such that dom(i) = dom(o), descr(i) = descr(o) and m ∈ B and o ∈ Om , or supplied as input to the method, i.e., i ∈ Im . Then, we say that a method m is information admissible if: (1) all o ∈ O are bound, and (2) for all m ∈ B and all i ∈ Im , i is bound. We call configuration domain a pair D = F, M  where F is a set of functionality operators, and M is a set of method schemas. A domain D is closed if, for all m ∈ D, Bm ⊆ D.

3.1

Configuration Problem and Solution

A configuration problem is a tuple (S, G, D, Ch) where S is a state, G a list of goals (i.e., functionality or method Ids), D is the domain specifying the functionalities and methods available, and Ch is the set of channels connected to the goal elements in G. If P = (S, G, D, Ch), then Π(P ), the set of all configurations for G in S for D, is defined recursively as follows. (1) If G is empty, then Π(S, G, D, Ch) contains exactly one configuration, namely the empty configuration ∅, ∅. Otherwise, let g be the first goal in G and G be the remaining goals, and continue as follows. (2) If g is a functionality Id which expands to f and its preconditions hold in s, then Π(S, G, D, Ch) = {{f } ∪ F  , Ch |F  , Ch  ∈ Π(S, G , D, Ch)} (3) If g is a functionality Id and the preconditions of its expansion f do not hold in S, then Π(S, G, D, Ch) = ∅. (4) If g is a method Id which expands to the set M according to the domain D, then Π(S, G, D, Ch) = {Π(S, append(Bm , G ), D, Ch )| m ∈ M andCh = (Ch with channels to/from l reconnected according to Im /Om ) ∪ Chm } The reconnection of channels in Ch for a given m works as follows. If m , o, m , i ∈ Ch, then this is changed to m1 , o, m , i where for m1 ∈ Bm it

8

holds that o ∈ Om1 . If m , o, m , i ∈ Ch, then this is changed to m , o, m1 , i where for m1 ∈ Bm it holds that i ∈ Im1 . Lemma 1. All the configurations in Π(S, G, D, Ch) are information admissible if: the domain D only contains information admissible methods, G = (m) (a single method), and Im = ∅, that is m does not need any external input. Proof. From the definition of information admissibility in Eq. 1, we have that a configuration is information admissible if and only if each input of each functionality is connected via an adequate channel (ch ∈ Ch = (fsend , o, f, i)) to an output of another functionality fsend with a compatible specification (descr(o) = descr(i) and dom(o) = dom(i)). From the definition of information admissible methods we have that each input i of a functionality/method is provided either from a method msend in Bm via an internal channel (msend , o, f, i) or from Im . In the first case, if msend is a functionality, the condition is satisfied. If msend is a method, then it must also be information admissible and its output o must be connected to a submethod or functionality in the body of msend . Going down through methods, eventually we will reach a functionality fsend . In the second case, that is the input i comes from Im , then m must be enclosed in some other method m . m must also be an information admissible method, with either some method msend ∈ Bm connected to i ∈ Im (case 1) or with i connected to some i ∈ Im (case 2). As there is a finite sequence of methods enclosing f , if the second case keeps repeating itself the top method G will eventually be reached, and in G the input of msend will be connected to a method in BG . Lemma 2. All the configurations in Π(S, G, D, Ch) are causally admissible. Proof. Assume the contrary, that there exist a configuration in Π(S, G, D, Ch) that is causally inadmissible. We argue that this case can never occur. From the definition of causal admissibility in Eq. 2, we have that a configuration is causally admissible if and only if all functionalities in the configuration are applicable in the world state. To have a configuration causally inadmissible, it must be possible to add functionalities f to configurations for which the preconditions P rf (s) do not hold. Since the preconditions of all functionalities are known, and since the preconditions of a functionality is verified with the state, before it is added to a configuration (step 1 and 2), there cannot exist any causally inadmissible configurations in Π(S, G, D, Ch). Thus, all the configurations in Π(S, G, D, Ch) are causally admissible.

3.2

Configuration Algorithm

The configuration planner takes as input a current causal state s, a robot goal G with initially one unexpanded method instance α(a1 , a2 , ...), and a domain D. It also maintains an initially empty configuration description C and an initially empty set of causal postconditions P . It works as follows: 1. Take the first element α(a1 , a2 , ...) in G. 2. If α(a1 , a2 , ...) matches the Id of a functionality operator O, expand it, verify the preconditions and if they hold, add it to C, and add the clauses 9

in postcond to P . Go back to 1. If the preconditions do not hold, report failure. 3. If α(a1 , a2 , ...) matches a method schema in D, non-deterministically select an expansion m. (this is a backtrack point). If there is none, report failure and backtrack. 4. Expand m as follows: (a) Add the channels Chm to the current configuration C. (b) Add the functionality and method Ids in Bm to the top of G. (c) Use the in and out fields of the method to reconnect any channels in C as described in the definition of Π. 5. If G = ∅, return C, P . Otherwise go back to 1. Steps 3 and 4 may need some more explanation. Assume we are expanding get-door-info(robot1, door4), and we have chosen the method in Figure 3. First, we need to replace r with robot1 and d with door4 everywhere in the schema, and room is bound to the room of robot1 (step 3). The channel is added to C (step 4 a) and the two functionalities are added to the top of the stack (step 4 b). Finally, according to the out field, any existing channel in C with label f1 (i.e., get-door-info) for its out connection is reconnected to f2 (i.e., measure-door) (step 4 c). The first output from the planner is a configuration description C, which essentially consists of a set F of functionality names with labels used for connecting channels, e.g., l8: measure-door(robot1, door4), and set Ch of channels, e.g., (17, 18, image(robot1, door4)). The second output from the planner is the set of postconditions P , which can be used to update the current state, which then in turn can be used as input for generating the configuration following the current one (if any).

3.3

Formal Properties

We are now in a position to prove soundness, completeness and optimality for our configuration generation algorithm. We assume that the domain D is closed and finite, and G is a single method Id with no input. Theorem 1 (Soundness). If D only contains information admissible methods, then the configuration algorithm generates only admissible configurations. Proof. For a configuration to be admissible, it must be both information and causally admissible. For any given configuration problem P , Lemma 1 and Lemma 2 guarantee that all configurations in Π(P ) are both information and causally admissible if D only contains information admissible methods. Since the configuration algorithm is a straightforward implementation of the definition of Π(P ), it follows that it generates only admissible configurations. Theorem 2 (Completeness). The configuration algorithm eventually generates any admissible configuration that is defined by the functionalities and methods in D.

10

Proof. By definition, the set of all configurations for a given configuration problem P is given by Π(P ). The configuration algorithm is a straightforward implementation of the definition of Π(P ), and it performs a full search since D is finite. Hence, it eventually generates any configuration in Π(P ). By Lemma 1, this configuration is admissible. Since this it true for any P , we have the thesis. The configuration algorithm has been given in a non-deterministic form. To prove optimality, we must complement it with a search strategy. We use best first with branch-and-bound [Lawler and Wood, 1966], using the cost of the partial configuration as a lower bound and pruning when this exceeds the lowest cost among the complete configurations generated so far. Theorem 3 (Optimality). If the configuration algorithm uses best-first search with branch-and-bound, it finds the admissible configuration with the lowest cost that is defined by the functionalities and methods in D. Proof. Follows directly from the completeness of the algorithm, and from the use of branch-and-bound.

4

Planning with Least Commitment

The above algorithm always deals with completely instantiated configurations and methods. This can lead to problems of scalability, as there may be a large number of possible instantiations for a given method which all are isomorphic relative to the individuals (i.e., robots) involved. Each such instantiation leads to a new branch in the search tree of the planner. We get several instantiations of a method when the valid precondition of the method schema contains free variables (i.e., not bound as parameters) that can be bound in several different ways. For instance, in Figure 5, the variable r1 can be instantiated in several ways if there are several individuals in the domain that belong to the class robot. And if there are several free variables, then each combination of these will be explored separately by the planner. One of the contributions of this paper is a method to manage a large set of isomorphic configurations collectively, instead of separately. It is based on the introduction of virtual individuals, which can represent a set of actual individuals. We use virtual individuals as arguments to methods, functionalities and channels, and include in our configuration a mapping between virtual individuals and sets of actual individuals, as well as a set of constraints (inequality) on virtual individuals. Formally, let I be the set of individuals in s. A multi-configuration mc is a tuple F, Ch, V, V I, CV  where F and Ch are functionalities and channels, V is a set of virtual individuals, V I : V → P(I) and CV ⊂ {v1 = v2 |v1 , v2 ∈ V ∪ I} is a set of constraints on the virtual variables.2 A multi-configuration corresponds to a set of configurations, namely {F σ, Chσ|σ ∈ subst(V, V I) and CV σ holds.} where subst(V, V I) is the set of all substitutions [v1 /i1 , . . . , vn /in ] including all v ∈ V where ik ∈ V I(vk ). 2 Throughout the paper, we will only consider nonequality constraints. However, constraints that are evaluated in the state s, such as near(v1,v2) can in principle also be included.

11

Step 3 of the planning algorithm is extended as follows. (a) For each free variable in the precondition that can take on more than one value, introduce a new virtual individual v to V and set V I(v) to be the set of individuals that could be bound. (b) For the existing v ∈ V , filter from V I(v) all i which do not satisfy the preconditions (test only for unary predicates). If any new V I(v) = ∅, then report failure. (c) Add the binary conditions (inequalities) of the preconditions to CV . (d) Test that the binary conditions CV can be satisfied, using backtracking for constraint satisfaction. It is sufficient to verify that the constraints are satisfiable at this point. Step 2 is also extended by filtering V I according to the preconditions, and adding binary conditions to CV . Note that the cost need not be uniform over all instantiations of a multiconfiguration, so here one has to rely on lower bounds. This is possible to do efficiently if the cost of a configuration is defined as a sum of the cost of its components: simply choose the least expensive instantiation for each virtual individual. When an admissible multi-configuration has been found, the issue remains to find the best (lowest-cost) instantiation. This is a combinatorial optimization problem. The proofs for the formal properties can be generalized to apply to this extension of the algorithm as well: the same expansions (choice of alternative methods, alternative bindings of free variables in preconditions) are still explored, only in a more compact manner. As we have a lower bound for cost in a multi-configuration, optimality can still be guaranteed.

5

Experiments

To test the scalability of the algorithm, we have conducted a series of generic experiments. Note that the experiments only address the scalability of the algorithm for generating the configurations, and not on the entire approach that of course also includes robot execution. In previous work [Lundh et al., 2006, 2007], experiments on the entire approach are reported. In the experiments, we test how the planning time and the number of used nodes are affected by the number of homogeneous/heterogeneous robots.The experiments were conducted on a Intel Pentium 4, 3 GHz, 1GB ram, running Allegro LISP under Windows. The different domains were automatically generated. Since we only test the algorithm and not the entire approach, the algorithm is run off-line on a stationary computer instead of on-line a robot as in normal cases. As mentioned above, the original algorithm in [Lundh et al., 2006] has problems with scalability of homogeneous robots, (for methods that are isomorphic with respect to the robots), since it must consider possible instantiations at expand time. Consider an example with a very basic domain with a method that needs 7 homogeneous robots. 1 robot is bound in advance and the 6 other robots, which are intended to provide information to the first robot, can be chosen freely from a pool of 6 available robots (not counting the first robot). For this example, the algorithm must at planning time consider all the 720 different combinations of selecting robots. Obviously, this is a very inefficient way to generate configurations. Just to generate these 720 configurations takes 135

12

Figure 4: The expansion hierarchy of methods (M) and functionalities (F) used in experiment I. seconds and 16560 nodes. We have conducted a series of experiments using the above least commitment planning algorithm, to demonstrate that this improves the scalability. The setup of the experiments is based on a very simple, but easy expandable domain (see Fig. 4). The domain consist of a main method (see Fig. 5) that can be extended to require more robots, a submethod get-result, and 3 different functionalities. To add a new robot to the experiment requires to update the preconditions, the channels, and the body of the main method. In the preconditions, we add that a new robot is required and that it cannot be the same robot as any of the other needed robots, e.g. (robot(r3), r =r3, r1 =r3, r2 =r3). In the channels, we add that a new channel is required between the new robot and the first robot, e.g. (f4, f1, result(r3)) and in the body we add a new method for the robot, e.g. f4: get-result(r3). In the experiment there is also a state that specifies how many robots are available. In Table 1, we present the time in seconds it takes to run different problems (including garbage collection). We also give the number of nodes used for the generating a configuration for the given number of needed robots (this is independent of the number of available robots). The results show a major improvement compared to the original algorithm. It is important to note that the improved algorithm generates a multiconfiguration, while the original algorithm generates each possible configuration separately. If we wanted to generate all possible configuration instances from a multiconfiguration, then we would have to solve a combinatorial problem which grows exponentially. However, in most practical cases it is enough to generate one configuration from a multi-configuration since the different combinations are considered isomorphic. For 200 robots (available and needed) this takes less (config-method name: do-scale-robots(r) precond: ( robot(r), robot(r1), robot(r2), r=r1, r=r2, r1=r2 ) channels: (f2, f1, result(r1)), (f3, f1, result(r2)) body: f1: scale-robots(r) f2: get-result(r1) f3: get-result(r2) )

Figure 5: An easily expandable method for 3 robots used in the scaling experiments. r is bound. r1 and r2 are free. 13

Needed robots 50 100 150 200

Available robots 50 100 150 200 0.5 1.1 1.9 2.9 6.3 9.0 12.6 28.3 37.5 90.7

Nodes 155 305 455 605

Table 1: Planning times in seconds and nodes used to generate a multiconfiguration for different combinations of available and needed robots. Alt. methods 2 3 4 5 6

5 0.01 0.4 1.7 3.3 16.9

6 0.1 1.7 11.9 112.8 -

Robots 7 0.4 10.4 289.7 -

8 0.8 96.0 -

9 2.0 -

Table 2: Execution time in s (including garbage collection). A dash - denotes that no solution was found before the planner ran out of memory. than half a second. Please note that the improvement of the algorithm to use least commitment planning only affects the scalability for homogeneous robots. If the robots are heterogeneous, the planner only finds one candidate for each needed robot, and the number of solutions do not grow exponentially. Thus, the performance of the original and the improved algorithm is similar for heterogeneous robots. Compared to the case with homogeneous robots, the planning time is much lower when the robots are heterogeneous, e.g., a configuration with 200 heterogeneous robots (and approx. 600 nodes) takes 1.8 seconds compared to 90.7 seconds if the robots are homogeneous. In the above experiments we tested how the algorithm scales with respect to robots used. In all of these experiments, there is only one method to achieve the requested information. To also demonstrate the limitations of the algorithm, we increase the complexity of the experiment to test how the robot scales for a worst case scenario. In addition to use homogeneous robots, every robot also have alternative applicable methods to achieve the same information (i.e., there are several alternative methods for get-result that are applicable). Thus, we have a set of homogeneous robots, and each selected robot has a number of ways to achieve its designated subgoal. Table 2 show the results of the experiments. When there is alternative methods, the complexity of the problem increases. The number of possible configurations is O(n! · mn ) where n is the number of homogeneous robots and m the number of redundant methods. To use different costs for the functionalities reduces the complexity slightly, as the search strategy employed will exclude the high-costing configurations. This analysis shows that when specifying a domain it is necessary to make a trade-off between flexibility and scalability of a domain. 14

Note that it may be questionable whether configurations involving as many as 200 robots are actually possible to execute. Therefore, we want to emphasize that our intention with these experiments was to test the scalability of the algorithm, and not the configuration approach as a whole. Said differently, even if there may be other obstacles today to forming really large configurations, this paper shows that complexity of our algorithm is not one of them.

6

Conclusions

We have presented and analyzed an algorithm to automatically synthesize a group configuration from a theoretical and empirical point of view. The algorithm combines functionalities, residing in different robots (or robotic devices), into a functional configuration, in which the robots cooperate to generate the information required to perform a certain task. From the theoretical point of view, we have proved the soundness, completeness and optimality of the algorithm. From the empirical point of view, we have performed experiments testing the scalability of the algorithm. One major contribution of this paper is an extension of the algorithm to use least commitment planning techniques. This extension reduces the complexity of the algorithm and the scalability improves dramatically. While the plan-based centralized approach has interesting properties, like the guaranteed correctness and optimality of the generated configurations, it has the usual problems of plan-based approaches: it requires full knowledge about the available functionalities and about the state of the world, and the generated configuration might not be correct any more if these data change after it was generated. In a related paper [Gritti et al., 2007], a reactive distributed approach to the self-configuration of an ecology of robots is explored, which might be more suitable for highly dynamic environments. Our next step will be to systematically compare these approaches, and to explore their integration.

References J. Bradbury, J. Cordy, J. Dingel, and M. Wermelinger. A survey of selfmanagement in dynamic software architechture specifications. In Proceedings of the International Workshop on Self-Managed Systems (WOSS’04), 2004. B. Gerkey and M. Matari´c. A formal analysis and taxonomy of task allocation in multi-robot systems. International Journal of Robotics Research, 23(9): 939–954, September 2004. M. Gritti, M. Broxvall, and A. Saffiotti. Reactive self-configuration of an ecology of robots. In the IEEE International Conference on Robotics and Automation (ICRA) workshop on Network Robot Systems, Rome, Italy, 2007. Y.K. Ha, J.C. Sohn, and Y.J. Cho. Automated integration of service robots into ubiquitous environments. In Proc of the 3rd Int Conf on Ubiquitous Robots and Ambient Intelligence, pages 177–182, 2006. D. Kim, S. Park, Y. Jin, H. Chang, Y.-S. Park, I.-Y. Ko, K. Lee, J. Lee, Y.-C. Park, and S. Lee. SHAGE: a framework for self-managed robot software. 15

In ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), 2006. J.H. Kim, Y.D. Kim, and K.H. Lee. The third generation of robotics: Ubiquitous robot. In Proceedings of the 2nd International Conference on Autonomous Robots and Agents (ICARA), Palmerston North, New Zealand, 2004. E. L. Lawler and D. E. Wood. Branch-and-bound methods: a survey. Operations Research, 14:699–719, 1966. R. Lundh, L. Karlsson, and A. Saffiotti. Plan-based configuration of a group of robots. In Proceedings of the European Conference of Artificial Intelligence ECAI-06, August 2006. R. Lundh, L. Karlsson, and A. Saffiotti. Plan-based configuration of an ecology of robots. In Proceedings of the International Conference on Robotics and Automation (ICRA), Rome, Italy, April 2007. B. Morisset, G. Infante, M. Ghallab, and F. Ingrand. Robel: Synthesizing and controlling complex robust robot behaviors. In Proceedings of the Fourth International Cognitive Robotics Workshop, (CogRob 2004), pages 18–23, August 2004. D. Nau, Y. Cao, A. Lothem, and H. Munoz-Avila. SHOP: simple hierarchical ordered planner. In Proceedings of the International Joint Conference on Artificial Intelligence (IJCAI), 1999. Network Robot Forum. www.scat.or.jp/nrf/English/, 2007. L. E. Parker and F. Tang. Building multi-robot coalitions through automated task solution synthesis. Proceedings of the IEEE, 94(7):1289–1305, 2006. J. Rao and X. Su. A survey of automated web service composition methods. In Proceedings of the First International Workshop on Semantic Web Services and Web Process Composition (SWSWPC), San Diego, California, USA, July 2004. A. Saffiotti and M. Broxvall. PEIS ecologies: Ambient intelligence meets autonomous robotics. In Proceedings of the International Conference on Smart Objects and Ambient Intelligence (sOc-EUSAI), pages 275–280, Grenoble, France, 2005. O. Shehory and S. Kraus. Methods for task allocation via agent coalition formation. Artificial Intelligence, 101:165–200, 1998. C. Shekhar, S. Moisan, R. Vincent, P. Burlina, and R. Chellappa. Knowledgebased control of vision systems. Image and Vision Computing, 17:667–683, 1998. Daniel S. Weld. An introduction to least commitment planning. AI Magazine, 15(4):27–61, 1994.

16