Multi-Robot Systems From Swarms to Intelligent Automata - Parker et al (Eds) Part 5 pptx

In this paper, we argue that the importance of the environment can be taken one step further, in the sense that the external behaviors displayed by a single robot or a multi-robot collec

Figure 4 (In color where available) An example of small-team coordination taken from

a test in which 5 robots cleared a large building As part of a 2-robot plan, the robot that is initially in the lower right corner moves up and left to block the central open area so the robot that another robot can move left and keep searching.

0 2000 4000 6000 8000 10000

12000

14000

16000

18000

20000

3-triangle.3 T3.3 gates-simple.2 gates.3 sal2.2

Environment Number of robots

Parish A*

(a)

10

15

20

25

30

35

40

45

50

3-triangle.3 T3.3 gates-simple.2 gates.3 sal2.2

Environment Number of robots

Parish A*

(b)

Figure 5 Comparison of Parish and A* in planning pursuit strategies in various environ-ments Shown in (a) is the number of nodes expanded during the search, and in (b) is the length

of the solution found (smaller is better in both cases) Results for Parish, which is stochastic, show the experimental mean and standard deviation, computed from 100 runs in each environ-ment.

Colin Cherry and Hong Zhang

Department of Computing Science

University of Alberta

Edmonton, Alberta Canada T6G 2E8

{colinc, zhang}@cs.ualberta.ca

collective of robots under reactive control is as much due to the design of their internal behaviors as to the external conditions imposed by the environment in which the robot collective operate Our argument is advanced through the exami-nation of a set of well-known collective robotics tasks that involve, in one form or another, the movement of materials, namely, foraging, transport, and construc-tion We demonstrate that these seemingly different tasks can all be achieved

by one controller that employs behaviors identical across the task domains but parameterized with a couple of task-specific constants The implementation of the study is conducted with the help of the TeamBots robot simulator.

1 Introduction

Collective robotics is concerned with the use of multiple robots for the per-formance of tasks that are inefficient, difficult or impossible by robot single-tons (Balch and Parker, 2002) A dominant and successful design approach

to multi-robot systems (MRS) is based on behavior-based control (Brooks, 1986), which uses a hierarchy of simple reflexive or reactive behaviors at the level of individual robots whose interaction with each other as well as with the environment can lead to the emergence of desired group-level behaviors Behavior-based control can be implemented with the well-known subsumption architecture (Brooks, 1986) or motor schemas (Arkin, 1998), which is adopted

in this study Numerous successful studies have clearly established the validity

of this design approach

One of the cornerstones of behavior-based robotics is the recognition of the importance of the environment on the behaviors displayed by a robot that inter-acts with it Given the complexity and variability of the world in which a robot must operate, rather than attempting to model the world exactly and formulate

79

L.E Parker et al (eds.),

Multi-Robot Systems From Swarms to Intelligent Automata Volume III, 79–90.

 c 2005 Springer Printed in the Netherlands.

plans and actions, a behavior-based approach uses carefully designed rules that sense and react to the changes in the world, and this approach has proved to be more robust and effective in many situations than the traditional deliberative control (Gat, 1997)

In this paper, we argue that the importance of the environment can be taken one step further, in the sense that the external behaviors displayed by a single robot or a multi-robot collective can, to a significant extent, be attributed to the environment in which the robots reside We will support this argument

by demonstrating that only minimum changes need to be made to the robot controller when the robot system is confronted with a seemingly different task Specifically, we will use a set of three well-known collective robotics tasks which involve, in one form or another, the movement of materials, namely, foraging, group transport (box-pushing), and collective construction We will show that, to solve all three tasks, structural change to the robot controller is unnecessary, and that only parameters that drive the internal behaviors of the robots need to be adjusted This observation represents a further development beyond the assertion that basis behaviors exist that are capable of wide variety

of tasks (Mataric, 1995)

1.1 Collective Robotic Building Tasks

The work in (Balch and Arkin, 1995) describes in detail the foraging task and the corresponding reactive foraging controller A number of “attractors" litter the field, and must be brought to a home position The attractors have mass, and heavy attractors can be carried more quickly with more than one robot working together The robots can communicate, and therefore have the ability to signal other robots to work on the same attractor as them

Group transport, or box pushing, describes any task where robots must work together to move one object that a single robot can not move alone The task modeled in this paper is most similar to the tasks investigated in (Kube and Zhang, 1993) and (Kube and Zhang, 1997), which tackle the problem of hav-ing robots push an attractor to a specific destination Their work uses robots controlled by hierarchical FSAs to push a circular box to a lit home area The robots are able to see both the home area and the attractor, allowing them to determine if the attractor is between them and the goal This notion of position-ing so that the attractor is between the robot and the destination will become central to the pushing strategy used later in this paper

The problem of collective construction is studied in (Parker et al., 2003) Robots are initially positioned in a clear area surrounded by rubble, and they proceed to clear the debris to create a larger, circular nest, where the nest walls are composed of the rubble Inspired by construction by ants, (Parker et al., 2003) takes an extreme minimalist approach to collective construction, called

blind bulldozing The robots being controlled in this paper, however, have access to considerably more sensing power than those used in (Parker et al., 2003), with the ability to sense attractors, sense a home position, and to differ-entiate between those attractors that are in place and those that are not

1.2 Problem Statement

The goal of our study is to design and test a single controller capable of executing all three tasks described above All three tasks involve moving some number of objects from their current location to a destination The major vari-ables in these tasks are whether or not the robots are capable of moving indi-vidual objects alone, and the destination for the objects Regardless of whether robots are working alone or in teams, pushing is always used as the method of moving objects

The robots’ physical capabilities and sensors remain static through all three tasks The only changes allowed from task to task are those in the external environment, and adjustments to some small number of controller parame-ters These parameters are intended to make small, task-specific changes to the controller: adjustments to schema weights or polarities, or to the triggers for perceptual cues Once designed, the controller will be implemented in the TeamBots simulator, and tested on the three tasks

2 Design of Versatile Controller

This section will describe the multitask controller used to conduct foraging, group transport and nest construction tasks Our control system will follow the motor schema approach popularized by (Arkin, 1998) This approach uses a perception-triggered finite state machine (FSM) to switch the robot between states, corresponding to the major steps needed for any task

We will begin by describing the general strategy employed in any pushing task and the corresponding finite state machine The behavior in each state will then be described in terms of combinations of base behaviors We will then describe the perceptual cues that trigger state transitions We end this section with a discussion of the three parameters that are used to adjust the generic

system to favor particular tasks: the cooperation and positioning parameters (c and p), and the building flag (b).

2.1 Generic Strategy and Finite State Machine

Viewed at a high level, the generic pushing robots tackle all material trans-port problems with the same strategy: they must find an object to push, get into a good pushing position, and then push object to its destination Starting with a foraging FSM that is similar to the one used in (Balch and Arkin, 1995),

we make small modifications to reflect the differences between the generic

Wander Position

Push

Detect attractor Lose attractor

Out of position

The finite state machine for the generic pushing robot.

pushing task and foraging if a gripper is available The resulting controller is pictured in Figure 1

The purpose of the “Wander” state is to find an attractor to work on Wander produces a random walk to perform this attractor search, consisting of the four

schemas Noise produces random motion Avoid obstacles keeps robots from colliding, and ensures they do not redundantly search the same area Swirl

obstacles to noise ensures that the robot takes a smooth route around obstacles

in its current direction of travel Finally, Draw to home, active only when the

build flag, to be described later, is set, encourages the robot to explore an area close to home This is the only instance where an extra schema was added to

a state for a particular task As with any schema-based control, the outputs of the behaviors (motor schemas) are combined in the form of a weighted sum to produce the final actuator commands (Arkin, 1998)

The purpose of the “Position” state, not to be confused with the position

flag p, is to bring the robot into a good position for pushing the attractor to

its destination Position causes the robot to move in a circular path around the robot’s closest, targeted attractor, without necessarily coming into contact with

the attractor It consists of the five schemas, including the Swirl obstacles to

noise and Noise schemas as in the Wander state The first of the three new

schemas, Swirl target to home, produces a circular motion so the robot moves around its closest attractor Move to target schema moves the robot toward the

target, so it is less likely to lose sight of the target while rotating around it

Swirl obstacles to home schema ensures a smooth path around other robots in

the current direction of travel Finally, Watch target is active for the robot’s

turret, always drawing it toward the current target, so the robot does not lose sight of it while rotating

The purpose of “Push” is to have the robot to move to a destination point, pushing an attractor in front of it “Push” consists of the same set of schemas

as “Position”, with the exception of Swirl obstacles to target, in place of Swirl

obstacles to home, which ensures smooth motion around an obstacle in the

robot’s current direction of travel

2.2 Perceptual Cues

Transitions between states depend on a set of perceptual cues described in this section First of all, the “detect attractor” cue is triggered when an attractor object falls within the robot’s visual sensor range Similarly, “lose attractor” is triggered if no attractors are currently in visual range

Secondly, as in previous studies (Balch and Arkin, 1995), we assume that the robot is constantly able to sense its home For foraging and group transport, the “in position” cue is triggered when the robot’s closest visible attractor lies between the robot and home Whether or not an attractor is between the robot and its home is determined by the alignment between vector from the robot to

the attractor and that from the robot to Home.

The betweenness threshold for “out of position” is set to be more tolerant than that of “in position” This produces behavior where the robot is very picky about when it starts to consider itself in position, but then allows for a fair amount of leeway before it actively corrects its position This prevents rapid and ineffectual switching between the “Position” and “Push” states When the build parameter is set to produce building behavior, this perceptual cue is inverted In this case, it detects when the robot lies between home and the attractor See Section 2 for more details

2.3 Task Parameters

The goal of this research is to construct a controller that is equally switches gracefully among the tasks of foraging, group transport, and nest construction, under the influence of only external conditions defined by the environment This will be accomplished with the help of the three simple parameters de-scribed below, which are devised in order to tune the robots to be predisposed

to perform a specific task One should note, though, that structure of the con-troller does not change and that they affect primarily schema weights and the direction of certain forces In other words, the parameters have been designed

to affect the performance of the controller while maintaining its spirit

Cooperation: c. The cooperation parameter c determines how well robots

work together, and conversely, how carefully they avoid redundant effort It

varies in value from 0 to 1, with c= 1 indicating maximum cooperation It

affects only the Avoid obstacle and Swirl obstacle schemas in the “Position”

and “Push” states

Robot

Home

Attractor

1

Home

Robot

Attractor

An example of pushing position with respect to robot radii

In “Position,” the avoid schemas have their weight set according to 2(1 − c) The result is that when cooperation is low, a robot will be unlikely to reach a good pushing position (and thus enter “Push”) for an attractor that already has another robot near by When cooperation is high, several robots will be able to target the same attractor easily

Conversely, in “Push”, the avoid schemas have their weight set directly

ac-cording to c As is described above, robots need to avoid each other when

cooperating to push a large object, or no room will be made for potentially helpful robots When cooperation is low, robots will ignore each other, and concentrate on pushing This rarely results in two robots “fighting over” the same object, though, as they are unlikely to both target the same object due to the high avoid weight while in the “Position” state

Position: p. The position parameter p intuitively determines how fussy a robot is about positioning itself before it starts pushing A lower p indicates

that the robot requires a position that is closer to the optimal position before it

starts pushing Numerically, p, is the number of robot radii away an attractor

is allowed to be from the point where it would be exactly on the path between the robot and its destination For example, take the two situations pictured in

Figure 2 In the situation on the left, a robot with p= 1 would transition into

“Push,” as would a robot with p= 2 However, in the situation on the right,

only a robot with p= 2 would transition into “Push.” Note that the transition happens regardless of the object radius, as a robot may not be able to tell an object’s true radius in practice

Build Flag: b. The build flag switches the robot from a foraging goal to a nest building goal, pushing objects out and away from a central point, instead

of pushing them in toward the same point It has the most dramatic effect on the controller of all the parameters, but it is our hope that though its effect may

be large, it is conceptually a very small change: it simply reverses the polarity

of the robots’ home

When the build flag is set, all schemas that would move the robot toward home become moves away from home and vice-versa This affects only the

Swirl X to home schemas in the “Position” and “Push” states When foraging,

these schemas swirl the robot away from home, so that the robot keeps the attractor between itself and home, and therefore pushes the attractor to home When constructing, these schemas swirl the robot toward home, so it stays between home and the attractor Therefore, it pushes the attractor away from home To agree with the above changes, the build flag also redefines the “(Still)

In position” perceptual cue, so that the robot checks if it is between home and the attractor when building Similarly, it redefines the robots’ attractor filter

so that all attractors that are a certain distance away from home are filtered out when building, as opposed to filtering attractors sufficiently close to home when foraging

Finally, in the only change that is not directly tied to reversing the polarity

of home, it adds an extra schema to the “Wander” state, causing the robot to stay close to home, and to avoid wandering in the portions of the map where nothing needs to be done This also has the visually pleasing effect of having the robots peacefully “live” inside their nest after construction is complete

Initial parameterizations for specific tasks. The parameters were created with the intention of easily characterizing the three target tasks with parameter values Foraging small, light attractors was envisioned as a low-cooperation

foraging task, and therefore was characterized with the parameter settings c=

0, p = 1 and b = false Group transport was seen as a high-cooperation forag-ing task, and was characterized with c = 1, p = w and b = false, where w is the

minimum number of robots needed to move the heaviest attractor Finally nest construction with small, light attractors was seen as a low-cooperation building

task, and was characterized with c = 0, p = 1 and b = true.

3 Experimental Design

We have conducted experiments for the purpose of both proof of concept and tests for parameter sensitivity Only the results in the first category are described due to the limit on the length of the paper Proofs of concept are designed to answer the question of whether or not the generic pushing sys-tem is able to accomplish a given task using the reasonable parameter settings described in Section 2

Figure 3. An initial configuration for the foraging task where the four big circles represent robots, the small dots represent objects to be foraged, and the square indicates the home The arc in front of each robot indicates the angular and linear ranges of each robot’s sensor.

3.1 Foraging Proof of Concept

The environment was set up with 10 randomly placed attractors in a 10x10 unit field The attractors were placed according to a uniform distribution, re-jecting (unpushable) points within 0.5 units of a wall, and positions that lie within the home zone Four robots began on the edges of the home zone, which

is centered at the point (0,0) The initial configuration of the robots is shown

in Figure 3, with their home zone roughly outlined with the center square All

variables were held constant and set to c = 0, p = 1, b = false.

For each randomly generated environment configuration, 10 trials were run with each controller, and the results were recorded in terms of both comple-tion time (measured in simulated milliseconds), and in terms of the number

of attractors successfully foraged, called the success rate from this point on The simulation was set to timeout after 2,620 simulator seconds, which corre-sponded to roughly 3 minutes of real-time when watching the simulator live Any incomplete runs were simply treated as having taken 2,620 simulator sec-onds 30 maps were generated and tested We will report the average comple-tion time and success rate for each controller