Mind the gap: Robotic Mission Planning Meets Software Engineering

(1)

Mind the gap: Robotic Mission Planning Meets Software Engineering

Mehrnoosh Askarpour

mehrnoosh.askarpour@polimi.it Politecnico di Milano

Milan, Italy

Claudio Menghi

claudio.menghi@uni.lu University of Luxembourg Luxembourg, Luxembourg

Gabriele Belli

gabriele.belli@alten.it Alten Torino, Italy

Marcello M. Bersani

marcellomaria.bersani@polimi.it Politecnico di Milano

Milan, Italy

Patrizio Pelliccione

patrizio.pelliccione@univaq.it Chalmers|University of Gothenburg

and University of L’Aquila

ABSTRACT

In the context of robotic software, the selection of an appropriate planner is one of the most crucial software engineering decisions.

Robot planners aim at computing plans (i.e., blueprint of actions) to accomplish a complex mission. While many planners have been proposed in the robotics literature, they are usually evaluated on showcase examples, making hard to understand whether they can be effectively (re)used for realising complex missions, with hetero- geneous robots, and in real-world scenarios.

In this paper we propose ENFORCE, a framework which allows wrapping FM-based planners into comprehensive software engineering tools, and considers complex robotic missions. ENFORCE relies on (i) realistic maps (e.g, fire escape maps) that describe the environment in which the robots are deployed; (ii) temporal logic for mission specification; and (iii) Uppaal model checker to compute plans that satisfy mission specifications. We evaluated ENFORCE by analyzing how it supports computing plans in real case scenarios, and by evaluating the generated plans in simulated and real environments. The results show that while ENFORCE is adequate for handling single-robot applications, the state explosion still represents a major barrier for reusing existing planners in multi-robot applications.

KEYWORDS

Planning, Robotics, Formal Methods, Timed Automaton, Temporal Logic, Model Checking, Uppaal

ACM Reference Format:

Mehrnoosh Askarpour, Claudio Menghi, Gabriele Belli, Marcello M. Bersani, and Patrizio Pelliccione. 2020. Mind the gap: Robotic Mission Planning Meets Software Engineering. In8th International Conference on Formal Methods in Software Engineering (FormaliSE ’20), October 7–8, 2020, Seoul, Republic of Korea.ACM, New York, NY, USA, 11 pages. https://doi.org/10.1145/3372020.

3391561

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and /or a fee. Request permissions from permissions@acm.org.

FormaliSE ’20, October 7–8, 2020, Seoul, Republic of Korea

ACM ISBN 978-1-4503-7071-4/20/05. . . $15.00 https://doi.org/10.1145/3372020.3391561

1 INTRODUCTION

Robotic software engineering concerns the development of techniques that enable a systematic and rigorous development of robotic software [11]. As classical software, robotic software is not mono- lithic, as it is usually obtained by assembling already existing components, as well as developing brand new ones (when needed). The lack of systematic and rigorous techniques, which promote reuse of components and facilitate their integration, has been identified as one of the major challenges in the robotic domain [31].

Formal methods are mathematical approaches to software and system development, which support rigorous specification, design and verification [20]. These approaches have been largely used in the robotic domain [22], and one of their major applications is mission planning, which is the topic of this work. Given a high level defined goal, calledmission[40], e.g., “robot A goes to position p, brings a box, goes to positionq, waits 10 seconds and, finally, reaches positionrand releases the box”, robotic mission planning aims at computing a set of actions that, if performed, ensure the accomplishment of the goal.

Many FM-based planners have been used in the robotic domain (e.g., [21, 27, 48, 50]). However, planners are usually evaluated on showcase simple examples, have limited usage assumptions (often not explicitly documented), and their scalability properties are usually not thoroughly evaluated. This restricts the usage of these planners in industrial contexts, where there is an increasing need for Integrated Formal Methods (iFMs) [22, 38]. Integrated Formal Meth- ods refer to the integration of multiple formal methods, or/and semi- or non-formal approaches, that complement each other. Following this line of thought, integrating mission planners within SE-based robotic frameworks requires to precisely understand when and how planners can be reused. Thus, there is a need for robotic mission planning to meet software engineering.

The goal of the paper is to perform a preliminary step to fill the gap between robotic mission planning and software engineering.

To this end, we first identify a set of features that robotic mission planners should possess to address complex problems coming from the industrial domain. Specifically, these features refer to several aspects of the application, namely, the mission to be accomplished by the robots (F1), the robots capabilities (F2), the team of robot(s) (F3), and the environment in which the robots are deployed (F4).

(2)

We proposeformally vErified plaNning soFtware fOr Real-world sCEnarios(ENFORCE), an approach for integrating FM-based planners and comprehensive software engineering tools, that allows designer to deal with mission planning for complex robotic scenarios. ENFORCE supports a systematic and rigorous design workflow, fosters the reuse of already implemented third-party components, and improves maintainability, as it promotes separation of concerns by modeling several aspects of the robotic application (i.e., robots, environment and mission) with distinct artifacts. Specifi- cally, ENFORCE makes use of two distinct formal models to describe independently how robots perform actions and move within their environments, and the map that describes the environment in which the robots are deployed. The mission the (team of ) robot(s) should achieve is specified by means of a temporal logic formula, written in terms of robot actions and positions of the environment. All these artifacts are automatically translated into the input language of a model checker, by means of a formally-defined translation. EN- FORCE can leverage off-the-shelf model checkers (provided they enable mission planning) to determine (i.e., synthesize) the exis- tence of a trace that satisfies the mission specification, and that can be used to derive the motion plans for the robots operating in the environment.

To implement our approach, we use the Uppaal [37] model checking tool, since it can be used to realize mission planning that features F1-F4. We rely on existing robotic techniques [8, 44] to represent the area in which the robots are operating as a tiling of the plane with squared cells. The area is modeled, with various precision lev- els, using Timed Automata (TA), i.e., the input modeling formalism of Uppaal. Locations of TA are used to capture both the cells of the map and the dynamics of the robots. The mission is specified in quantitative temporal logic (i.e., TCTL).

For the sake of simplicity, in this work, we assume that all robots are controllable, i.e., uncontrollable agents are not operating in the environment. Despite this simplification, we encounter different hurdles that hamper an effective integration of existing FM-based planning techniques in SE workflows.

To evaluate our approach, we assess the effectiveness and correctness of the overall synthesis procedure implemented in ENFORCE.

The effectiveness is evaluated by checking whether ENFORCE syn- thesizes plans in a reasonable time, both in the case of single-robot (RQ1) and in the case of multi-robots (RQ2) applications, when maps of real environments are considered. Correctness is evaluated by checking whether the computed plans allow robots to achieve the specified mission. This is performed both by evaluating the behavior of the robots in simulated environments (RQ3) and in real environments (RQ4). Our results show that ENFORCE can effectively synthesize correct plans, in reasonable time, that ensure the mission satisfaction for simulated and real environments, with realistic size, and single-robot applications. Conversely, ENFORCE is not able to compute a plan in a matter of minutes for multi-robots applications deployed in realistic scenarios. We critically analyze and discuss our results.

Integrating existing planning techniques within SE workflows is not naive, yet requires an in-depth knowledge of the planner features and its scalability, especially when the number of robots increases. We believe that our thorough empirical evaluation paves the way for a more critical analysis of the features of existing

Table 1: Number of papers and venues considered in the fea- ture collection

Venue Acronym #Paper

Formal Methods FM 1

Conference on Formal Methods in Software Engineering FormaliSE 3

Conference on Robotics and Automation ICRA 2

Symposium on Intelligent Autonomous Vehicles 1

Conference on Intelligent RObots and Systems IROS 3 Conference on Networking, Sensing and Control ICNSC 1

Conference on decision and control CDC 3

Journal of Systems and Control 1

Transactions on Robotics T-RO 1

American Control Conference ACC 3

European Control Conference ECC 1

Journal of Automatica 2

Journal of China Information Sciences^∗ 1

FM-based planning techniques to promote their reuse within SE frameworks.

Structure.Sec. 2 describes the features of the planner we are considering in this work. Sec. 3 introduces the basic notions on Timed Automata (TA) and quantitative temporal logic (TCTL). Sec. 4 presents ENFORCE. Sec. 5 shows our experimental results and Sec. 6 discusses our findings. Finally, Sec. 7 concludes.

2 COLLECTION OF THE PLANNING FEATURES

We are considering mobile platforms and static/mobile manipula- tors, since they are broadly used in the industrial domain [4, 5], they are regulated by ISO standards [1, 2], and can work together with or under supervision of human operators [3]. In order to make our tool applicable on various available industrial robotic systems, we performed a thorough state-of-the-art analysis on robot motion/mission planners. We had collected 24 different works focusing on FM-based planners, that were presented in 14 different venues (see Table 1). These works were collected by considering the knowledge of the authors in the field, complemented by a snowballing literature review. We reviewed these papers, and we identified recurrent features of planners.

Based on the results of our review and a discussion with our industrial partner, we identified four main features (F1,F2,F3, and F4), discussed below.

F1 - Expressing explicit time concerns in robotic missions. Planners should analyze missions containing explicit time constraints. For example, the mission “visit region A, then Bwithin 10 seconds” forces a robot tofirstvisit A andthenB within an explicit time constraint, i.e., within 10 seconds.

Logic-based languages are broadly used in the literature for specifying the mission that robots should achieve [22, 38]. The columnLogandTpof Table 2 report, respectively, the logic that has been used to specify missions for each paper, and whether explicit time concerns have been specified.

LTL has been extensively used to express a rich variety of behavior including robot missions [28, 32, 39, 40, 42]. It also benefits from a consolidated knowledge containing algorithms for verification and synthesis of controllers. However, it lacks a metric notion of time, and it is not able to express bounds on the delay between events. In LTL, one can express that an event B follows an event A,

(3)

Table 2: Analysis of related work on planning. Log: the used logic;Tp: explicit temporal concerns;MA: multi-agent teams;Act: actions rather than motion;Sync: team synchronization;Mp: map of realistic environment;Exp: real experiments; Tool: the used verification tool.

F1 F2 F3 F4

Ref. Log Tp Act MA Sync Mp Exp Tool

[30, 44] TCTL ✓ ✗ ✓ ✗ ✗ ✗ Uppaal

[8] TCTL ✗ ✗ ✓ ✗ ✗ ✓ Uppaal

[35] CTL ✗ ✗ ✓ ✗ ✗ ✓ C-SMV

[49] LTL ✗ ✗ ✗ ✗ ✗ ✓ ✗

[27] LTL ✗ ✗ ✗ ✗ ✗ ✗ ✗

[46] LTL ✗ ✓ ✗ ✗ ✗ ✓ ✗

[32] LTL ✗ ✗ ✓ ✗ ✗ ✓ ✗

[12] LTL ✗ ✓ ✓ ✓ ✗ ✓ ✗

[33] LTL ✗ ✓ ✓ ✓ ✗ ✗ ✗

[34] LTL ✗ ✓ ✓ ✓ ✓ ✓ ✗

[47] LTL ✗ ✗ ✓ ✗ ✗ ✗ ✗

[29] LTL ✗ ✓ ✓ ✓ ✗ ✗ ✗

[21] LTL ✗ ✓ ✓ ✓ ✓ ✗ Matlab

[25, 28, 39, 48] LTL ✗ ✓ ✓ ✓ ✗ ✗ Matlab

[13, 26] LTL ✗ ✓ ✗ ✗ ✗ ✗ Matlab

[43] MTL ✓ ✓ ✓ ✓ ✗ ✓ ✗

[52] MTL ✓ ✓ ✗ ✗ ✗ ✗ CPLEX

[42] MTL ✓ ✓ ✓ ✓ ✗ ✗ Matlab

but it is not possible to limit the time interval between the two events by imposing, for instance, that the delay is smaller than 5 time units. Therefore, a number of authors [8, 43, 44] have re- cently considered formalisms that allow for expressing explicit time constraints, such as Metric Temporal Logic (MTL) [36], or Timed Computation Tree Logic (TCTL) [6]. However, some of these works are mostly theoretical, some of them do not explicitly consider how robots synchronize and perform actions, and usually they are not validated on real maps but consider small environment abstractions (usually represented through small-size matrices of cells representing locations of the environment).

F2 - Replicating functionalities and actions of a robot. In- dustrial robots are used for many different activities, commonly realized by means of arms, or end effectors. Thus, planners have to consider not only how robots move in their environment, but also other types of functionalities, such as pick and place, grab, welding, assembly. ColumnActin Table 2 shows if a paper covers planning by considering functionalities of robot other than movements.

F3 - Managing multi-robots and their action synchronization. Planners should be able to manage both single-robot and multi-robot systems. A robotic system could consist of multiple robots, which potentially collaborate, or compete, for achieving a given mission. Thus, their interaction, collaboration, and synchronization must be considered for planning their actions.

The analysis of the behavior of a team of robots, and the synthesis of the motion plans that regulate their movements over a bi- dimensional area have been studied in the last decade [32, 34, 43, 45].

In Table 2, columnMAindicates if a paper supports multi-robots, and columnSyncspecifies if they collaborate to achieve a goal together, and need to synchronize their actions.

F4 - Considering realistic environments. Planners should be able to perform on realistic environments. Most of the planners in the literature consider abstractions of real environments that are represented by grid of cells, usually of very limited size, e.g., [44]. Thus, it is difficult to evaluate how the algorithms scale when the size of the environment (and of the corresponding grid of cells) grows, such as when planning must be performed on real buildings. In Table 2, the✓symbol in columnMpindicates that the planning procedure has been applied on maps representing realistic buildings.

The majority of the planners, except for [21, 34], are only evaluated through simulation, and no experiments in real environments have been performed. In Table 2, columnExpindicates if an experimental evaluation in a real scenario has been performed, and algorithms are deployed on real robots.

Most of the planners are developed by means of ad-hoc solutions, rather than built on pre-existing solutions with proven effectiveness. The use of consolidated tools has many advantages. In many cases the implemented procedure is stable and efficient, as the tools include optimizations that work at the engine level. Moreover, consolidated tools might offer different options to the user for the analysis of the system, such as, for instance, the state space ex- ploration policy (either breadth first or depth first). The user can use off-the-shelf tools without the need of implementing ad-hoc solutions on specific test cases. In the last column of Table 2, the✗ symbol marks the works which used ad-hoc solutions. Otherwise, we reported the name of the tool used for planning.

Related Work.The robotic mission planning problem has been widely explored in the literature and in the FM community (see Table 1 and Table 2). Some of these works considered the problem of decision making and task planning as a two-player temporal logic game between the planner component and its environment [51], other focused on planning multi-robot systems and collision avoid- ance [9, 16, 30]. From a technological perspective, several solutions have been proposed, such as the use of Satisfiability Modulo The- ories to verify the fulfilment of defined missions [15] or model checkers [18]. Planning robotic systems has also been analysed by considering other characteristics, spanning from hardware features [23, 23] to the provision of support to people with disabil- ities [14]. However, while these works provide FM-solutions for specific problems, less attention is usually given to making the solutions reusable, and to their evaluation from a SE perspective.

Some works have also been done to help users in engineering robotic applications. RoboChart [41] provides a language for mod- elling robotic applications. It allows user to verify the models of the robotic applications by reusing existing model checkers and theo- rem provers. RobotML [17] is a robotic modeling language provided as a Papyrus plugin, that enables the design of robotic applications, their simulation, and their deployment to multiple target execution platforms. FLYAQ [10] is a tool for defining missions of teams of multicopters. It enables the automatic generation of the detailed flight plan the multicopters have to follow.

3 BACKGROUND

This section recalls the definition of Timed Automata (TA) [7] and TCTL, which are the formalisms used in the rest of this work.

(4)

Table 3: The notation used in definition of a TA.cis a natural number,dis an integer, and∼∈ {<,=}.

Notation Definition

X finite set of clocks with real values

Y finite set of integer variables

Act finite set of actions

η:=x∼c| ¬η|η∧η clock constraints (x ∈X)

Γ(X) set of clock constraints

ζ:=y∼d|y∼y^′| ¬ζ|ζ∧ζ variable constraints (y,y^′∈Y)

Γ(Y) set of variable constraints

assign(Y):={y:=d|y∈Y} set of assignments

Timed Automata.Given the notation introduced in Table 3, a timed automaton(TA) is defined by a tuple⟨Q,q0,v⁰,I,T⟩, where

(1) Qis a finite set of locations, (2) q0∈Qis the initial location,

(3)v⁰:Y→Nis a function assigning each variable inYwith an integer value,

(4) I:Q→Γ(X)is an invariant assignment function, and

(5)T ⊆Q×Q×Γ(X)×Γ(Y)×Sync×℘(X)×℘(assign(Y))is a

finite set of transitions such thatSync=Act× {!,?}. Theconfigurationof a TA is denoted by a pair(q,v), whereq∈Q is the current location of the automaton, andvis a function over X ∪Y that assigns a non-negative real value to every clock ofX and an integer to every variable ofY.

A configuration change(q,v)→(q^′,v^′)changes the configuration of the TA from(q,v)to(q^′,v^′),and occurs due to either a transition inT (discrete transition), or time elapsing (time transition).

When a discrete transition(q,q^′,σ,η,ζ,S,A)∈T is fired:

(1) the clock and the variable values invsatisfy, respectively, guardsηandζ, andv^′satisfies the invariantI(q^′); (2) for each clockx, ifx is inS, then it holds thatv^′(x) =0,

otherwisev^′(x)=v(x); and

(3) for each variabley∈Y, it holds thatv^′(y)=dandy:=dis an assignment inA.

When a time transition is fired:

(1) location does not changeq=q^′;

(2) each variablesy∈Y retains its value, andv^′(x)=v(x)+δ, withδ∈R^≥0, for allx ∈X; and

(3) invariantI(q)is satisfied by all assignments of the clocks fromvtov^′.

Arunorexecutionof a TA is a (possibly infinite) sequence of configurations(q0,v0)(q1,v1)(q2,v2)· · · such that, for anyi≥0, (qi,vi)→(q_i+¹,vi+1)is a discrete transition or a time transition.

The set of all the executions of a TAAis indicated withR(A). When several TAs are considered, the configuration contains locations of all of them and the values of all their clocks and variables. The symbols inΣare used to constrain the executions of the TA—i.e., the ways in which a network of TA synchronize while changing the configuration of the system. Each symbolσ ∈Σthat

labels a transition has the formσ? orσ!. Informally, two TAs synchronize when they simultaneously perform a discrete transition respectively labeled withσ? andσ!.

For example, Figures 1 shows a network of TA representing a mobile robot with two components, i.e., a moving platform and a gripper, that is used in an industrial environment to move around and collect objects from a number of object storages which contain.

The robot is able to load objects in a mounted bin (actionro_load) and move (actionro_move) within its environment.

The model of the moving platform described in Figure 1a shows that the robot alternates between “moving" and “still". In particular, the robot traverses the distance between its starting point and reaches the first storage (moving) and then stops for loading (still).

The same thing is repeated from the first storage to the next one until all of the storages are met. This alternation is regulated by the values assigned to the clockxwhich constraints the duration of moving. The clockxconstraint the robot movement to last at most ten time units. As the value ofxreaches ten, the robot stops moving andxis reset.

We assume that a group of storages contain only five objects and the rest contain ten objects. The model of the gripper described in Figure 1b can alternate among three different states: “idle", when no object have to be loaded, “loading1", when five objects (n=5) have to be loaded, and “loading2", when ten objects (n=10) have to be loaded. Loading five objects requires 10 seconds, while loading ten objects requires 17 seconds. The robot is not supposed to move unless the loading action is completed (idle).

The synchronization of the two TAs in Figure 1 forces the mobile platform to become still before the gripper starts loading. Similarly, the gripper should reach the state “idle" before the mobile platform starts moving.

TCTL.Uppaal allows for specifying missions through an exten- sion of the CTL logic, which also contains “time related" constraints (TCTL). Letϕbe a boolean combination of formulae on variables and clocks such as, for instance,x ≤10∧loadinд1 indicating that clockxis less than or equal to 10 and that TA of Figure 1b is in location “loadinд1". TCTL allows the specification of properties in the form∀ Gϕ,∀ Fϕ,∃ Gϕand∃ Fϕwhose semantics is defined as follows:

∀ Gϕ ⇔ for every execution,ϕholds globally

∀ Fϕ ⇔ for every execution,ϕholds eventually

∃ Gϕ ⇔ exist a path such thatϕholds globally

∃ Fϕ ⇔ exist a path such thatϕholds eventually.

4 FORMALLY VERIFIED PLANNING

SOFTWARE FOR REAL-WORLD SCENARIOS

An overview of the ENFORCE framework is presented in Figure 2.

ENFORCE promotes the reuse of FM-based planners by integrating low-level FM-based planners with higher-level SE artifacts. EN- FORCE takes as inputs an image that describes the environment in which the robots will be deployed (1), e.g., the layout of a building, the models that describe the robots’ behaviors (2), and the missions the robot should achieve, i.e., the properties of interest (3). Those artifacts are combined into a comprehensive model of the robotic application (5), and used to compute a set of plans ensuring the

(5)

moving x ≤10 still

start

sync:roload? assign:x:=0 sync:romove! guard:x=10∨x=17

(a) Timed Automaton modeling the moving platform of the robot.

idle start

loadinд1 x ≤10 loadinд2

x ≤17

guard:x =10 sync:romove? guard:n=5 sync:roload! assign:x :=0

guard:n=10 sync:roload! assign:x :=0 guard:x =17 sync:romove?

(b) Timed Automaton modeling the gripper of the robot.

Figure 1: A network of Timed Automata

mission achievement (6). Finally, the plan is performed by sending executable actions to the physical robots, or robot simulators (7).

In this section, we describe the inputs of ENFORCE (Section 4.1), and the procedures used by ENFORCE to compute the plans to be executed by the robots (Section 4.2).

4.1 Inputs

The inputs of ENFORCE are discussed in the following.

Environment Description(1). The environment processed by ENFORCE is described using a high-level description of the environment represented by the images of the buildings contained in classical building layouts, such as the one used to indicate emer- gency exits in public buildings. An example of environment that can be processed by ENFORCE, representing the Building 22 of Politecnico di Milano, is reported in Figure 3.

Models of the Robots(2). In our envisioned usage, the models of the robots are provided by third party companies, such as robots manufacturers, or designed by developers that want to use ENFORCE. The model of the robot describes how a robot (1) moves, (2) performs actions, and (3) synchronizes with other robots.

Robot Movements.The TA that models the robot includes (at least) five locations, one representing the idle state (s), and four corresponding to the movements in the four directions, i.e., up (u), down (d), left (l) and right (r). Note that, for simplicity we had only considered four directions for movement. However, the approach can be extended to consider more complex models of robot movements. Figure 4 presents an example of model of the robot discussed in the following. When the robot undertakes a motion action, one transition from locationsto one of the locations representing the

Environment Description (Building Layout)

Robots Description

(TA)

Robotic Mission (TCTL)

1 2 3

Environment Description2TA

TANetworkCreation

FM-based Plan

Computation PlanExecutor

4 5

6 7

Legend

Input Procedure

Figure 2: ENFORCE overview.

motions is performed. For the actionαto be performed, a transition of the robot labeled withα! is fired. For anyα∈ {u,d,l,r}, the TA changes the current location into locationαto model that the robot has just finished actionα. All the transitions leading fromstoα are labeled with a guard that encodes the duration of the shift. The automaton measures the temporal delay ensued from the kinetics of the robot by means of a clockt. Letspeedbe the maximum speed of the robot andtmovebe ^span

speed, i.e.,tmoveis the minimum time required to cover a distance of lengthspan. The valuetmoveis used in the guardst≥tmoveto set the duration of each transition labeled with actionu,d,landr, meaning that it takes to the robot at leasttmoveto move up, down, left, and right, respectively. Every time one of those transitions is performed, clocktis reset in order to begin the measure of the delay of the next action. Once a motion action is finished, the robot can either stop, or keep moving in the same direction. If the robot stops, a transition labeled with action

“stay” (i.e.,s!) is taken. Performing a “stay” action entails a change of the TA current location, which is then set tos, and a reset of the clockt. The time needed by the robot to stop is determined by the valuetstay. Hence, the transitions from locationsα∈ {u,d,l,r}to sare guarded witht ≥tstay. If the robot keeps moving towards the same direction, then the same actionαcan be iterated multiple times, provided that the conditiontmoveis satisfied and the synchronizationα! with the TA modeling the map can be realized.

Robot actions.Actions are encoded in the automaton through suitable TA locations. In Figure 4 locationsaandbare associated with “operationa” and “operationb” to represent the execution of actionsaandb. The locations are connected to statesby means of two transitions, one enabling the activation of the action, and the other representing its termination. The robot might start one action if some suitable conditions are satisfied. These constraints

Figure 3: Building 22 of Politecnico di Milano.

(6)

s r l

d

b a

u

The formulae corresponding the numeric labels of the edges:

(1)guard:t≥tstay sync:s! assign:t=0 (2)guard:t≥tmove sync:l! assign:t=0 (3)guard:t≥tmove sync:u! assign:t =0 (4)guard:t≥tmove sync:d! assign:t=0 (5)guard:t≥tmove sync:r! assign:t=0 1

2 3

1 4

1

5 1

sync:t≥0 guard:syncstart!

assign:t=0

sync:t≥tactionb guard:syncend!

sync:t≥0

assign:t=0 sync:t≥tactiona assign:t=0

3

1 5

4 2

Figure 4: An example of TA robot model able to move in four different directions and perform two different actions.

can be expressed in the guard of the transitions leading to their associated locations. Once a transition is fired, the robot remains in the target location for the entire durationt_actionOof the operation O, beingOeitheraorb, and then, it returns in locationswhen t ≥t_actionO.

Synchronization with other robots.Synchronizations among robots is modeled using appropriate actions, that are added in the setAct. In Figure 4, the robot synchronizes with another one on channel syncstartwhen it performs operationa. Once the operation is done, the robot notifies the termination on channelsyncend. Given an actionα, the coupling between two robots requires on one side sending a message on the channel (e.g.,α!) and on the other side receiving it (e.g.,α?).

Robotic Mission(3). We assume that the mission the robots have to perform is specified by users as a TCTL formula. In the future, we plan to generate the TCTL specification by supporting the usage of higher-level specification languages, such as robotic mission specification patterns [40] or robotic DLSs [24]. We cur- rently support two different types of missions that can be expressed in TCTL, i.e., reachability and (ordered) execution of actions.

Reachability.Reachability properties require that within a given time limit a location should be finally reached. Let time be a global clock that is never reset, and let(x,y)be a target location that must be reached within a time boundt_bound. Letl_(x,y)be a boolean variable that is set to one when the robot enters the location(x,y). The following TCTL formula states that the robot has reached(x,y) earlier thant_boundtime units from the beginning of the execution.

∃ F((l_(x,y)=True)∧(time<t_bound))

Execution of Actions.Letflagabe a boolean variable (initially set to false) indicating that actionahas been performed. The following TCTL formula specifies that actionais performed earlier thant_bound time units.

∃ F((flaga=True)∧(time<t_bound)) (1) Sometimes the mission may require a robot to perform a set of actions{a,b,c}within a specific time bound. Hence, the property can be expressed by the formula below.

∃ F(( ^

i∈ {a,b,c}

f laд_i =True)∧(time<t_bound)) (2) The specification of properties that require a robot to perform a set of actions in a specific order within a specific time-bound, can be done as follows. Consider the actionsa,b,cto be done in this order.

This mission can be expressed by using the TCTL formula

∃ F((G=True)∧(time<t_bound)) (3) where variableGis an additional variable added to the model of the robots that holds only ifa,b, andcfollow the correct order.

4.2 Procedures

The main procedures of ENFORCE are discussed in the following.

These procedures are inspired by the one proposed by Quottrup et al. [44] and Andersen et al. [8], which are well-known TA approaches for solving the planning problem in the robotic domain.

EnvironmentDescription2TA(4). The purpose of this procedure is to convert a high-level SE environment description into a lower-level FM-based modeling formalism. We propose two different instances, as alternative options, of the procedure to convert a high-level map of the environment into TA, namelyEncoding 1 andEncoding 2.

Encoding 1.LetW andHbe the width and the height (expressed in meters) of the (rectangular) map where the robots move, and let spanbe the sampling span, i.e., width and the high of the squared cells that are used to tile this map. Let also be(0,0)be the coordinate of the bottom-left corner of the figure. We define two setsX,Y containing respectively thexandyCartesian coordinates of the points(x,y), generated by the creation of a grid with square cells with width and highspan. Formally,

X = {x |0≤x ≤W−span,(x%span)=0} Y = {y|0≤y≤H−span,(y%span)=0} where % is the modulus mathematical operator.

For everya_r ∈Act, letBk(a_r)be the set of positions(x,y), with x∈X,y∈Y, where the robot cannot take actionar when it is in position(x,y), i.e., the actiona_r is blocked. For instance,Bk(u_r)are those positions(x,y)from which the robot cannot move to reach (x,y+span). For each robot, the environment is represented as a TA, defined as⟨Q,q_x0,y0,v⁰,I,T⟩, whose locations represent the current position that is occupied by the robot, i.e., a locationqx,y ∈ Q encodes position (x,y). Locationq_x0,y0 is the initial location of the robot. The TA constraints robot movements using actions {u_r,d_r,l_r,r_r,s_r}. Transitions inT are defined as follows, for any

(7)

(x,y)∈X×Y:

(q_(x,y),q_(x,y+span),∅,∅,(ur,?),∅,∅)∈T if (x,y)<Bk(ur); (q_(x,y),q_(x,y−span),∅,∅,(d_r,?),∅,∅)∈T if (x,y)<Bk(d_r); (q_(x,y),q_(x+span,y),∅,∅,(r_r,?),∅,∅)∈T if (x,y)<Bk(r_r); (q_(x,y),q_(x−span,y),∅,∅,(l_r,?),∅,∅)∈T if (x,y)<Bk(l_r); (q_(x,y),q_(x,y),∅,∅,(sr,?),∅,∅)∈T

For example, the portion of the environment bounded by a red dashed rectangle in Figure 5a is converted into the TA in Figure 5c.

Encoding 2.LetW,H,span,X,Ybe defined as for Encoding 1, and rbe a robot. The position of the robotris represented using two real variablesxrandyr, with 0≤xr ≤W−spanand 0≤yr ≤H−span. The set of locationsQof the TA contains only locationq, which is also the initial state of the TA. Five transitions specify how the robot can change its position in the environment, depending on whether the robot is moving up, down, left, right or is remaining in its current location. Every transition is labeled with (i) a guard that specifies if the robot can move in a given direction; (ii) an event that will be used to synchronize the model of the environment with the actions taken by the robotr; and (iii) an assignment that updates the coordinates of the robot. For every actionar ∈Act, we define a guardγ_arthat is enabled only if the current position of the robot does not block the execution of the actionar, i.e., the position of the robot is not inBk(ar).

γ_ar = ^

(x,y)∈Bk(ar)

¬(x=x_r∧y=y_r)

Then, the TA modeling the environment of the robotrcontains the following five transitions:

(q,q,γ_ur,∅,(u_r,?),∅,y_r =y_r+span); (q,q,γ_dr,∅,(d_r,?),∅,y_r =y_r−span); (q,q,γr r,∅,(rr,?),∅,xr =xr +span); (q,q,γ_lr,∅,(lr,?),∅,xr =xr−span); (q,q,∅,∅,(sr,?),∅,∅)∈T;

For example, consider the portion of the environment bounded by a red dashed rectangle in Figure 5a, the portion of the guard of the transitions that allows the robot to go down is presented in Figure 5b.

Network Creation(5). To create a comprehensive model of the robotic application, the model of the robots and their environment are combined into a (single) network of TA. To this end, every TA modeling a robotris added to the network. Furthermore, a copy of the TA describing the environment obtained in (4) is created for each robotrof the robotic application, and it is added to the network. This ensures that the robotrcan perform a movement actionαr ∈ {ur,dr,rr,lr} only if a transition labeled withαr! synchronizes with a transition labeled withα_r? of the copy of TA modeling its environment.

FM-based Plan Computation(6). Before executing the planning, the network of TA is modified depending on the type of the mission to be considered.

•Reachability.To handle reachability missions, the model of the environment of the robotrthat should reach position(x,y)is modified as follows. If the environment is generated usingEncoding 1,

an assignment that sets variablel_(x,y₎to True is added to all the transitions that enter the state representing location(x,y). If the transition is generated usingEncoding 2, an additional transition that sets the variablel_(x,y₎to True when the variablesxrandyr

are set to values(x,y)is added to the TA.

•Execution of Actions.To handle execution of actions, the TA of the robots are changed as follows. If the mission is specified as in formula 1, the assignmentflag_a=True is added to the transition that connect stateato states. If the mission is specified as in formulae 2 and 3,flag_a=True,flag_b =True,flag_c =True are respectively added to the transitions that connect statesa,bandc to states. Furthermore, for the mission specified in formula 3, (i) two additional guards requiring that thatflag_aandflag_bare set to True are respectively added to the transitions that connect states to statesbandc; and (ii) the assignmentG=True is added to the transition that connect statecto states.

After performing these changes, the network of the TA and the TCTL mission are fed into the Uppaal model checker. If the network of TA contains a trace that satisfies the mission under analysis, it is returned by Uppaal. Otherwise, an error reporting that no plan is available is shown to the user.

Plan Executor(7). The plan executor uses the traces produced by the planner to generate the commands to be sent to the robots. The trace is iteratively parsed, and the actions contained in the trace are converted into commands that are sent to the actual physical robots, or to the robotic simulator.

5 EVALUATION

This section assesses the effectiveness of ENFORCE which is implemented as a standalone Python application. The source code and a complete replication package are available from [19]. In particular, we have conducted several experiments¹in order to answer four main questions:

RQ1: Does ENFORCE effectively synthesize plans ensuring the satisfaction of the mission for single-robot applications? If yes, how long does the synthesis procedure take?

RQ2: Does ENFORCE effectively synthesize plans ensuring the satisfaction of the mission for multi-robot applications? If yes, how long does the synthesis procedure take?

RQ3: Are the plans computed by ENFORCE ensuring the mission satisfaction in simulated environments?

RQ4: Are the plans computed by ENFORCE ensuring the mission satisfaction in real environments?

RQ1 - Single Robot Effectiveness.We have evaluated different scenarios that vary over different missions, environment maps, sampling steps values, and the encoding of the environment.

Experiment Design.We analysed three different maps described in Table 5, representing real buildings and their sizes and number of rooms, as described in the table. The maps are available in our online repository [19]. We used three different maps in order to make sure that our experiments consider test cases that are representatives of realistic maps. For each map, we assumed four different sampling steps (ST) 50cm, 75cm, 100cm, and 125cm.

Furthermore, we tried both encoding 1 (C1) and encoding 2 (C2),

1All the experiments have been conducted on a machine with 8 GB 1600 MHz.

(8)

(a) A portion of the Building 22 of Politecnico di Milano.hgdiqwdgr- grhgdiqwdgrgrhgdiqwdgrgrhgdiqwdgrgrhgdiqwd

guard:...¬(x_r ≥0∧x_r ≤500∧y_r==22)∧

(¬(x_r ≥580∧x_r ≤800∧y_r==22)) sync:d?

assign:y_r=y_r+1

(b) Encoding 2 applied to the portion of the environment contained in the red dashed box of Figure 5a

id6|9 id6|10 id6|11 id6|12

id7|9 id7|10 id7|11 id7|12

sync:r?

sync:l? sync:l?

sync:r? sync:r?

sync:l?

sync:r?

sync: l?

sync:r?

sync:l?

sync:r?

sync:l?

sync:u?

guard:d?

sync:u?

sync:s? sync:s? sync:s? sync:s?

sync:s? sync:s? sync:s? sync:s? (c) Encoding 1 applied to the portion of the environment contained in the red dashed box of Figure 5a.

Figure 5: Two different encoding of the environment.

Table 4: Computation time (seconds) required by ENFORCE to generate plans for each scenario.

M1 M2 M3

T1 T2 T3 T1 T2 T3 T1 T2 T3

E ST C1 C2 C1 C2 C1 C2 C1 C2 C1 C2 C1 C2 C1 C2 C1 C2 C1 C2

E1 50 39.9 8.7 37.2 8.2 44.6 8.2 40.2 2.5 41.6 2.7 40.8 2.7 101.2 93.4 61.0 32.5 61.5 32.4 E1 75 4.8 2.3 7.4 2.3 6.1 2.0 4.3 0.9 4.5 1.0 5.4 0.8 38.7 22.7 13.7 8.0 12.8 7.7

E1 100 2.4 0.9 1.9 1.0 1.9 1.0 1.9 0.5 1.7 0.5 1.5 1.0 17 .9 8.7 5.6 3.6 5.2 3.3

E1 125 0.8 0.5 1.0 0.7 0.8 0.5 0.6 0.3 0.7 0.3 0.7 0.3 8.5 4.9 3.4 1.8 2.8 1.8 E2 50 5.2 1.8 5.5 1.7 5.2 1.8 3.1 0.5 2.8 0.5 2.9 0.5 24.0 9.7 6.6 2.6 6.8 2.6 E2 75 4.5 1.1 4.7 1.1 4.5 1.3 2.4 0.5 2.4 0.4 2.6 0.4 20.6 5.0 2.0 0.7 6.5 1.7 E2 100 1.4 0.6 1.3 0.5 1.4 0.5 0.6 0.2 0.7 0.2 0.6 0.2 7.0 2.8 3.5 6.1 2.1 0.7 E2 125 0.5 0.2 0.5 0.1 0.5 0.6 2.5 0.2 2.5 0.1 2.5 0.2 3.5 0.2 0.8 0.1 0.8 0.3 E3 50 9.8 10.0 8.5 10.4 9.2 9.6 8.0 3.1 6.9 3.3 7.2 3.0 6.5 124.8 15.6 29.6 14.9 28.8 E3 75 2.5 1.7 2.3 1.5 2.4 1.5 2.0 0.6 1.5 0.6 1.6 0.6 6.2 30.8 4.8 5.5 4.8 5.8 E3 100 1.0 1.0 0.8 1.3 0.9 1.2 0.8 0.5 0.5 0.6 0.5 0.7 6.4 14.8 1.9 4.3 2.0 3.7 E3 125 0.3 0.5 0.5 0.2 0.5 0.2 4.3 0.3 0.3 0.3 0.3 0.3 3.4 6.7 1.0 1.5 1.2 1.5

∗E1: Jupiter Building,E2: Building 22E3: Building 20;

M1: Mission1,M2: Mission2,M3: Mission3;

C1: Encoding1,C2: Encoding2;

T1: Time bound 1,T2: Time bound 2,T3: Time bound 3.

and three missions that the mobile robot has to achieve within a predefined time-bound: reaching a point (M1), reaching two points close to the initial position of the robot, and performing one action in each of these points (M2), and reaching two points far from the initial position of the robot, and performing one action in each of these points (M3). For every map, we considered three valuesT1, T2, andT3 as time-bound for the completion of the missions, i.e., T1,T2, andT3 are, respectively, equal to 150s, 500s, and 800sfor mapE1, 160s, 300s, and 600sfor mapsE2 andE3. ENFORCE has been applied on each map once for every sampling step (ST), every encoding, every mission and every time bound, which implies a total of 216 variations.

Table 5: ID, size, number of rooms (#R) and description of the environments considered in RQ1.

ID Size #R Description

E1 80m×90m 80 Jupiter Building, Chalmers University E2 120m×50m 57 Building22, Politecnico di Milano E3 70m×50m 50 Building20, Politecnico di Milano

Results.The results are reported in Table 4, which shows that ENFORCE succeeded in computing a plan that satisfied the considered missions for all the cases. The magnitude of the highest time

(9)

measured for the encoding 1 and 2 is few minutes (respectively, 101.2 and 124 seconds).

The answer toRQ1is that on the considered scenarios, ENFORCE effectively synthesized plans ensuring the satisfaction of the mission for single-robot applications.

RQ2 - Multi-Robots Effectiveness.To answer this question, we studied a scenario with two robots,E1 map and a sampling step measuring 125cm, that is the most coarse-grained among those considered inRQ1.

Experiment Design.The robots are supposed to start from different initial locations, meet at the same pre-chosen point to execute a collaborative action, and finally move to a destination point within 1600 seconds. We performed the analysis with three values for destination pointP1,P2, andP3 by increasing distance from the initial robots locations; meaning thatP3 is the farthest from the initial point andP1 is the closest one to it.

Results.The experiment showed that in case of two robots, EN- FORCE takes at least 45 minutes to compute a plan, or return a time out error. Therefore, the performance is not acceptable for practical usage of a planner in real cases scenarios.

The answer toRQ2is that for the three considered scenarios, ENFORCE was able to synthesize plans ensuring the satisfaction of the mission for multi-robots applications. However, computing the plans required at least 45 minutes.

RQ3 - Correctness in Simulated Environments.In order to better investigate the generated plans by ENFORCE, we realised them with Choreographe simulator², which allows for simulation of a Nao robot³. Our goal is to verify that the synthesized plans are correct, i.e, they allow satisfying the corresponding missions.

Experiment Design.We had used the environmentE1 since it is the biggest (in terms of m²) among the considered environment maps. Moreover, we had to consider missions that are feasible to be simulated with Choregroaphe. The simulated scenario was based on executing the following three missions by the robot inE1.

– the robot has to start from an initial location, reach a given position, get a set of items from a table, and return to its initial location;

– the robot has to start from its initial location, reach a given position, say a sentence or a warning, return to its initial location; and

– the robot has to start from its initial position, reach a given position, unload an object, and return to its initial position.

The movements, the say and the unload actions are simulated, respectively, by means of theMoveAlong,Say, andCartesian motion actionsof the Choreographe simulator.

Results.The simulator confirmed that the actions executed by the robots successfully satisfied the mission requirements.

2http://doc.aldebaran.com/1- 14/software/choregraphe 3http://www.ald.softbankrobotics.com/robots/nao

The answer toRQ3is that on the three considered scenarios, the Choreographe simulator confirms the correctness of the plans computed by ENFORCE.

RQ4 - Correctness in Real Environments.As it was of ut- most importance for our tool to be practical, we experimented the correctness of ENFORCE plans in real environments.

Experiment Design.We conducted the real experiments inE1, and the offices of our industrial partner PAL-robotics⁴, with Turtlebot⁵ and a TIAGO robot⁶and a sampling step of 50cm long. For this experiment, we had considered the following three missions, that were defined based on (i) the requirements of our industrial partner, and (ii) the type of the robots and facilities we had access to.

– the TurtleBot patrols the building during the night. It starts from the initial position P1, and reaches the location P2, where it checks the presence of an intruder. If an intruder is detected the robot calls the surveillance. Then, it goes back to P1.

– the TurtleBot delivers a box from one office to another. The robot starts from office P1, where a user loads it, and moves to the delivery point P2 within 2 minutes, where it unloads the box, and finally returns to P1.

– TIAGO starts from location P1, reaches first location P2 and then P3, and goes back to location P1 within 3 minutes. In every locations, an audio message is delivered (to users).

We used ENFORCE to compute the motion plans within the environments, that were enriched with the recording actions. To test the plans in the environment, we send ROS⁷navigation goals to the robots, to enforce the movement actions, and the Linux command Say to play audio messages.

Results.In all the considered scenarios, the robots effectively satisfy their missions. Videos of our experiments are available in our online repository [19].

The answer toRQ4is that on the three considered scenarios, our experiments confirm the correctness of the plans computed by ENFORCE.

6 DISCUSSION

The results of the evaluation lead us to the following findings. We present our discussion by relating it with the inputs of ENFORCE.

– Environment Description and Planning Precision(1). From a software engineering standpoint, the reusability of planners in industrial applications depends on their performance and scalability.

The experimental evaluation in Sec. 5, points out that mapping areas with a low sampling value ensures accurate movements, but increases the computation time, as it enlarges the size of the TA modeling the entire system. Information related to the sampling values, and the size of the maps that can be effectively processed by planners, are usually not extensively discussed in research papers. Conversely, in this work, we considered three

4http://pal- robotics.com/

5http://www.turtlebot.com/

6https://tiago.pal- robotics.com/

7http://wiki.ros.org/ROS

(10)

different maps of real environments, robotic missions, and single and multi-robot applications, to extensively discuss how the sampling step, and the size of the map, affect the performance of the ENFORCE (inspired by [8]). The sampling step and the size of the map do not pose a threat to single-robot applications, whereas dramatically affect the use of planners for multi-robots applications. However, choosing the right value for the sampling step is essential, as an unreasonably large value assigned to the sampling step does not allow ENFORCE to synthesize plans.

Possible Improvement. One solution to the previous problem would be to consider a dynamic sampling of the environment.

Instead of decoding the whole environment once, dynamic sampling can consider only a local neighborhood of the current location at each time step, improving performance.

– Robotic System Characteristics(2). When software engineers want to design a robotic application, they have to find a planner that is suitable for the set of robots they are using, each one having specific characteristics. For this reason, the features and the assumptions of a planner should be clearly stated, to allow the designers to select the best option, that can satisfy the modeling requirements needed to represent the behavior of the robots.

However, these data, as well as the performance of planners, are often not clearly stated and thoroughly evaluated, and it is often difficult to understand whether a planner meets certain expectations. For example, the size of the team of robots that can be managed by a planner (with certain performances) is often not precisely specified. In this work, we have considered one among many planners that have been proposed in the robotics literature (for the reasons specified in Section 4). While ENFORCE uses a well-known efficient and optimized model checker, the state explosion problem still represents the major obstacle to the adoption of FM-based solutions, in particular those based on TA-planners, in the robotic domain.

Possible Improvements. We believe that to enable and facilitate (re)- use of existing planners, additional effort is required to provide upfront documentation on the working assumptions, and more rigorous and thorough evaluations of planners. The research community has to develop guidelines to help developers and researchers in this direction. While the FM-community has been studying for several decades solutions to limit the state explosion problem, it is unknown whether this problem will be solved in the future. Therefore, to earn the benefits of FM-techniques in practical contexts, they must be wisely used. We believe that there is a need for understanding how to effectively (re)-use existing FM-based planners within robotic projects. For example, it is necessary to understand at which level of abstraction planning should be performed. Performing planning on a higher level of abstraction provides computational benefits, but opens new problems, i.e., how high-level models and plans can be bound to the physical world and the low-level problems that can occur as the mission is performed.

– Characteristics of Missions(3). Planners compute sequences of actions that ensure the satisfaction of a mission that the robotic team has to achieve. While robotic users often have a clear high- level idea of the goal the robotic application, they are usually not familiar with logic-based languages, that are the most recurrent

means adopted for mission specification. Since understanding whether a logical language is suitable for expressing the mission under analysis might be difficult, the choice of a planner is, generally, not trivial. Furthermore, even when a language that is enough expressive to capture the missions is found, writing mission might still be hard.

Possible Improvements. We believe that it is important to formally state and discuss the type of missions that can be processed by the different planners, and to provide high-level languages that guide non-expert users during the mission specification. In our previous work, we performed an initial step in this direction. We proposed robotic mission specification patterns [40], that map recurrent mission specification problems to logic-based solutions, and integrated them into a robotic Domain Specific Language (DSL) [24].

7 CONCLUSION

In this paper, we proposed ENFORCE (formally vErified plaNning soFtware fOr Real-world sCEnarios), a robot planning framework that uses Timed Automata to represent the robot behavior and the environment in which the robots are deployed, and that adopts TCTL for the specification of the missions, including real-time constraints. The framework enables the automatic computation of plans, that ensure the satisfaction of a mission of interest. EN- FORCE relies on Uppaal, a state-of-the-art model-checker for the computation of plans. To evaluate ENFORCE, we considered both simulated environments and real robots.

We believe that this work warns the research community to promote a systematic and extensive evaluation of FM-based planners in robotic applications, and to push for a closer integration of formal methods into software engineering. Our contribution increases the quality of software applications in robotics, as it fosters a deeper evaluation of FM-based planners and in particular those built upon TA, a deeper evaluation of their underlying assumptions, and use context. The analysis paves the way for more conscious and systematic reuse of existing planners across (different) SE platforms of robotic applications. Our discussion, in fact, clearly highlights the limitation of the FM-based planner used in this work with the purpose of strengthening the — still too weak — links between FM and SE.

ACKNOWLEDGMENTS

This work has received funding from the European Research Coun- cil under the European Union’s Horizon 2020 research and innova- tion programme (grant No 694277 and No 731869). We also acknowl- edge financial support from Centre of EXcellence on Connected, Geo-Localized and Cybersecure Vehicle (EX-Emerge), funded by Italian Government under CIPE resolution n. 70/2017 (Aug. 7, 2017).

REFERENCES

[1] ISO 10218-1. 2011.Robots and robotic devices – Safety requirements for industrial robots – Part 1: Robots. Organization for Standardization, Geneva, Switzerland.

43 pages.

[2] ISO 10218-2. 2011.Robots and robotic devices – Safety requirements for industrial robots – Part 2: Robot systems and integration. Organization for Standardization, Geneva, Switzerland. 72 pages.

[3] ISO/TS 15066. 2016.Robots and robotic devices – Collaborative robots. Organization for Standardization, Geneva, Switzerland.