Multi-robot deployment from LTL specifications with reduced communication - technical report -

Multi-robot Deployment From LTL Specifications with Reduced Communication

Abstract

In this work, we develop a computational framework for fully automatic deployment of a team of unicycles from a global specification given as an LTL formula over some regions of interest. Our hierarchical approach consists of four steps: (i) the construction of finite abstractions for the motions of each robot, (ii) the parallel composition of the abstractions, (iii) the generation of a satisfying motion of the team; (iv) mapping this motion to individual robot control and communication strategies. The main result of the paper is an algorithm to reduce the amount of inter-robot communication during the fourth step of the procedure.

\IEEEoverridecommandlockouts\overrideIEEEmargins

1 Introduction

Motion planning and control is a fundamental problem that have been extensively studied in the robotics literature [1]. Most of the existing works have focused on point-to-point navigation, where a mobile robot is required to travel from an initial to a final point or region, while avoiding obstacles. Several solutions have been proposed for this problem, including cell decomposition based approaches that use graph search algorithms such as [2, 1], continuous approaches involving navigation functions and potential fields [3], and sampling-based methods such as Rapidly-Exploring Random Trees (RRTs) [4, 5]. However, the above approaches cannot accommodate complex task specifications, where a robot might be required to satisfy some temporal and logic constraints, e.g., “avoid for all times; visit or and then be at either or for all times”.

In recent years, there has been an increased interest in using temporal logics to specify mission plans for robots [6, 7, 8, 9, 10, 11, 12]. Temporal logics [13, 14, 15] are appealing because they provide formal, rich, and high level languages in which to describe complex missions. For example, the above task specification translates immediately to the Linear Temporal Logic (LTL) formula , where , , are the usual Boolean operators, and , are two temporal operators standing for “eventually” and “always”, respectively. Computation Tree Logic (CTL) and -calculus have also been advocated as robot motion specification languages [11, 7].

To use formal languages and model checking techniques for robot motion planning and control, a fundamental challenge is to construct finite models that accurately capture the robot motion and control capabilities. Most current approaches are based on the notion of abstraction [16]. Enabled by recent developments in hierarchical abstractions of dynamical systems [17, 18, 19, 20, 21]), it is now possible to model the motions of several types of robots as finite transition systems over a cell-based decomposition of the environment. By using equivalence relations such as simulations and bisimulations [22], the motion planning and control problem can be reduced to a model checking or formal synthesis problem for a finite transition system, for which several techniques are readily available [23, 24, 14, 25].

Some recent works suggest that such single-robot techniques can be extended to multi-robot systems through the use of parallel composition (synchronous products) [11, 26]. The main advantage of such a bottom-up approach is that the motion planning problem can be solved by off-the-shelf model checking on the parallel composition followed by canonical projection on the individual transition systems. The two main limitations, both caused by the parallel composition, are the state space explosion problem and the need for inter-robot synchronization (communication) every time a robot leaves its current region. In our previous work, we proposed bisimulation-type techniques to reduce the size of the synchronous product in the case when the robots are identical [27] and derived classes of specifications that do not require any inter-robot communication [26]. By drawing inspiration from distributed formal synthesis [28], we have also proposed top-down approaches that do not require the parallel composition of the individual transition systems [29]. While cheaper, this method restricts the specifications to regular expressions.

In this paper, we focus on bottom-up approaches based on parallel composition and address one of the limitations mentioned above. Specifically, we develop an algorithm that determines a reduced number of synchronization (communication) moments along a satisfying run of the parallel composition. Our approach is heuristic - we do not minimize the necessary amount of communication. However, our approach can be directly modified to produce minimal sets of synchronization moments. Our extensive experiments show that the proposed algorithm leads to a significant reduction in the number of synchronizations. We integrate this algorithm into a software tool for automatic deployment of unicycles with polyhedral control constraints from specifications given as LTL formulas over the regions of an environment with a polyhedral partition. The user friendly tool, which is freely downloadable from http://hyness.bu.edu/s̃oftware/MRRC.htm, takes as input a user-defined environment, an LTL formula over some polytopes, the number of unicycles, and their forward and angular velocity constraints. It returns a control and communication strategy for each robot in the team. While transparent to the user, the tool also implements triangulation and polyhedral operation algorithms from [30, 31, 8], LTL to Büchi conversion [32], and robot abstraction by combining the affine vector field computation from [21] with input-output regulation [20].

The remainder of the paper is organized as follows. Sec. 2presents some preliminary notions necessary throughout the paper. Sec. 3 formulates the general problem we want to solve, outlines the solution and then presents a specific problem of interest. The main contribution of the paper is given in Sec. 4. To illustrate the method and the main concepts, a case study is examined throughout the paper and concluded in Sec. 5, while an additional case study is included in Sec. 6. The paper ends with conclusions and final remarks in Sec. 7.

2 Preliminaries

Definition 2.1

A deterministic finite transition system is a tuple , where is a (finite) set of states, is the initial state, is a transition relation, is a finite set of atomic propositions (observations), and is the observation map.

To avoid supplementary notations, we do not include control inputs in Definition 2.1 since is deterministic, i.e. we can choose any available transition at a given state. A trajectory or run of starting from is an infinite sequence with the property that , , and , . A trajectory defines an infinite word over set , , where . With a slight abuse of notation, we will denote by the word generated by run . The set of all words that can be generated by is called the (-) language of .

In this paper we consider motion specifications given as formulas of Linear Temporal Logic (LTL) [14]. A formal definition for the syntax and semantics of LTL formulas is beyond the scope of this paper. Informally, the LTL formulas are recursively defined over a set of atomic propositions , by using the standard boolean operators and a set of temporal operators. The boolean operators are (negations), (disjunction), (conjunction), and the temporal operators that we use are: (standing for “until”), (“always”), (“eventually”). LTL formulas are interpreted over infinite words over set , as are those generated by transition system . For LTL formulas satisfied by continuous systems, we restrict the class of specifications to , which are LTL formulas without the “next” temporal operator. We note that, the class of is not at all restrictive, since for continuous systems captures the full expressivity power of LTL [8].

All LTL formulas can be converted into a generalized Büchi automaton [32] defined below:

Definition 2.2 (Generalized Büchi automaton)

A generalized Büchi automaton is a tuple , where

  • is a finite set of states,

  • is the set of initial states,

  • is the input alphabet,

  • is a (nondeterministic) transition relation,

  • is the set of sets of accepting (final) states.

The semantics of a Büchi automaton is defined over infinite input words over . An input word is accepted by automaton if and only if there exists a run produced by that word with the property that all sets from are infinitely often visited. Due to the complicated acceptance condition (multiple sets have to be infinitely often visited), a generalized Büchi automaton is usually converted into a regular (degeneralized) Büchi automaton. A regular Büchi automaton has only one set of final states, i.e. . Any generalized Büchi automaton can be transformed into a regular Büchi automaton that accepts the exact same words. A conversion algorithm can be found in [32].

For any LTL formula over a set of atomic propositions , there exists a (generalized or regular) Büchi automaton with input alphabet accepting all and only infinite words over satisfying formula [33].

Given a transition system with set of observations and an LTL formula over , one can find a trajectory of which generates a word satisfying . This can be done by using model checking inspired tools [8], which begin by translating to a regular Büchi automaton . Then, the product of with is computed, operation that can be informally viewed as a matching between observations of and transitions of . An accepted run (if any) of the obtained product automaton is chosen. This accepted run is projected into a run of , which generates a word satisfying . Although is infinite, it has a finite-representable form, namely it consists of a finite string called prefix, followed by infinite repetitions of another finite string called suffix (such a run is said to be in the prefix-suffix form). A cost criterion can be imposed on the obtained run , e.g. the minimum memory for storing it, or a minimum cost on transitions of encountered when following the prefix and a finite number of repetitions of the suffix. The run can be be directly generated on if one can deterministically control (impose) the transition that appears in each state (which is true for a deterministic transition system defined in 2.1).

3 Problem Formulation and Approach

In this paper we are interested in developing an automated framework for deploying identical unicycle robots in planar environments. Assume that such a robot is described by , where gives the position vector of the robot’s center of rotation, and is its orientation. The control consists of forward driving () and steering () speeds, where is a set capturing control bounds. We assume that includes an open ball around the origin, which implies that can be also negative (i.e. the robot can drive backwards). The kinematics of the unicycle are given by:

(1)

Assume that some robots move in a polygonal convex environment with kinematics given by (1), where a set of non-overlapping convex polygonal regions1 are defined. The general deployment problem for a team of unicycle robots satisfying an LTL formula is given by:

Problem 3.1

Given a team of unicycles and a task in the form of an formula over a set of regions of interest , design individual communication and control strategies for the mobile robots such that the motion of the team satisfies the specification.

We assume that the unicycles are identical and have a small (negligible) size when compared to the size of the environment and of the predefined regions. Moreover, we consider that a unicycle visits (or avoids) a region when a specific reference point on it visits (or avoids) that region. To fully understand Problem 3.1, we say that the motion of the team satisfies an LTL formula if the word generated during the motion satisfies . The word generated by a set of continuous trajectories is a straightforward generalization of the definition of the word generated by a single trajectory [8]. Informally, the word generated by the team motion consists of a sequence of elements of containing the satisfied propositions (visited regions) as time evolves. In a generated word, there are no finite successive repetition of the same element of , and infinite successive repetitions of the same element appear if and only if each robot trajectory stays inside a region.

Case study: For better understanding of introduced concepts, throughout this paper, we consider a case study with the environment illustrated by Fig. 1, where 3 unicycle-type mobile robots evolve. The reference point of each unicycle is its “nose”, the center of rotation is the middle of the rear axis, and the initial deployment of robots is the one from Fig. 1. The imposed specification requires that “regions and and are simultaneously visited, and regions and are simultaneously visited, infinitely often, while region is always avoided”. This specification translates to the following LTL formula:

(2)
\endproof
Figure 1: A polygonal environment, six regions of interest, and the initial deployment of three unicycle robots. Robot 1 is green, robot 2 is blue, and robot 3 is red; there is no relation between the robot and the region colors.

To provide a deployment strategy for Problem 3.1, we will first combine various techniques from computational geometry, motion planning and model checking until we obtain a solution in the form of a sequence of tuples of smaller regions and feedback control laws in each of these regions. After this, we focus on the main contribution of the paper, namely finding a reduced set of communication (synchronization) moments among robots, while still guaranteeing the satisfaction of the specification. The main steps of the algorithmic approach for solving Problem 3.1 are given in the following 3 subsections.

3.1 Robot Abstraction

We first abstract the motion capabilities of each robot to a finite transition system. To this end, the environment is first partitioned into convex regions (cells) such that two adjacent cells exactly share a facet, and each region from consists of a set of adjacent cells. Such a partition can be constructed by employing cell decomposition algorithms used in motion planning and computational geometry, e.g. one can use a constraint triangulation [21] or a polytopal partition [8]. Let us denote the set of partition elements by . For a clear understanding, Fig. 2 presents a triangular partition obtained for the environment from Fig. 1. We use a triangular partition for the case study presented throughout this paper, although our approach can be applied to any partition scheme.

Figure 2: Triangular partition consisting of 40 regions, corresponding to the environment from Fig. 1.

The second step is to reduce each unicycle with kinematics (1) to a fully-actuated point robot placed in unicycle’s reference point. We use the approach from [20], where a non-singular map relates the velocity of the reference point to the initial controls . Note that can be conservatively bounded by a polyhedral set , such that the resulted control is in .

Definition 3.1

The transition system abstracting the motion capabilities of unicycle , has the form , where:

  • , i.e. the set of states is given by the cells from partition;

  • The initial state is the cell where the reference point of unicycle is initially deployed;

  • The transition relation is created as follows:

    • if we can design a feedback control law making cell invariant with respect to the trajectories of the reference point of unicycle , and

    • , if and are adjacent and we can design a feedback control law such that the reference point of unicycle leaves cell in finite time, by crossing the common facet of and ;

  • labels the set of regions of interest, and symbol corresponds to the space not covered by any region of interest;

  • The observation map associates each cell from the partition with the corresponding proposition from , or with the symbol .

Considering the unicycles reduced to their reference point, the construction of the continuous controllers corresponding to the transition relation from Definition 3.1 is done by using results for facet reachability and invariance in polytopes [21]. We just mention that designing such feedback control laws reduces to solving a set of linear programming problems in every cell from partition, where the constraints result from the control bounds and the considered adjacent cells. Also, since the reference point is fully-actuated and the control bounds include the origin, we obtain a transition between every adjacent cells, as well as a self-loop in every state of . Therefore, a run of can be implemented by unicycle by imposing specific control laws for the reference point in the visited cells, and by mapping these controls to . We note that, since the unicycles are identical, the only difference between transition systems is given by their initial states.

Case study revisited: The partition from Fig. 2 enables us to construct a transition system with 40 states corresponding to each robot, where the transitions are based on adjacency relation between cells from environment, and the observations are given by the satisfied region. Fig. 3 illustrates some vector fields obtained from driving-to-facet control problems and from invariance controlled design, as well as the corresponding transitions from system . \endproof

Figure 3: Left: vector fields driving any initial state from cell to a neighbor (blue and red colors), and vector field making invariant (black). Right: transitions from are colored in accordance with the colors of the created vector fields. Observation given by map is placed near each state.

3.2 Satisfying Behavior of the Team

In this part of the solution, we use ideas from [27, 26] to find a run (for the whole team) satisfying the formula . The transition systems are combined into a global one, , capturing the synchronized motion of the team (synchronized in the sense that robots change at the same time the occupied cells from partition, or states from ). Then, by using model checking inspired techniques as mentioned in Sec. 2, we find a run for the whole team, in the form of a prefix-suffix sequence of tuples.

Definition 3.2

The transition system capturing the behavior of the group of robots is defined as the synchronous product of all ’s, :

  • ,

  • ,

  • is defined by if and only if , ,

  • is the observation set,

  • is defined by .

We now find a run of such that the generated word satisfies . For this, we use the tool from [8], and we impose the optimality criterion that during the prefix and one iteration of the suffix, the total number of movements between partition cells is minimized. This is accomplished by adding weights to transitions of , where the weight of a transition equals the number of robots that change their state from . These weight are inherited when taking the product of with . This optimality criterion minimizes the memory used on robots for storing motion controllers (feedback control laws driving robots from one cell to an adjacent one).

In [27, 26], such a global run was projected to individual runs of robots. Then, the robots can be controlled by the affine feedback controllers that map to unicycle controls from Sec. 3.1. In deployment, when the team makes a transition from one tuple of the run to the next, the robots must synchronize (communicate) with each other and wait until every member finishes the previous transition. The synchronization will occur on the boundaries of the cells when crossing from a cell to another.

Remark 3.1

Since the robots are identical, the number of states from can be reduced by designing a bisimilar (equivalent) transition system (the quotient induced by robot permutations) [27]. Thus, the computation complexity of finding a run is manageable even for large teams.

Case study revisited: For the above introduced example (Fig. 1 and 2, and specification (2)), we obtain a team run , with 7 states in prefix and 8 states in suffix, as shown in Eqn. (3).

(3)

Run means that the robots start from their initial cells, and the first to robots evolve to cells and respectively. The synchronization imposed by the construction of and used in [27, 26] would require that the first two robots cross from to and from to synchronously (at exactly the same time), and so on. By construction, the word generated by over the set of propositions , , satisfies formula from Eqn. (2). However, the mentioned synchronizations are disadvantageous, because they require a lot of communication and waiting, and they imply many discontinuities is the control input of each robot (due to the frequent stops at the facets of traversed cell). Intuitively, one can observe that synchronizations along prefix of for example do not contribute to the satisfaction of the formula, nor they would lead to its violation, because the robots just head towards some regions they have to visit.\endproof

As evident from the case study, deployment strategies for a satisfying run as proposed in [27, 26] require a significant amount of synchronization (and thus communication) among the team. In this paper, rather than synchronizing robots for each transition in , we aim in finding a reduced set of transitions along that require synchronization. This problem is formalized in Sec. 3.3. Its solution is given in Sec. 4, in the form of an algorithmic procedure returning a reduced number of necessary synchronization moments along , together with deployment strategies for robots. We note that in [26], we developed an algorithmic tool that tests if unsynchronized motion of the team can lead to a violation of the formula. If the answer is yes (such is the case for the case study considered in this paper), then synchronization required in [26] cannot be reduced. Therefore, the solution to the problem formulated in Sec. 3.3 constitutes a significant improvement over [26].

3.3 Minimizing Communication

Problem 3.2

Given a run of that satisfies the LTL specification , find a team control and communication strategy that requires a reduced number of inter-robot synchronizations than in the synchronization-based deployment, while at the same time guaranteeing that the produced motion of the team satisfies .

Central to our approach to Problem 3.2 is an algorithm that takes as input the satisfying run and returns a reduced number of necessary synchronization moments, where the moment along R is defined as the index corresponding to . Motivated by the fact that synchronization by stopping and waiting at region boundaries is not always necessary to produce a desired tuple, we consider two types of synchronizations: in a weak synchronization, a certain tuple is generated because there exists an instant of time at which the robots are in the corresponding cells; a strong synchronization ensures that a sequence of two successive tuples from is observed. Note that a strong synchronization at each moment in is exactly the stop and wait strategy from [27, 26]. Since the run is given in the prefix-suffix form, our algorithmic framework will return a finite set of moments that require synchronization, as well as the type for each synchronization moment.

4 Solution to Problem 3.2

This section provides a solution to Problem 3.2. We first construct an algorithmic procedure for finding a set of necessary synchronization moments (Sec. 4.1 - 4.3), and then we present a communication strategy guaranteeing that the synchronization moments are satisfied (Sec. 4.4).

Without loss of generality, we assume that run is in the prefix-suffix form (see Sec. 2). Assume that the prefix has length and the suffix has length , with , for (and , , ). For avoiding supplementary notations implying repetitions of the suffix, we assume that whenever an index along exceeds , that index is automatically mapped to the set , i.e. if , then index is replaced with , and so on. For an easier understanding, we use superscripts for identifying a robot and subscripts for indexing the cells.

For any robot and for any moment , cells and are either adjacent or identical, and the same is true for cells and . Recall that from the abstraction process of continuous robot trajectories, does not contain any successive and finite repetition of a -tuple.

4.1 Finding Synchronization Moments

The idea of constructing a solution to Problem 3.2 is to start with no synchronization moments, and iteratively test if the formula can be violated and update the set of synchronization moments and their type.

Let be an arbitrary set of synchronization moments, and let us impose the type of each synchronization moment by creating a map , where means a weak synchronization at position , and means a strong synchronization at position , .

As mentioned in Sec. 3.3, a weak synchronization at moment along run means that the tuple is reached by the robots, i.e., there is a moment when the robots are in cells , respectively. A strong synchronization at moment along run means that there is a weak synchronization at , and additionally the robots synchronously enter the next tuple (). In other words, all moving robots cross from cells to cells at the same time.

One can observe that a strong synchronization at position is not equivalent to two weak synchronizations at and . The strong synchronization guarantees that in the generated team run the tuple is immediately followed by the tuple . However, the weak moments guarantee that the and tuples are generated, but there may appear different tuples between them. It can be noted that a weak synchronization at moment is equivalent with a strong one at the same moment if and only if and the suffix of has length 1 ().

For testing the correctness of a set of synchronization moments, we developed a procedure , which takes as inputs the formula , the run , a set of synchronization moments and a map . The returned output is either “feasible” (set with map guarantees the satisfaction of the formula, no matter how the robots move in between synchronization moments) or “not feasible” (it is possible to violate the formula by imposing just the moments from with type ). We postpone the details on until Sec. 4.2.

We use Algorithm 1 for obtaining a solution to Problem 3.2, in the form of a set of synchronization moments and a map . The intuition behind this algorithm is to start with no synchronization moment () and increase until we obtain a feasible set together with a corresponding map . We show the correctness of the solution given by Algorithm 1 in Sec. 4.3, together with more informal explanations on the provided pseudo-code.

Inputs: Run , formula
Outputs: Set , map

1:  for  do
2:     , undefined
3:     ,
4:     while  do
5:        if  = “feasible” then
6:           Return set and map
7:        end if
8:        
9:        
10:        
11:        for  do
12:           if  = “feasible” then
13:              
14:              
15:              
16:              
17:              Break “for” loop on
18:           else
19:              
20:           end if
21:        end for
22:     end while
23:  end for
Algorithm 1 Solution to Problem 3.2
Remark 4.1 (Complexity)

Algorithm 1 is guaranteed to finish, because in the worst case it returns the set , meaning that strong synchronizations are needed at every moment (see Sec. 4.3). The worst case complexity requires iterations of the test_feasibility procedure.

Remark 4.2 (Optimality)

Algorithm 1 can be tailored such that it returns an optimal solution (with respect to a cost defined by weighting different synchronization moments). This can be done by first constructing all possible pairs (there are such pairs). Then, these pairs should be ordered according to their associated cost. Finally, the pairs should be tested (in the found order) against the test_feasibility procedure, until a feasible response is obtained. Of course, the worst case would require iterations of test_feasibility (when the only solution is and strong synchronization at every moment).

4.2 Testing a Set of Synchronization Moments

Procedure follows several main steps:

  1. It produces an automaton generating all the infinite words (sequences of observed propositions) that can result while the robots evolve and obey synchronization moments from (this automaton has the form of a Büchi automaton with an observation map);

  2. If necessary, is transformed into a standard (degeneralized) form;

  3. The product automaton between and the Büchi corresponding to negated LTL formula () is computed and its language is checked for emptiness;

  4. If the language is empty, the procedure returns “feasible” and otherwise it returns “not feasible”.

For step (i), the run is projected to individual runs, each corresponding to a specific robot. In each of these individual runs, we collapse the finite successive repetitions of identical states (cells) into a single occurrence (such repetitions mean that the individual robot stays inside a cell). Let us denote the resulted runs by , where prefix has length () and suffix has length (), . Together with individual projections and collapsing, we construct a set of maps , , mapping each index from run to the corresponding index from the individual run (e.g. if we have the same element in tuples and ).

Next, we obtain a generalized Büchi automaton (see Def. 2.2) whose runs are the possible sequences of tuples of cells visited during the team evolution. Thus, the language of contains all possible sequences of elements from observed during the team movement. Each robot moves without synchronizing with the others, except for the moments from set with type .

Definition 4.1

The automaton is defined as , where:

  • is the set of states,

  • is the initial state,

  • is the transition relation,

  • is the set of sets of final states,

  • is the observation set,

  • is the observation map, .

The transition relation is defined as follows: , with and , if and only if the following rules are simultaneously satisfied:

  1. if and only if and , ;

  2. if , and if , ;

  3. if such that for , where is the largest possible subset of robots satisfying this requirement, then:

    1. if , then , ;

    2. if and , then , .

Informally, requirements (a) and (b) capture a global progress/movement along individual runs of robots, by also capturing the possible situations when some robots advance “slower” (from the point of view that it takes more time for them to reach the next cell from partition). Requirement (c) restricts transitions by assuming that the agents satisfy all synchronization moments from with type given by .

Before detailing the construction of , we say that we consider as a generated word of any trajectory that infinitely often visits all sets of states from . This definition of generated words is exactly the definition of accepting words of generalized Büchi automata. Moreover, has a structure similar to a Büchi automaton, which has final sets of states that are infinitely often encountered along an accepted run.

The set of sets of final states of () is created by using Algorithm 2. The construction from Algorithm 2 matches the purpose of generated runs of , in the sense that any run contains infinitely many revisits to tuples from suffix of where synchronization is imposed. More details on the construction of are given in Sec. 4.3.

1:  
2:  if  then
3:     
4:  else
5:     Assume
6:     
7:     for  do
8:        
9:     end for
10:  end if
Algorithm 2 Set of final sets of automaton

Once is constructed, we have to check if there exists a generated word of that violates the LTL formula (by satisfying the negation of the formula). As mentioned at the beginning of this section, this basically implies checking for emptiness the language of a product between and (steps (ii)-(iv)).

Similar to finding a run as mentioned in Sec. 2, this emptiness checking can be done by using available software tools for normal (degeneralized) Büchi automata. In case that contains more than one set, has the structure of a generalized Büchi automata. If this is the case, we first convert into a degeneralized form (as mentioned in Sec. 2), and then we construct the product with . The construction of this product is similar to the one constructed between transition systems and Büchi automata [8]. The only difference is that the set of final states of product equals the cartesian product between final states of (degeneralized) and the final states of Büchi.

Example of constructing : We include here a simple example, solely for the purpose of understanding the construction of . Therefore, we do not define an environment, nor we impose an LTL formula. Consider a team of 2 robots and the following run :

(4)

has a prefix of length 1, and a suffix of length 3 (the suffix is represented between square brackets).

First, assume an empty set of synchronization moments, . By projecting to individual runs and collapsing successive identical states, we obtain: and , where , , , , , , . The obtained automaton is given in Fig. 4(a), where the initial state is . This automaton is already in degeneralized form (it has a single set of final states), because does not contain synchronization moments along suffix. Also, note that once the final set of is reached, it is never left. This corresponds to the fact that both robots reach and follow their suffixes (independently), and any possible observed sequence during the movement corresponds to a word generated by .

Now, assume a set , with and . This means there is a strong synchronization at the beginning of every iteration of suffix of (state ) and a weak synchronization at the end (state ). The automaton created as described in this subsection is given in Fig. 4(b). This automaton has the same set of states and observations as , but the set of transitions is reduced because of synchronization rules. is in generalized form, because it has 2 sets of final states ( and ). They gray states become unreachable because the reduced transitions of . Note that any word generated by infinitely often visits state (which corresponds to the first synchronization moment from ) and state (corresponding to the second synchronization moment from ). Also, there is only one outgoing transition from , in accordance with the strong synchronization in this state. It should be clear why in this case we have 2 sets of final states: if we had a single set, containing both and , then would have been accepting words like . However, such a word would correspond to a spurious (impossible) movement of robots, because state would never be visited, although it corresponds to a synchronization moment. \endproof

(a) (b)
Figure 4: Examples of two automata constructed as described in Sec. 4.2, from run from Eqn. (4): (a) ; (b) , with and . Final states are double encircled, with different line types corresponding to different final sets, and the gray states are not reachable.

4.3 Correctness of Solution to Problem 3.2

Theorem 4.1

Any solution returned by Algorithm 1 is a feasible solution to Problem 3.2, and Algorithm 1 returns a solution in a finite number of steps.

{proof}

The correctness of Algorithm 1 and of the “test_feasibility” procedure results by the construction we performed in this section, as detailed below.

Correctness of “test_feasibility” procedure: We first prove that the “test_feasibility” procedure cannot yield a “feasible” output if the inputs and can produce a violation of the formula. This comes from the requirements of the transition relation and from the construction of . Requirement (a) from definition of means that does not self-loops, except for the case when all individual runs have suffixes of length 1 (in this case a self-loop exists for reiterating the suffix). Requirement (b) results from the fact that every robot follows its individual run and iterates the suffix; the fact that there is no synchronization (a moving robot might not change its current cell, while others advance along their individual runs) is captured by the possibility of having for some robots. Thus, requirements (a) and (b) capture a global progress/movement along individual runs of robots, by enforcing iterations of individual suffixes. If we ignore requirement (c), and we assume that is just a single set constructed as in line 3 of Algorithm 2, can generate any possible run resulted while robots evolve without any synchronization (set and map were not yet used). Thus, if “test_feasibility” returns a “feasible” answer, it means that even the unsynchronized movement is feasible, so the motion restricted by would definitely imply a satisfaction of . However, such an approach would be very conservative, because it does not restrict the possible generated runs of based on and 2.

Conservativeness reduction of : Requirement (c) restricts transitions based on synchronization moments and their type. Thus, (c.(1)) guarantees that if one or more robots arrived at a synchronization moment, then they will not continue following the individual runs (by changing their states) unless all other robots arrived at that synchronization moment. This way, (c.(1)) captures the fact that the weak synchronization moments and the first part of the strong ones (visiting a certain tuple) are satisfied. Requirement (c.(2)) ensures that a tuple of cells corresponding to a strong synchronization moment is synchronously left by all robots that have to move at that index (the moving robots synchronously go to the next state from their individual run, while for other robots implies remaining in the same state/cell). The reduced set of transitions of captures the satisfaction of all synchronization moments, and includes all possible unsynchronized (independent) movements of robots between synchronization moments. Therefore, the correctness of “test_feasibility” is not affected, while its conservativeness is reduced.

Construction of : If there is no synchronization moment in the suffix of , then contains only one set, equal to the cartesian product of the sets of states composing the suffixes of individual runs , (line 3 in Algorithm 2). This is because no synchronization moment in suffix of means no synchronization moments in suffixes of individual runs. Therefore, the robots independently follow their suffixes and any -tuple from set can be infinitely often observed during the team evolution. In this case is still too conservative, because it can generate many runs that cannot result from the actual movement of robots (e.g. infinite surveillance of just two states from ).

The set of accepted runs is drastically reduced if there are synchronization moments in suffix of (and also in individual suffixes). In this case, will contain sets (in Algorithm 2, ). Each of these sets contains just one tuple, which corresponds to one synchronization moment along individual suffixes. This construction comes from the following aspects: (i) due to synchronization moments along suffixes, we have additional information about some infinitely visited states, and considering as in line 3 of Algorithm 2 would be too conservative. (ii) If there are more synchronization moments along suffix, having a single set of final states that contains all the corresponding tuples would be again too conservative. This is because the transitions of might allow infinitely often revisits to just a single element of that set, and we might get spurious counterexamples when testing against the negation of LTL formula. (iii) In case of a strong synchronization moment along the suffix, adding two states (tuples corresponding to and ) in the corresponding element of would not bring any additional benefit than adding just (as done in Algorithm 2). This is because requirement (c.(2)) implies that the only possible transition from state corresponding to is to the state corresponding to . Therefore, construction of as in Algorithm 2 further reduces the conservativeness of by restricting its set of generated runs with respect to and . still generates all possible sets of tuples that the team can follow while moments from with type are satisfied.

There is one more step in proving the correctness of “test_feasibility”, namely that there exists a pair for which “test_feasibility” returns a “feasible” output. This pair is and , . Indeed, in this case every state of has only one outgoing transition, and the only run generated by is . The word generated by satisfies formula (because was constructed by assuming it is strongly synchronized at every position). Therefore, the language of the product between the degeneralized and is empty, and “test_feasibility” returns “feasible”.

Correctness of Algorithm 1: We now prove that Algorithm 1 returns a feasible pair in a finite number of steps. First, we explain Algorithm 1 and we show that the worst case ( and , ) is returned, if no other less restrictive pair was encountered.

Algorithm 1 starts with and undefined, and increases with at most one moment at every iteration of the “while” loop from line 4. For this, it goes from the last index in suffix of (moment ) towards the first one, and it constructs a temporary set of synchronization moments (). includes all the moments from (initially none) and all indices after the current moment until . All moments following the currently tested one are first assumed to be weakly synchronized, and if no solution is obtained, they will be assumed strong (line 10 and “for” loop starting on line 1). This is because we consider a strong synchronization more disadvantageous than a weak one, due to the waiting and communication at borders separating adjacent cells. The current moment is first tested with a weak synchronization, and if no feasible answer results, it is tested with strong synchronization (loop starting on line 11). If the current test (with and ) is feasible, we add to set only the current moment, with its current synchronization type stored in map (lines 13, 14). Then, on line 15 we update the lower bound for the current synchronization moment (it doesn’t make sense to go lower than the just found moment), and we start again the while loop on line 4 (from moment towards the lower bound). For each disjoint assignment of “synch_type” (“for” loop on line 1), the currently tested moment inside the “while” loop from line 4 is build on the feasible moments existing in and until that instant (those moments are included in and on lines 8, 9).

Once a feasible pair is encountered, all future iterations from Algorithm 1) try to reduce the number of moments from and relax their synchronization type. In the worst case the same pair will be returned: if no other feasible pair included in this one is found, after a number of iterations of the “while” loop the same pair is again encountered (but this time, the first element of the old/feasible is already in ). Now, the second element from the old (the first from the new ) is added to and the “while” loop is again iterated, and so on. Thus, once a feasible pair is encountered, Algorithm 1 finishes in a finite number of steps.

For proving that a feasible pair is ever encountered, we show that, if no other feasible pair is found, the algorithm eventually tests the pair where and , (this pair is deemed feasible by the “test_feasibility” procedure, as shown before). When (first iteration of “for” loop on line 1), we iterate the “while” loop for times and we do not get any feasible result. For we would get and , after another iterations of the “while” loop. Even though we get a “feasible” answer from “test_feasibility”, we add just the first moment from to (so ) and reiterate. This time, at the iteration of the “while” loop we would get the same pair (when ). Now, is updated to and the “while” loop is reiterated with . Since each iteration of “while” loop includes 3 calls to the “test_feasibility” procedure, the total number of such calls is: .

By using a similar reasoning as above, it can be easily shown that if there exists a set and a map for which =“feasible”, then the pair will be encountered by Algorithm 1 if other feasible pair is not encountered before. This shows why Algorithm 1 does not necessarily find an optimal solution (with respect to a cost defined by weighting different synchronization moments): once a feasible pair is encountered, all future iterations test only subsets of , not other sets from . \endproof

4.4 Communication and Control Strategy

We complete the solution to Problem 3.2 by providing a deployment strategy such that the synchronization moments from set with type are correctly implemented. A weak synchronization at moment along is achieved by enforcing each robot to wait inside cell (and signal this to others) until it receives a similar signal from all other robots. A strong synchronization at moment is accomplished by first enforcing a weak synchronization at moment , and then temporary stopping the robots for which just before leaving cell (and entering ).

Since we need individual strategies, we have to adapt the set and map to descriptions suitable for each robot that moves along its individual run , . To solve this, for each robot we construct a queue memory , where each entry contains the index along when there should be enforced a synchronization, and the synchronization type. Alg. 3 creates these queue memories by adding entries, in the ascending order of moments from .

1:  
2:  for all  do
3:     Assume that is sorted and states in are enumerated sequentially
4:     
5:     
6:     Add entry at the end of
7:  end for
Algorithm 3 Queue memory
1:  
2:  while TRUE do
3:     Read first entry from
4:     Read second entry from
5:     if  then
6:        while “ready” signals not received from all other robots do
7:           Broadcast a “ready to synchronize” signal
8:           Apply convergence controller inside current cell from run
9:        end while
10:        if  then
11:           Apply controller driving to the next cell until border between and is reached
12:        end if
13:        if  then
14:           while “ready” signals not received from all other robots do
15:              Broadcast a “ready to synchronize” signal
16:              if  then
17:                 Stop robot
18:              else
19:                 Apply convergence controller inside current cell
20:              end if
21:           end while
22:        end if
23:        if  then
24:           Remove first entry from
25:        else
26:           Move first entry from to the end of
27:        end if
28:        if  then
29:           
30:        end if
31:     else
32:        if  then
33:           Apply controller driving to the next cell until border between and is reached
34:           
35:        else
36:           Apply convergence controller inside current cell
37:        end if
38:     end if
39:  end while
Algorithm 4 Individual strategy for robot

The queues will be used by the robots in a FIFO manner, as in Alg. 4. Each robot follows the infinite run , by applying correct feedback controllers and by synchronizing with other robots when required. After fulfilling a synchronization moment, the corresponding entry from is removed or moved to the end, depending on the inclusion of the current moment in prefix or suffix. The current index in is incremented based on specific conditions, for correctly handling the situations when two or more synchronization moments from yield the same value through map . Note that the robots not changing their cell when a strong synchronization moment is required still synchronize twice on that moment (for the weak and then the strong part), but they apply a convergence controller inside current cell.

5 Case Study Revisited

This section concludes the case study illustrated throughout the paper, by applying the procedure described in Sec. 4 to the run from Eqn. (3). We obtain only two weak synchronization moments, at indices 8 and 12 of run (first and fifth positions of every repetition of suffix). This makes sense, since the propositions satisfied by the team at the two synchronization moments are the two sets of regions ( and ) that are required to be visited for the satisfaction of the formula.

The individual runs of the robots are given in Eqn. (5), where the square brackets delimitate each suffix, and the two weak synchronization moments are marked in bold:

(5)

The control and communication protocol from Sec. 4.4 points to the following deployment strategy for each robot: the robot moves along its individual run without any communication, until it encounters a required synchronization moment. Then, it broadcasts that it is in a “ready” mode for the synchronization moment, and it waits inside the current cell until it receives “ready” signals for the current moment from all other robots. After this, each robot evolves again individually (without any synchronization) until the next synchronization moment. Note that for the above example, once robot 1 reaches its suffix it keeps applying a convergence controller inside and broadcasting a “ready” signal (so that it does not induce waiting for other robots).

Some snapshots from the deployment (implemented according to Sec. 4.4) are shown in Fig. 5, where two repetitions of the suffix for each robot are included. A movie for the case study is available at http://hyness.bu.edu/~software/unicycles.mp4. For comparison, if we avoided solving Problem 3.2 and instead used the deployment strategy from [26], we would get the team trajectory illustrated by the movie http://hyness.bu.edu/~software/unicycles-full-synch.mp4. In this movie, we can see that the motions of the robots are not as “smooth” as our proposed approach, and the iterations for each suffix require more time. Our approach is more suitable for real experiments as robots have less frequent stops at region borders.

(a) (b) (c) (d)
(e) (f) (g) (h)
Figure 5: Several configurations reached during movement ((a)(g)), and traces of robots (h). (a) Robot 1 (green) heads to , robot 2 (blue) heads to , robot 3 (red) heads to ; (b) Robot 3 begins to wait for the first weak synchronization moment from suffix; (c) Robots 2 and 3 are waiting (by converging inside their regions); (d) First synchronization moment is accomplished, all robots continue normal movement; (e) Robot 3 begins waiting for the second synchronization moment; (f) Synchronization accomplished, robots 2 and 3 head back to and respectively; (g) Robot 3 begins waiting for the first synchronization moment from suffix, and when robot 2 reaches a new iteration of suffix begins.

Computation time: The most computationally intensive part of the solution to Problem 3.1 is finding a run (as in Sec. 3.1 and 3.2). For our case study, this took about 100 minutes on a medium performance computer. In contrast, the solution we proposed for Prob. 3.2 (Sec. 4) took only 30 seconds. To generate a solution for Prob. 3.2, 26 iterations of the test_feasibility procedure were performed until the set of synchronization moments was found.

6 Additional Example

This section briefly presents another example on the same environment as in Fig. 1, but considering two robots and the LTL formula: