Email: {parker|ftang}@cs.utk.edu. AbstractâThis paper describes a methodology for automat- ically synthesizing task solutions for heterogeneous multi-robot.
Coalescent Multi-Robot Teaming through Automated Task Solution Synthesis Lynne E. Parker and Fang Tang Distributed Intelligence Laboratory, Department of Computer Science, The University of Tennessee, Knoxville Email: {parker|ftang}@cs.utk.edu
Abstract— This paper describes a methodology for automatically synthesizing task solutions for heterogeneous multi-robot teams. In contrast to prior approaches that require a manual predefinition of how the robot team will accomplish its task (while perhaps automating who performs which task), our approach automates both the how and the who to generate task solution approaches that were not explicitly defined by the designer a priori. Our approach, which we call ASyMTRe, is based on mapping environmental, perceptual, and motor control schemas to the required flow of information through the multi-robot system, automatically reconfiguring the connections of schemas within and across robots to synthesize valid and efficient multi-robot behaviors for accomplishing the team objectives. We present the anytime ASyMTRe configuration algorithm, proving that the configuration algorithm is correct, and formally addressing issues of completeness and optimality. We then validate the approach by presenting the results of applying our methodology to two different teaming scenarios: multi-robot transportation, and multirobot box pushing. The advantages of this new approach are that it: (1) enables the robot team to synthesize new task solutions that use fundamentally different combinations of robot behaviors for different team compositions, and (2) provides a general mechanism for sharing sensory information across networked robots, so that more capable robots can assist less capable robots in accomplishing their objectives.
I. I NTRODUCTION A challenging class of multi-robot applications is that which requires multiple robots to coalesce into teams to solve a single task by coordinating the sharing of sensory and effector capabilities. In the most difficult of these problems, the method for solving the task, sometimes called task decomposition, is dependent on the available capabilities of the multi-robot team, and thus cannot be specified a priori. In these cases, the team must determine how to solve the task by coupling the appropriate sensory and effector capabilities from each robot, perhaps resulting in actions for each robot team member that are tightly coupled with those of other team members. Even more challenging, one or more robot team members could act based upon sensory data shared from other robots, perhaps translated into its own frame of reference. In the formal multirobot task allocation (MRTA) framework of [6], this class of problems involves “Single-Task” robots (ST), “Multi-Robot” tasks (MR), and “Instantaneous Assignment” (IA), abbreviated ST-MR-IA. For such problems, it is challenging to create robot behavior code that is flexible enough to solve tasks in a variety ways. For example, as outlined in [12], the types of behaviors needed to deploy a mobile sensor network are shown to be highly
dependent upon the total robot team composition. For homogeneous robots with the ability to detect obstacles and other team members, a potential-field-based dispersion algorithm is appropriate to achieve mobile sensor network deployment (e.g., [8]). For teams involving a highly capable “mother ship” robot and many simple sensor nodes, deployment using a marsupial delivery method is appropriate. For teams with a few robots that can perform laser localization, obstacle avoidance, and visual detection of teammates, plus many simpler robots that do not have these capabilities, an assistive navigation approach is appropriate, in which the more capable robots assist in the navigation of the simpler robots (e.g., [13]). The important point here is that the resulting robot behaviors for accomplishing the task could be dramatically different depending upon the combination of sensors that is available for solving the task. Ideally, we would like to design the behavior code for an individual robot to be independent of any particular robot team composition, towards the goal of flexible, reusable robot behaviors. To address this class of multi-robot problems, we are developing an approach, called ASyMTRe (Automated Synthesis of Multi-robot Task solutions through software Reconfiguration, pronounced “Asymmetry”), which provides general mechanisms for coalescent multi-robot teams to: (1) synthesize single task solutions based upon the current team composition, (2) share sensory information across networked robots, as required to accomplish the task, and (3) automatically instantiate these task solutions directly into executable robot code. This approach is a type of coalition formation (e.g., [14]), which has been extensively studied in the multi-agent community, and is also beginning to be addressed in the multi-robot community (e.g., [16]). However, our work goes beyond the mapping of agent/robot capabilities to tasks and finding the best combination of agents/robots for the task. ASyMTRe also defines mechanisms based on schema theory and the mapping of schemas to information types (inspired by the information theoretic work of [4]) to enable robot team members to share sensory information across robots, and to enable robots to automatically instantiate the derived team solution into executable code on the robot team members. The rest of this paper is organized as follows. Section II describes the ASyMTRe solution approach. Section III analyzes the theoretical soundness, completeness, and optimality of this approach. Section IV describes the experimental results that validate our approach. We present a review of related work in
TABLE I C ONNECTION C ONSTRAINTS FOR SCHEMAS Sensor/Schema ES PS CS MS
Input Sources: Sensor Signals ES PS, or CS PS, CS, or ES
Output Feeds into: PS PS, CS or MS PS, CS, or MS Actuators
Section V and conclude in Section VI. II. T HE AS Y MTR E A PPROACH A. Schema Theory and Information Types Our approach is based on a distributed extension to schema theory. As such, the basic building blocks of our approach are collections of environmental sensors (ES), perceptual schemas (PS) [9], motor schemas (MS) [1], and a simple new component we introduce, called communication schemas (CS). Perceptual schemas process input from environmental sensors to provide information to motor schemas, which then generate an output control vector corresponding to the way the robot should move in response to the perceived stimuli. Communication schemas transfer information between various schemas distributed across multiple robots. All of these schemas are assumed to be pre-programmed into the robots at design time, and represent fundamental individual capabilities of the robots. ASyMTRe allows robots to reason about how to solve an application based upon the fundamental information needed to accomplish the task. The information needed to activate a certain schema remains the same regardless of the way that the robot may obtain or generate it. Thus, we can label inputs and outputs of all schemas with a set of information types that are unique to the task. In our system, we define the inputs and outputs of the schemas to belong to the set of information types F = {F1 , F2 , ...}. For schema Si , I Si and OSi ⊂ F , represent the set of input and output of Si , respectively. We assume that a schema has one output but can have multiple inputs. Additionally, we define “OR” and “AND” conditions corresponding to multiple inputs to a schema. For some schemas, only one of the specified inputs is needed, corresponding to the “OR” condition. For other schemas, all indicated inputs are needed to produce an result, corresponding to the “AND” condition. Using the mapping from schemas to information types, robots can collaborate to define different task strategies in terms of the required flow of information in the system. ASyMTRe uses solution quality as a metric to automatically configure the proper connections between the sensors and the schemas across multiple robots to ensure that the team-level goals are achieved with a highutility solution. Once the interconnections between schema are established, the robot team members have executable code to accomplish their task. Given a set of n robots and a task T, the solution configuration problem can be represented as (R, T, U ), where R = {R1 , R2 , · · · , Rn } is the set of n robots, T = {M S1 , M S2 , · · ·} is the set of motor schemas that define the team-level task to be achieved, along with application-specific
parameters as needed1 , and U provides utility information to be defined later. A robot, Ri , is represented by Ri = (ES i , S i ). ES i is a set of environmental sensors that are i installed on Ri , where OESj ⊂ F is the output of ESji . S i is the set of schemas that are pre-programmed into Ri at design i i time. Each schema is represented by Sji = (Sji , I Sj , OSj ). A schema can be activated if and only if its input can be obtained from the output of another schema or sensor. Specifically, a set of Connection Constraints are used to regulate the connections between schemas. As shown in Table I, the constraints specify the restrictions on correct connections between various schemas. Given the above information, the problem (R, T, U ) has a solution if and only if for each Ri ∈ R and for all M Sj ∈ T , the inputs of M Sj are satisfied, along with all the inputs from the schemas that feed into M Sj . A solution is a combination of schemas that can satisfy the above requirements. To measure the quality of the solution, we define a sensoricomputational system (SCS) [4], which is a module that computes a function of its sensory inputs. In our system, this is represented as SCSji = (Sji , ESji ), where Sji is the jth P S/CS on Ri . Each SCSji has an associated cost Cji and a success probability Pji . The utility function for Ri ’s contribution to the solution is defined as: X (w · 1/Cji + (1 − w) · Pji ) (1) Ui = j
where w is the weight of the sensing cost relative to the success probability. The metric sums over all the SCSj that Ri needs to activate to accomplish a task. The utility of a complete solution P is the sum of the individual robot utilities, which is U = i Ui . In summary, the problem we study here is: Given a problem (R, T, U ), what is the solution (consisting of a distributed configuration of schemas) such that the total utility U is maximized? B. Potential Configuration Space (PCS) When a group of robots is brought together to accomplish a task, each with its unique sensors and corresponding schemas, one way to solve the problem is to perform an exhaustive search of all the possible combinations of schemas within or across robots. We refer to this complete space as the Original Configuration Space (OCS). However, the number of possible connections in the OCS is exponentially large in the number of robots. In the general case, the robots will be developed separately, and it is highly possible that the schemas with the same functionality are represented differently on different robots. By definition, schemas Si and Sj are of the same functionality, func(Si ) = func(Sj ), and are thus in the same equivalence class, if and only if I Si = I Sj and OSi = OSj . To reduce the size of the search space, we generate a reduced configuration space, called the Potential Configuration Space (PCS), by including only one entry for each equivalence class 1 In continuing work, we are developing a more general and complete way of defining the team task, similar to the formal specification of tasks in [5].
Fig. 1. Step I: Reduce the OCS to the PCS by creating one entry per schema equivalence class. Step II: Generate the list of potential solutions based on the schemas in the PCS Step III: Instantiate the selected potential solutions on specific robots. Assume T = {M S11 , M S12 }, func(P Ski ) = func(P Skj ), func(CSki ) = func(CSkj ), and func(M Ski ) = func(M Skj ).
of schema. The extent of the size reduction that we achieve depends upon the specific team composition, and the degree of overlap in their capabilities. Step I in Figure 1 shows an example of reducing the configuration space. Assume, without loss of generality, that the team is composed of n robots, each of which has h schemas, and each schema requires k inputs. The OCS is of size is O((nhk)nh ). After the reduction, 0 the PCS is of size O((h0 k)h ), where h0 is the number of equivalence classes, and h0 < nh. This analysis assumes that every output of any schema can be a potential input of any schema. In practice, the size of the PCS is even smaller because of the connection constraints shown in Table I. Theorem 1: If a solution exists in the OCS, it must exist in the PCS. Proof: Assume to the contrary that one of the solutions present in the OCS does not exist in the PCS. Recall that a solution is a combination of schemas. This could only occur if at least one schema Si in the solution does not exist in the PCS, which means there exists an Si in the OCS, but there does not exist an Sj in the PCS such that func(Si ) = func(Sj ). According to the definition of the PCS, there will be one entry for each equivalence class of schema. Thus, there cannot be a solution in the OCS that does not exist in the PCS. C. Instantiation on Robot Teams After the PCS is generated, the ASyMTRe configuration algorithm searches through the PCS to generate a list of potential solutions for each robot, where each solution is a combination of schemas in the PCS. As shown in Theorem 1, the algorithm will not miss any solutions by searching in the PCS. Once solutions are found in the PCS, we still need to map them back to the OCS and instantiate them on robots by translating the schemas in the solutions into robot-specific schemas. Steps II and III in Figure 1 demonstrate an example of the instantiation process. It is important to note that the list of potential solutions are for each robot, not for the entire task. As shown in the figure, the solutions are independent for each M S ∈ T .
The configuration process involves greedily searching through the list of potential solutions and selecting the solution with the maximum local utility from each robot’s perspective. Suppose the algorithm eventually assigns a solution to every robot Ri with P an utility Ui . Our goal is to maximize the total utility i Ui . In practice, we also impose a maximum cooperation size constraint on the algorithm, to reduce the complexity of the robots executing the resulting solution. In considering potential solutions, the exhaustive, brute force approach would involve enumerating all possible P orderings of robots and selecting the one that maximizes i Ui . However, this approach could be impractical since the complexity is O(n!), where n is the number of robots. Therefore, we impose an additional heuristic on the search process, which is the ordering in which robots are considered by the algorithm. At the beginning, we heuristically define two special orderings with which we begin the search, to increase the likelihood of generating a quality result. The first ordering sorts robots according to increasing robot sensing capabilities. Less capable robots are considered first because it is relatively easy to find a solution when the sensing resources are abundant. Our second ordering sorts robots by the number of other robots that they can cooperate with. Thus, robots with fewer other robots to cooperate with will have the chance to find their collaborators earlier in the search process. An anytime algorithm [18] can be applied here, since it can provide a satisfactory answer within a short time and its quality of results can be improved given more time. In our domain, the algorithm first generates an ordering of robots with which the algorithm can configure solutions, and then reports the solution if its utility is higher than the previous one. If more time is available, another ordering of robots can be generated and the above procedure is repeated until the deadline is reached. The algorithm will report the solution with the highest utility it has found so far or report no solution if one does not exist. Since we have a finite number of robots and a finite solution space, the algorithm will ultimately find the optimal solution if there exists one, given sufficient search time. D. The ASyMTRe Configuration Algorithm All of the previously described aspects of the ASyMTRe approach are combined to yield the centralized ASyMTRe configuration algorithm shown in Table II2 . With every ordering, the algorithm starts to configure solutions on robots. Each potential solution is tested and the utility of the solution is maximized from every robot’s perspective. If a robot does not have the required sensing resources to accomplish a goal, the algorithm checks the other robots to see if they can provide the required information. Among the robots that provide the information with the highest utility, the robot with the least sensing capability is selected. Therefore, robots with more sensor resources are saved for future configuration. After every robot has been assigned a solution, the algorithm calculates the team utility and replaces the previous solution 2 Our current work involves developing a distributed version of this algorithm, which can deal with incomplete information.
TABLE II T HE AS Y MTR E C ONFIGURATION A LGORITHM The ASyMTRe Configuration Algorithm ((R, T, U), Deadline) (R, T, U): the robot team composition, task, and utility n: the number of robots in the team m: the number of configurations to accomplish the task k: a constant, which specifies the number of iterations
1) Generate the PCS based on equivalence classes. [O(n)] 2) Generate a list of potential solutions of size m by connecting schemas in the PCS to satisfy the task’s requirements. 3) Sort the robot team members according to increasing sensing capabilities. [O(nlog(n))] 4) Configure solutions on the robot team: [O(kmn2 )] • For each robot Ri , according to the current ordering: [O(n)] – For each potential solution j to accomplish the task: [O(m)] ∗ If Ri can accomplish the task by itself, assign solution j to Ri . [O(1)] ∗ Else check the other n−1 robots to see if one can provide the needed information. [O(n)] ∗ If the estimated utility Ui of Ri using solution j is greater than the utility of its previous solution, and the constraints on cooperation size are satisfied, update the solution strategy on Ri . [O(1)] • Continue the above process until: – All the robot team members can accomplish the task. – Or, after k number of trials. • Calculate the team utility U. If U is greater than the utility of previous solutions, update them. • If the special ordering (according to increasing number of potential robots that a robot can cooperate with) has not been checked yet, sort the team by this ordering and repeat the above process. Otherwise, if more time is available, generate another ordering of robots and repeat the above process. 5) If a solution exists, report the current best solution. Otherwise, report “Failure”.
if the utility of the current solution is higher. At this point, if the algorithm is given more time, it continues by generating another random ordering of robots and repeats the configuration process. This process will continue until the deadline is reached. The algorithm will report the current best solution it has computed so far, or it will report “failure” in two cases: (1) cannot find a solution given the deadline, or (2) there does not exist a solution to the problem. III. A LGORITHM A NALYSIS We now analyze the soundness, completeness, and optimality of the ASyMTRe configuration algorithm. A. Soundness Theorem 2: The ASyMTRe configuration algorithm is correct. Proof: Assume to the contrary that the algorithm is not correct. This could occur in two ways: (1) At least one of the
connections made is not a valid connection; (2) Not all needed connections are made to compose a solution. We argue that these two cases will not occur. First, an output of a schema Si can be connected to an input of a schema Sj if and only if OSi = IjSk , which means the output of Si has the same information type as one of the input required by Sj . Since we know all the input and output information types for every schema, and we maintain the connection constraints that specify the types of schema connections that the system allows, it is not possible to generate an invalid connection. Second, a potential solution is a combination of schemas such that the inputs for each M Si ∈ T are satisfied, along with all the inputs from the schemas that feed into M Si . Since the algorithm complies with this standard, all needed connections will be made to become a potential solution. Thus a solution generated by ASyMTRe will be a correct solution. B. Completeness and Optimality Since the algorithm always selects the locally best solution for every robot, it acts as a greedy search algorithm and thus suffers from the well-known problems of greedy algorithms. Namely, in our domain, the ordering in which the robots are considered may cause the system to miss solutions, even though sufficient sensor resources exist to accomplish the task. To avoid missing solutions, the algorithm continually reorders the robots until a solution is found or all orderings are exhausted. Theorem 3: The ASyMTRe configuration algorithm is complete and optimal given enough time. Proof: We prove completeness and optimality by showing that the algorithm can search the entire solution space given enough time. Step 4 (in Table II) shows the major configuration process in which, given an ordering of robots, the algorithm searches through the list of potential solutions to find solutions for every team member. If the algorithm is given enough time, it will ultimately test all possible orderings of robots, which is O(n!), and reports the solution with the highest utility. Since the solution space is eventually explored in its entirety by the algorithm, it is complete and optimal, given enough time. Despite this proof, we note that in reality, practical constraints require a fast response, especially when dealing with failures that require quick reconfiguration. Since the problem itself is NP-complete and the worst case time complexity is O(n!), it is not possible to generate an optimal solution in practice when n is large. However, in our experiments, the algorithm has always been able to return a good solution for the team within a few (5) seconds. IV. E XPERIMENTAL R ESULTS We have claimed that the ASyMTRe approach can enable the robot team to find a task solution automatically based on the flow of information in the system. We validate this claim in two experimental tasks: multi-robot transportation and box pushing. In each task, in order to validate the reasoning system, robots with different sensing capabilities are brought together
to form a team. The experiments focus on two aspects of the team: the number of robots n and the heterogeneity of robots. In our experiments, n varied from 2 to 100. To measure the diversity of the robot team, we calculate H, the simple social entropy metric of the team [2]. The value of H measures the diversity of the robot team and depends on the number of homogeneous subteams it contains and the proportion of robots in each subteam. This measure is directly proportional to the diversity of the team, with higher values representing higher diversity. For the sensing capability of the robots, we assume every robot has the ability to communicate. A. Task 1: Multi-Robot Transportation 1) Task description: In this application, a team of robots must navigate from their starting positions to a set of goal positions (one per robot) defined in a global coordinate reference frame. Assume that all the robots are programmed with the motor schema go-to-goal, which moves the robot from its current position to a goal position, defined in a global coordinate reference frame. To successfully use this motor schema, a robot must be able to perceive its own current position relative to its goal. If every robot team member can localize itself, obviously the solution is to have every robot navigate independently. However, on some teams, there might be robots that do not have the sensing and behavior capabilities to localize (e.g., see [13]); they need help from more capable robots to provide the information needed to fulfill the task. In the following paragraphs, we detail the application by introducing the environmental sensors and various schema used in this application. The environmental sensors are: laser scanner with an environmental map (laser), omnidirectional camera (camera), DGPS, and communication sensor (comm), providing up to 23 different combinations of robot capabilities. The different types of robots are shown in Table IV. Here, a robot of type 1 or 4 cannot localize by itself since it has neither laser nor DGPS. The functionalities of the perceptual schemas, communication schemas and motor schemas are defined in Table III. We assume: • A robot with a laser and an environmental map can estimate its current global position in the environment. • A robot with a DGPS can estimate its current global position in the environment. • A robot with a camera or laser can estimate the relative position of another robot in the environment, as long as the other robot is within its sensing range. • A robot has the computational ability to convert a relative position to a global position. From the description of the task, we define a set of information F = {Self Global Position, Other Global Position}. Table III shows the input and output information for each schema used in this application. According to the flow of information, the configuration algorithm generates all the possible connections that can connect the available schemas and lead the robot to achieve its goal. Assuming that all the robots have communication capabilities, two specific connections are
Fig. 2. One solution for connecting the schemas to accomplish the “navigate” goal. This solution involves R1 using its laser to globally localize itself and to calculate a relative position of R2 . With this information, R1 can calculate the global position of R2 and communicate this information to R2 , for its use in moving to its goal position.
Fig. 3. A second solution for connecting the schemas to accomplish the “navigate” goal. This solution involves R1 using its DGPS to globally localize itself, and then communicating this information to R2 . R2 uses camera to calculate the relative position of R1 , and then combines this with R1 ’s communicated global position to determine its global position.
shown in Figures 2 and 3. Initially, there are no connections between schemas. After the solution is generated, proper sensors are activated, and the schemas are connected, based on the connection constraints in Table I. As an example, in Figure 2, the output of PS1 is connected to the input of M S1 because we have OP S1 = I1M S1 = Self Global Position. 2) The reasoning process: After searching through all possible connections of schemas, the system generates several methods to accomplish the navigation task: 1) A robot Ri can navigate using laser or DGPS. 2) A robot Rj can navigate if there is another robot Ri that can navigate and estimate the global position of Rj using laser or camera. 3) A robot Rj can navigate if there is another robot Ri that can navigate, and Rj can use camera to estimate Ri ’s relative position and calculate its own global position. With multiple solutions available, a robot needs to determine which solution it should use. This is decided by each robot’s current sensing capability and the estimated utility of the particular solution it chooses. The utility is calculated by the combination of sensing costs and success probabilities. Typically, the sensing cost is determined by the sensory and computational requirements of the solution. Perceptual processes with a significant amount of sensor processing, such as laser scan matching or image processing, are given higher sensing costs. Perceptual processes with a relatively low processing requirement, such as DGPS, are assigned lower sensing costs. Success probability is an estimated value
TABLE III P ERCEPTUAL SCHEMAS , COMMUNICATION SCHEMAS , AND MOTOR SCHEMAS IN MULTI - ROBOT TRANSPORTATION TASK Schema P S1 P S2 P S3
P S4 CS1 CS2 CS3 CS4 M S1
Description Calculates self global position Calculates self goal position Calculates global position of another robot Calculates self global position according to the detected relative position of another robot and the global position of the same robot Communicates self global position to another robot Communicates global position of another robot to that robot Receives global position of another robot Receives global position of itself from another robot Go-to-goal schema that calculates motor command that leads the robot towards the goal.
Input Laser or DGPS Hardcoded Laser or camera and Self Global Position Camera and Other Global Position Self Global Position Other Global Position Other Global Position Self Global Position Self Global Position and Goal Position
Output Self Global Position Goal Position Other Global Position Self Global Position Other Global Position Self Global Position Other Global Position Self Global Position Motor commands
TABLE IV E IGHT TYPES OF ROBOT WITH DIFFERENT SENSING CAPABILITIES Type 1 2 3 4 5 6 7 8
Available Sensor(s) comm DGPS, comm laser, comm camera, comm DGPS, laser, comm DGPS, camera, comm laser, camera, comm DGPS, laser, camera, comm
Fig. 4. Case 1: The initial setup of the two pioneers robots is on the left. The result when the two robots reach their goal points is shown on the right.
based upon experiences. Perceptual processes that are easily influenced by environmental factors, such as image processing under different lighting conditions, are given lower success probabilities. Otherwise, they are given higher success probabilities. 3) Results of Multi-Robot Transportation: We present three cases, varying the robot team size, n, and the team member capabilities, measured by the simple social entropy metric, H. Case 1, n = 2, H = 1.0. We first describe a simple case, where the robot team is composed of only two robots from type 3 and 4 respectively. The solution generated is obvious: the robot with laser can navigate by itself, while it helps the robot with camera navigate by method 2 or 3, depending on the weight factor. This particular example has been successfully implemented on two Pioneer robots in [3]. Case 2, n = 6, H = 1.58 (out of max 2.58). In this case, the robot team is composed of six robots, with two each of types 1, 2, and 4. If the maximum number of robots allowed in a subteam is 3 and the maximum number of robots that any robot
Fig. 5. Results of ASyMTRe applied to Case 2, in which the team is composed of six robots from three different types. According to the automated software reconfiguration process, the team is divided into two subteams to accomplish the transportation task.
can help is 1, the solution is shown in Figure 5. The team is divided into two subteams, each of which has three robots from each type. The team is moving forward along the direction of the arrow. There are physical constraints, such as the camera’s field of view. At the beginning, we need to manually place the robots into proper positions so that the constraints are satisfied. (In future work, we plan to build in automated mechanisms to handle maintaining appropriate fields of view.) For instance, R3 and R1 must be in the field of view of R5 . In subteam 1, R3 with a DGPS localizes by itself using method 1, and it helps R5 with a camera localize using method 3. After R5 has been helped, it helps R1 localize using method 2. A similar situation occurs with subteam 2. Case 3, n = 99, H = 1.58 (out of max 2.58). To test the adaptability of the reasoning system, we applied it to a robot team of size 99. To make the setup easier, we still use the three types of robots from type 1, 2, 4, respectively, but we duplicate them 33 times. For the parameters, we have the same setup as in case 2, where the size of the subteam is 3. The reasoning system generates the result in less than one second. It divides the team into 33 subteams, and each with three different types. The result is the same as is shown in Figure 5, except that it has 33 subteams. B. Task 2: Cooperative Box Pushing 1) Task description: Cooperative box pushing was studied by Donald, et al. [4] in the development of information invariants for analyzing the complexity of alternative cooperation algorithms. To illustrate the connection of our approach to
TABLE V P ERCEPTUAL SCHEMAS , COMMUNICATION SCHEMAS , AND MOTOR SCHEMAS IN MULTI - ROBOT BOX PUSHING Schema P S1 P S2 P S3 P S4 CS1 M S1 M S2
Description Computes the force when pushing a box Computes the relative displacement when pushing a box Computes the angle between the line of pushing and the actual moving direction Computes the vector of the box relative to the pusher robot Communicates information from one robot to another The Push schema which computes the motor commands needed for the robot to push a box along a line Move along with the box, so that the helper robot can keep track of the box and the pusher robots.
Fig. 6. One solution for connecting the schemas to accomplish the “Push” goal. This solution involves R1 using its laser to perceive the relative vector of the box, and then communicating this information to the pusher robots.
the theory of information invariants, we have defined our box pushing experimentation in a similar manner to [4]. The goal is to organize the team into subteams, such that each subteam is able to push a box with exactly two robots3 , which we call pusher robots. Assume that all the robots are programmed with the motor schema Push, which pushes the box along a straight line. To use this motor schema, a robot must be able to perceive the box’s vector relative to itself. Here, the relative vector includes the applied force, relative displacements, the angle between the actual pushing direction and the line of pushing. For example, the two pusher robots can record the relative displacements while they are pushing the box, and by comparing these two values, they can decide which robot should push harder. We define five environmental sensors for this task, as follows: laser, camera, gripper, bumper, and odometry. These sensors define 25 possible robot capabilities. Three methods were presented in [4] to push a box with two robots, which we use here. In addition, we generate another method here where the pusher robots do not have the capabilities to perceive the relative vector of the box, while a helper robot helps them get this information. The alternative cooperative box pushing methods are as follows: 1) Using bumper, two robots can compute their applied forces and communicate this information to each other, allowing them to decide which robot should push harder. 2) Using odometry, two robots can compute the relative displacements along the line of pushing; they exchange the location information and take actions to reduce the difference between the relative displacements. 3 This
can be generalized to an arbitrary number of robots.
Input Bumper Odometry Gripper Laser or Camera Fi force, displacement, angle, or box relative vector box relative vector
Output force displacement angle box relative vector Fi Motor commands Motor commands
3) Using special grippers, two robots can compute the angles between the line of pushing and its actual moving direction; they take actions to reduce its angle on the next step – no explicit communication is needed in this case. 4) Using a laser or camera, a helper robot can help the pusher robots calculate the relative vector of the box, enabling the pusher robots to take appropriate actions. The information set in the box pushing application is F ={force, displacement, angle, box relative vector}. Various schemas and their input and output information are defined in Table V. The reasoning process is similar to the multi-robot transportation application, which generates software schema connections based on the connection rules. Figure 6 shows one of the connections that enables the robots to push a box. The result is the decomposition of the team such that each subteam can accomplish the task. To calculate the utility, we assume that the sensing costs and success probabilities for {gripper, bumper, odometry} are the same. The only difference is laser and camera, in which the values are the same as the multi-robot transportation application. 2) Results of Box Pushing: To demonstrate how the box pushing task can be achieved, we selected a team of 7 robots from 6 different types, as shown in Table VI. The simple social entropy is 2.52, out of a maximum 2.81. Figure 7 presents the results, in which the team is divided into three subteams. In subteam 1, robot R1 and R4 push the box together. Since R1 cannot perceive the box’s relative vector by itself, they are helped by R5 using either laser or camera. In subteam 2, robot R3 and R6 push the box together using method 2, since they both have odometry. In subteam 3, robot R2 and R7 push the box together using method 1, since they both have bumper. The team has been divided into several subteams and each subteam can fulfill the box pushing task. We notice that in subteam 1, R5 can use either laser or camera to help the pusher robots. The correct choice depends on its utility of using a certain sensor. In this example, if we focus on sensing cost, camera is a better choice. Otherwise, if we focus on the success probability, laser is a better choice. V. R ELATED W ORK Research specific to heterogeneous robots often focuses on the issue of task allocation, which is the problem of
TABLE VI B OX PUSHING : ROBOT TEAM COMPOSITION Robot R1 R2 R3 R4 R5 R6 , R7
Environmental Sensor(s) comm bumper, comm odometry, comm gripper, comm laser, camera, comm bumper, gripper, odometry, comm
task. We have shown that the centralized ASyMTRe configuration algorithm is sound, complete and optimal given enough time. Experimental results from two domains were presented to validate our approach. Our ongoing work includes developing a distributed version of ASyMTRe to enable the approach to deal with incomplete information distributed across multiple team members. We are also formally considering motion constraints in the reasoning process to facilitate physical robot implementation. R EFERENCES
Fig. 7. Results of applying ASyMTRe to an instance of the box pushing task, in which the team is composed of seven robots from six different types. The team is autonomously divided into three subteams, and each heterogeneous subteam can successfully push a box.
determining a suitable mapping between robots and tasks. Several approaches have been developed in the last decade. Since it has been shown that developing the optimal mapping of tasks to robots is NP-hard [11], existing mechanisms for multi-robot task allocation use some type of heuristic greedy strategy to achieve the mapping (e.g., [10], [17], [7], [19]). Another approach is for the human designer to subdivide the application into roles that define action strategies for achieving part of the application. Robot team members then determine autonomously which robots should perform which roles. Collaborative architectures provide general mechanisms to coordinate the robots depending upon the requirements of the roles they are fulfilling and the types of collaboration that are necessary (e.g., [15]). Other related work regarding coalition formation was discussed in Section I. Our representation of the robot capabilities is similar to that used in STRIPS planning, although we abstract the problem in a very different manner. In common STRIPS planning, the robot capabilities are usually represented by predicates such as Has(laser) and Action(Goto), which requires solution strategies to be previously incorporated into the STRIPS rules. We represent the capabilities at the level of schema, which allows the planner to be independent of precompiled solution strategies, enabling ASyMTRe to generate how to solve tasks in a much more general manner. VI. C ONCLUSIONS AND F UTURE W ORK This paper has presented ASyMTRe – a mechanism for the automatic generation of task solution for heterogeneous robot teams. Built upon schema and information invariants theories, our approach enables the robot team to dynamically connect schemas within and across robots to accomplish a
[1] R. C. Arkin, T. Balch, and E. Nitz. Communication of behavioral state in multi-agent retrieval tasks. In Proceedings of the 1993 International Conference on Robotics and Automation, pages 588–594, 1993. [2] T. Balch. Hierarchic social entropy: An information theoretic measure of robot team diversity. Autonomous Robots, 8(3):209–238, 2000. [3] M. Chandra. Software reconfigurability for heterogeneous robot cooperation. Master’s thesis, Department of Computer Science, University of Tennessee, 2004. [4] B. R. Donald, J. Jennings, and D. Rus. Information invariants for distributed manipulation. International Journal of Robotics Research, 16(5):673–702, 1997. [5] C. H. Fua, S. S. Ge, and K. W. Lim. Boas: Backoff adaptive scheme for task allocation with fault tolerance and uncertainty management. In Proceedings of the IEEE Intl. Symposium on Intelligent Control, Taipei, Taiwan, September 2004. [6] B. Gerkey and M. J. Mataric. A formal analysis and taxonomy of task allocation in multi-robot systems. International Journal of Robotics Research, 23(9):939–954, 2004. [7] B. P. Gerkey and M. J. Mataric. Sold! auction methods for multirobot coordination. IEEE Transactions on Robotics and Automation, 18(5):758–768, 2002. [8] A. Howard, M. J. Mataric, and G. S. Sukhatme. Mobile sensor network deployment using potential fields: A distributed scalable solution to the area coverage problem. In Distributed Autonomous Robotic Systems 5: Proceedings of the Sixth International Symposium on Distributed Autonomous Robotic Systems (DARS 2002), pages 299–308. SpringerVerlag, 2002. [9] R. Murphy. Introduction to AI Robotics. The MIT Press, Cambridge, MA, 2000. [10] L. E. Parker. ALLIANCE: An architecture for fault-tolerant multirobot cooperation. IEEE Transactions on Robotics and Automation, 14(2):220–240, 1998. [11] L. E. Parker. Toward the automated synthesis of cooperative mobile robot teams. In Proceedings of SPIE Sensor Fusion and Decentralized Control in Robotic Systems II, volume 3525, pages 82–93, 1998. [12] L. E. Parker. The effect of heterogeneity in teams of 100+ mobile robots. In A. Schultz, L. E. Parker, and F. Schneider, editors, MultiRobot Systems Volume II: From Swarms to Intelligent Automata. Kluwer, 2003. [13] L. E. Parker, B. Kannan, F. Tang, and M. Bailey. Tightly-coupled navigation assistance in heterogeneous multi-robot teams. In Proceedings of IEEE International Conference on Intelligent Robots and Systems, 2004. [14] O. Shehory. Methods for task allocation via agent coalition formation. Artificial Intelligence, 101(1-2):165–200, 1998. [15] R. Simmons, S. Singh, D. Hershberger, J. Ramos, and T. Smith. First results in the coordination of heterogeneous robots for large-scale assembly. In Proc. of the ISER ’00 Seventh International Symposium on Experimental Robotics, 2000. [16] L. Vig and J. A. Adams. Issues in multi-robot coalition formation. In L. E. Parker, A. Schultz, and F. Schneider, editors, Multi-Robot Systems Volume III: From Swarms to Intelligent Automata. Kluwer, 2005. [17] B. B. Werger and M. J. Mataric. Broadcast of local eligibility for multitarget observation. In Distributed Autonomous Robotic Systems 4, pages 347–356, 2000. [18] S. Zilberstein. Using anytime algorithms in intelligent systems. AI Magazine, 17(3):73–83, 1996. [19] R. Zlot, A. Stentz, M. B. Dias, and S. Thayer. Multi-robot exploration controlled by a market economy. In Proceedings of IEEE International Conference on Robotics and Automation, pages 3016–3023, 2002.
