**3. Problem formalization**

A formal framework of a dynamic environment and some related concepts are presented below.

Definition 3.1. (Dynamic environment) A global view (snapshot) of an environment <sup>E</sup>, with a set of locations *<sup>L</sup>*, taken at time *<sup>t</sup>*, is given by a 3-tuple <sup>E</sup>*<sup>t</sup>* <sup>¼</sup> R*t* , T *t* , *<sup>f</sup>* , where <sup>R</sup>*<sup>t</sup>* is the set of robots present in the environment at time *<sup>t</sup>*, and <sup>T</sup> *<sup>t</sup>* is the set of tasks that arrive in the environment at time *<sup>t</sup>*, *<sup>f</sup>* : <sup>R</sup>*<sup>t</sup>* � <sup>↦</sup> *<sup>L</sup>*, is a function that gives the location of a robot at a discrete instant of time represented by the set of natural numbers .

A robot has a set of skills *ψ* (eg., gripper, camera), and at any instant of time it may be in any state from the set of states S ¼ f g *Idle*, *Ready*, *Promise*, *Busy* . A robot can enter the environment E at any time, but can leave only if its state is *Idle*. When

via runtime team/coalition formation. To form a team with a lack of global knowledge, the robots need to communicate with each other to acquire relevant information. Here, a distributed approach for collaborative task execution in a dynamic environment is discussed. We illustrate the applicability of the approach with urban search and rescue (USAR) domain and evaluate its performance with extensive

We now illustrate an example scenario of the problem considered as shown in

**Figure 1**. The environment, a grid world of size 4 3, consists of 12 locations marked as *a*, *b*, … , *l*. Robots can move to its adjacent location. Boxes arrive at the locations at different points in time. The task is to move a box from its arrival

The snapshots of the environment at different instants of time is shown in **Figure 1**. At time *t*1, two tasks *τ*<sup>1</sup> and *τ*<sup>2</sup> arrive at locations *a* and *g* respectively, 4 robots are present at the locations *b*, *c*, *f* and *h*. The robots *r*<sup>1</sup> and *r*<sup>4</sup> detect the tasks *τ*<sup>1</sup> and *τ*<sup>2</sup> respectively. At time *t*2, *r*<sup>1</sup> and *r*<sup>4</sup> move to locations *a* and *g* to attend the tasks. Now, *r*<sup>1</sup> and *r*<sup>4</sup> determine the team sizes to be 2 and 3, and the goal locations to be *h* and *l* for the tasks *τ*<sup>1</sup> and *τ*<sup>2</sup> respectively. At this time, *r*<sup>3</sup> exits and *r*<sup>5</sup> and *r*<sup>6</sup>

At *t*2, *r*<sup>1</sup> and *r*<sup>4</sup> do not know the states and locations of other robots present in the environment, and thus with this insufficient information they cannot form their respective teams. Thus, in order to form their teams, they invoke the algorithm given in Section 4. At *t*3,*r*<sup>1</sup> and *r*<sup>4</sup> both form their teams successfully and the members reach the locations of the tasks as shown in the Figure. Finally, at time *t*4, execution of the tasks are completed and the team members for *τ*<sup>1</sup> and *τ*<sup>2</sup> reach their respective goal locations.

In the literature, several approaches have been suggested for solving the problem

The work [2] proposed direct (explicit) communication to improve the coordination of a homogeneous group of two six-legged robots required to transport a rectangular box towards a target cooperatively. The work [3] considered the problem of cooperative box pushing where the roles of the members are pre-defined; specifically one robot acts as a watcher and the others act as pusher. However, we consider a more complex scenario of cooperative object transportation scenario, where the role of each robot is not fixed in advance, rather decided at runtime. In [4], the robots are designed to push the object across the portion of its surface, where it occludes the direct line of sight to the goal. This simple behavior results in transporting the object

of cooperative object transportation [1–4]. The work [1] is considered as the pioneering work, targeting a cooperative transport task by a homogeneous group of simple robots that can only push an object. The authors [1] demonstrate that

coordinated effort is not possible without explicit communication.

towards the goal without using any form of direct communication.

experiments using ARGoS, a realistic multi-robot simulator.

location to the goal location, which is marked on the box.

enter at locations *k* and *j* respectively.

**2. Related work**

**144**

**Figure 1.**

*Snapshots of a dynamic environment.*

*Robotics Software Design and Engineering*

a robot attends a task, it can determine the information required to begin team formation, from the task specification, which is given below.

The counter *c* of initiator is increased on receipt of *Willing* message. The parameter (*c*≥ *k* � 1) is checked after Δ time has elapsed. Now, if the value of (*c*≥*k* � 1) is true then team formation that has maximum utility is possible and sends *Confirm* message to the members of the team and sends a *Not-Required* message to (*c* � ð Þ *k* � 1 ) robots, if any. However, if the value of the condition (*c*≥*k* � 1) is false, *i*sends a *Not-Required* message to all *c* robots who expressed their willingness to help. Also, *i* changes its state from state *Ready* to *Idle* The algorithm has the non-blocking property since a timer is used. If there was no timer, an initiator would have waited indefinitely and thereby forcing some non-initiators to

The *receive* function of a robot is given in Algorithm 2. The agents take the action based on the current state that may be *Idle* (line 17–21), *Promise* (line 22–39), *Busy* (line 12–16 and 41–45), and *Ready* (line 1–11). Within a state, the type of message is checked and appropriate actions are taken. For example, if an agent receives a *Request* message in *Idle*, the identifier of the sender is enqueued, and *flag* is set to true; if it has appropriate skills then it sends the *Willing* message to the sender

The behavior of the agent is captured with communicating automata (CA) [7] as shown in **Figures 2** and **3**. Moreover, this communicating automata is helpful in

Transitions in CA are very general form *χ* : *γ*, where *χ* can either be an input *a* (send message !*m*, receive message ?*m*), or a state condition *g*, or ð Þ *a*, *g* , and *γ* can

wait indefinitely as well; thus the system would be blocked.

*A Distributed Approach for Autonomous Cooperative Transportation*

*DOI: http://dx.doi.org/10.5772/intechopen.98270*

(initiator) and *flag* is set to false.

*Finite state machine for an initiator agent.*

*Finite state machine for a non-initiator agent.*

**Figure 2.**

**Figure 3.**

**147**

understanding and designing the algorithm.

Definition 3.2. (Task (cooperative transportation)) A task *τ* is specified by a 5-tuple *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ where *ν* is the name of a task (e.g., move (carry) box B to location *l* 0 , lift desk D), *l* ∈*L* is the location where the task arrived, *t* is the time at which the task arrived, *k*> 1 is the number of robots required to execute the task, and Ψ is the set of skills required to execute the task.

Definition 3.3. (Condition for single task execution) A task *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ can be executed, if there exists a set R of *k* available robots, such that for all *r*∈ R,

*ψ<sup>r</sup>* ⊇ Ψ at some time *t* <sup>0</sup> > *t*, and for all *r*∈ R, location of *r*, *locr* ¼ *l* at some time *t* 00 >*t* 0 . The first condition in the *if* is for team formation, and the second condition is for ensuring that all the team members converge to the location of the task.

Definition 3.4. (Condition for multiple task execution) The tasks *τ*<sup>1</sup> ¼ h i *ν*1, *l*1, *t*, *k*1, Ψ<sup>1</sup> and *τ*<sup>2</sup> ¼ h i *ν*2, *l*2, *t*, *k*2, Ψ<sup>2</sup> can be executed if the following conditions hold:


3.R<sup>1</sup> ∩ R<sup>2</sup> ¼ ∅.

Definition 3.5. (Utility of a team for task execution) Let Γ ¼ f g *x*1, … , *xk* be a team that can execute a task *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ where each member of the team was located at *locxi* . The utility of a team Γ for executing *τ* is Uh i <sup>Γ</sup>,*<sup>τ</sup>* ¼ �*cost*h i <sup>Γ</sup>,*<sup>τ</sup>* , where *cost*h i <sup>Γ</sup>,*<sup>τ</sup>* <sup>¼</sup> <sup>P</sup> *xi* <sup>∈</sup><sup>Γ</sup> *<sup>μ</sup> xi* h i ,*<sup>τ</sup>* and *<sup>μ</sup> xi* h i ,*<sup>τ</sup>* <sup>¼</sup> **<sup>p</sup>** *xi* ð Þ� , *<sup>τ</sup>* <sup>1</sup> *αxi* þ **d** *locxi* ð Þ� , *l βxi* .

where *αxi* , *βxi* ∈ð � 0, 1 denote remaining battery coefficient and battery consumption rate respectively of (a robot) *xi*, **p** *xi* ð Þ , *τ* is the price of *xi* for *τ*, **d**ð Þ *l*1, *l*<sup>2</sup> is the distance covered when moving from *l*<sup>1</sup> to *l*2.

A robot with higher *α* value ensures that it will not fail due to its more remaining battery backup. A robot with lower *β* value ensures that it will last for a longer period of time.

#### **4. Distributed algorithm for cooperative transportation**

Following assumptions are made for the study. Multiple robots are required for any task execution. A robot can execute at most one task at a time. Each robot has a unique identifier (id). A wireless network that is lossless, message delay is finite, data is not corrupted during transmission is considered. Messages are delivered in a FIFO manner.

Informal description of the algorithm is given below. Let a robot *i* attend a task *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ where *ψ<sup>i</sup>* ⊇ *τ:*Ψ. To execute the task (cooperative transportation), initiator communicates with other robots in order to form a runtime team. Here, the *i* is named as an initiator, and the other robots as non-initiators.

After task detection, *i* broadcasts a *Request* message to know the current state of the other robots present in the environment at that moment in time and waits for some time, say Δ. The broadcast messages are delivered only to those robots who are present in the range. Now, on receipt of *Request* message, a non-initiator *j* takes the necessary actions. A non-initiator who has the desired skill will send a *Willing* and an *Engaged* message if its state is other then *Idle*.

#### *A Distributed Approach for Autonomous Cooperative Transportation DOI: http://dx.doi.org/10.5772/intechopen.98270*

The counter *c* of initiator is increased on receipt of *Willing* message. The parameter (*c*≥ *k* � 1) is checked after Δ time has elapsed. Now, if the value of (*c*≥*k* � 1) is true then team formation that has maximum utility is possible and sends *Confirm* message to the members of the team and sends a *Not-Required* message to (*c* � ð Þ *k* � 1 ) robots, if any. However, if the value of the condition (*c*≥*k* � 1) is false, *i*sends a *Not-Required* message to all *c* robots who expressed their willingness to help. Also, *i* changes its state from state *Ready* to *Idle* The algorithm has the non-blocking property since a timer is used. If there was no timer, an initiator would have waited indefinitely and thereby forcing some non-initiators to wait indefinitely as well; thus the system would be blocked.

The *receive* function of a robot is given in Algorithm 2. The agents take the action based on the current state that may be *Idle* (line 17–21), *Promise* (line 22–39), *Busy* (line 12–16 and 41–45), and *Ready* (line 1–11). Within a state, the type of message is checked and appropriate actions are taken. For example, if an agent receives a *Request* message in *Idle*, the identifier of the sender is enqueued, and *flag* is set to true; if it has appropriate skills then it sends the *Willing* message to the sender (initiator) and *flag* is set to false.

The behavior of the agent is captured with communicating automata (CA) [7] as shown in **Figures 2** and **3**. Moreover, this communicating automata is helpful in understanding and designing the algorithm.

Transitions in CA are very general form *χ* : *γ*, where *χ* can either be an input *a* (send message !*m*, receive message ?*m*), or a state condition *g*, or ð Þ *a*, *g* , and *γ* can

a robot attends a task, it can determine the information required to begin team

Definition 3.2. (Task (cooperative transportation)) A task *τ* is specified by a 5-tuple *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ where *ν* is the name of a task (e.g., move (carry) box B to

which the task arrived, *k*> 1 is the number of robots required to execute the task,

Definition 3.3. (Condition for single task execution) A task *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ can be executed, if there exists a set R of *k* available robots, such that for all *r*∈ R,

The first condition in the *if* is for team formation, and the second condition is for

1. there exists a set R<sup>1</sup> of *k*<sup>1</sup> available robots, such that for all *r*∈ R1, *ψ<sup>r</sup>* ⊇ Ψ<sup>1</sup> at

2. there exists a set R<sup>2</sup> of *k*<sup>2</sup> available robots, such that for all *r*∈ R2, *ψ<sup>r</sup>* ⊇ Ψ<sup>2</sup> at

Definition 3.5. (Utility of a team for task execution) Let Γ ¼ f g *x*1, … , *xk* be a team that can execute a task *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ where each member of the team was

sumption rate respectively of (a robot) *xi*, **p** *xi* ð Þ , *τ* is the price of *xi* for *τ*, **d**ð Þ *l*1, *l*<sup>2</sup> is

battery backup. A robot with lower *β* value ensures that it will last for a longer

A robot with higher *α* value ensures that it will not fail due to its more remaining

Following assumptions are made for the study. Multiple robots are required for any task execution. A robot can execute at most one task at a time. Each robot has a unique identifier (id). A wireless network that is lossless, message delay is finite, data is not corrupted during transmission is considered. Messages are delivered in a

Informal description of the algorithm is given below. Let a robot *i* attend a task *τ* ¼ h i *ν*, *l*, *t*, *k*, Ψ where *ψ<sup>i</sup>* ⊇ *τ:*Ψ. To execute the task (cooperative transportation), initiator communicates with other robots in order to form a runtime team. Here, the

After task detection, *i* broadcasts a *Request* message to know the current state of the other robots present in the environment at that moment in time and waits for some time, say Δ. The broadcast messages are delivered only to those robots who are present in the range. Now, on receipt of *Request* message, a non-initiator *j* takes the necessary actions. A non-initiator who has the desired skill will send a *Willing*

*xi* <sup>∈</sup><sup>Γ</sup> *<sup>μ</sup> xi* h i ,*<sup>τ</sup>* and *<sup>μ</sup> xi* h i ,*<sup>τ</sup>* <sup>¼</sup> **<sup>p</sup>** *xi* ð Þ� , *<sup>τ</sup>* <sup>1</sup>

**4. Distributed algorithm for cooperative transportation**

*i* is named as an initiator, and the other robots as non-initiators.

and an *Engaged* message if its state is other then *Idle*.

the distance covered when moving from *l*<sup>1</sup> to *l*2.

. The utility of a team Γ for executing *τ* is Uh i <sup>Γ</sup>,*<sup>τ</sup>* ¼ �*cost*h i <sup>Γ</sup>,*<sup>τ</sup>* , where

*αxi*

, *βxi* ∈ð � 0, 1 denote remaining battery coefficient and battery con-

<sup>1</sup> >*t*, and for all *r*∈ R1, *locr* ¼ *l*<sup>1</sup> at some time *t*

<sup>2</sup> > *t*, and for all *r*∈ R2, *locr* ¼ *l*<sup>2</sup> at some time *t*

ensuring that all the team members converge to the location of the task. Definition 3.4. (Condition for multiple task execution) The tasks *τ*<sup>1</sup> ¼ h i *ν*1, *l*1, *t*, *k*1, Ψ<sup>1</sup> and *τ*<sup>2</sup> ¼ h i *ν*2, *l*2, *t*, *k*2, Ψ<sup>2</sup> can be executed if the following conditions

, lift desk D), *l* ∈*L* is the location where the task arrived, *t* is the time at

<sup>0</sup> > *t*, and for all *r*∈ R, location of *r*, *locr* ¼ *l* at some time *t*

00 <sup>1</sup> >*t*<sup>1</sup><sup>0</sup> .

00 <sup>2</sup> >*t* 0 2.

.

þ **d** *locxi* ð Þ� , *l βxi*

00 >*t* 0 .

formation, from the task specification, which is given below.

and Ψ is the set of skills required to execute the task.

location *l*

hold:

0

*ψ<sup>r</sup>* ⊇ Ψ at some time *t*

some time *t*

some time *t*

3.R<sup>1</sup> ∩ R<sup>2</sup> ¼ ∅.

located at *locxi*

where *αxi*

period of time.

FIFO manner.

**146**

*cost*h i <sup>Γ</sup>,*<sup>τ</sup>* <sup>¼</sup> <sup>P</sup>

0

*Robotics Software Design and Engineering*

0

*Finite state machine for an initiator agent.*

**Figure 3.** *Finite state machine for a non-initiator agent.*

either be a sequence of actions *seq*, or a sequence of actions that is to be performed atomically h i *seq* , or empty. Similarly, semantics are defined.

The complete execution trace of algorithms 1,2 is shown in **Figure 4** using

*A Distributed Approach for Autonomous Cooperative Transportation*

message sequence chart (MSC).

*DOI: http://dx.doi.org/10.5772/intechopen.98270*

**149**

## **4.1 Analysis of the algorithm**

#### *4.1.1 Message complexity*

Let there be *I* initiators at some instant of time, say *t*. Each initiator broadcasts a *Request* message, which is sent to ð Þ *N* � 1 robots, where *N* is the total number of robots present at time *t*. So, the total number of such messages would be ð Þ� *N* � 1 *I* which is *O N*ð Þ � *I* . The total number of replies obtained from non-initiators would be at most ð Þ� *N* � 1 *I* which is *O N*ð Þ � *I* . An initiator sends *c* number of *Confirm* and *Not-Required* messages, which is *O N*ð Þ. Thus total messages send by all the initiators would be *O N*ð Þ � *I* . Thus the total number of messages would be the sum of these messages, and this becomes *O N*ð Þþ � *I O N*ð Þþ � *I O N*ð Þ � *I* , which is *O N*ð Þ � *I* . When the number of initiators is relatively small compared to the total number of robots present at time *t*, the message complexity would be *O N*ð Þ.

#### *4.1.2 Handling multiple initiators*

Let us consider the snapshot of the environment at *t*<sup>2</sup> in **Figure 1**, where *r*1,*r*<sup>4</sup> invoke the *send* function (Algorithm 1) simultaneously; *r*1,*r*<sup>4</sup> need one, two other robots respectively. The initiators *r*1,*r*<sup>4</sup> broadcast *Request* messages corresponding to their respective tasks. Let all the other robots be in *Idle* state initially and they can satisfy the requirements of both the tasks. Eventually *r*<sup>2</sup> becomes part of the team with *r*<sup>1</sup> because it received the *Request* message from *r*<sup>1</sup> before it received the *Request* message from *r*4. Similarly, eventually *r*<sup>5</sup> and *r*<sup>6</sup> become part of the team with *r*4.

either be a sequence of actions *seq*, or a sequence of actions that is to be performed

Let there be *I* initiators at some instant of time, say *t*. Each initiator broadcasts a *Request* message, which is sent to ð Þ *N* � 1 robots, where *N* is the total number of robots present at time *t*. So, the total number of such messages would be ð Þ� *N* � 1 *I* which is *O N*ð Þ � *I* . The total number of replies obtained from non-initiators would be at most ð Þ� *N* � 1 *I* which is *O N*ð Þ � *I* . An initiator sends *c* number of *Confirm* and *Not-Required* messages, which is *O N*ð Þ. Thus total messages send by all the initiators would be *O N*ð Þ � *I* . Thus the total number of messages would be the sum of these messages, and this becomes *O N*ð Þþ � *I O N*ð Þþ � *I O N*ð Þ � *I* , which is *O N*ð Þ � *I* . When the number of initiators is relatively small compared to the total number of robots

Let us consider the snapshot of the environment at *t*<sup>2</sup> in **Figure 1**, where *r*1,*r*<sup>4</sup> invoke the *send* function (Algorithm 1) simultaneously; *r*1,*r*<sup>4</sup> need one, two other robots respectively. The initiators *r*1,*r*<sup>4</sup> broadcast *Request* messages corresponding to their respective tasks. Let all the other robots be in *Idle* state initially and they can satisfy the requirements of both the tasks. Eventually *r*<sup>2</sup> becomes part of the team with *r*<sup>1</sup> because it received the *Request* message from *r*<sup>1</sup> before it received the *Request* message from *r*4. Similarly, eventually *r*<sup>5</sup> and *r*<sup>6</sup> become part of the team with *r*4.

atomically h i *seq* , or empty. Similarly, semantics are defined.

present at time *t*, the message complexity would be *O N*ð Þ.

**4.1 Analysis of the algorithm**

*Robotics Software Design and Engineering*

*4.1.2 Handling multiple initiators*

**148**

*4.1.1 Message complexity*

The complete execution trace of algorithms 1,2 is shown in **Figure 4** using message sequence chart (MSC).

**Figure 4.** *Execution trace of the algorithms for multiple initiators.*
