Università degli Studi di Torino INTELLIGENT ...

Università degli Studi di Torino Dipartimento di Informatica Corsi di Laurea in Informatica

Tesi di Laurea in Informatica

INTELLIGENT SUPPORT SYSTEM FOR MISSION PLANNING Curriculum Sistemi per il Trattamento dell’Informazione

Relatore: Prof. Pietro Torasso

Candidato: Marco Roberti

Sessione di Dicembre 2015 a.a. 2014/2015

2

Contents 1 Introduction 11 1.1 Outline of the thesis . . . . . . . . . . . . . . . . . . . . . . . 12 2 Domain specification

15

3 An overview of plan solving techniques 3.1 The PDDL planning language . . . . . 3.1.1 PDDL 2.1 . . . . . . . . . . . . 3.2 Automated planners . . . . . . . . . . 3.2.1 MetricFF . . . . . . . . . . . . 3.2.2 COLIN . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4 Characterising the problem of mission planning 4.1 Entities of the domain . . . . . . . . . . . . . . . 4.1.1 Human agents involved . . . . . . . . . . . 4.1.2 UAV models . . . . . . . . . . . . . . . . . 4.1.3 Sensors and sensor suites . . . . . . . . . . 4.1.4 Airports . . . . . . . . . . . . . . . . . . . 4.1.5 Targets . . . . . . . . . . . . . . . . . . . 4.1.6 Observation requests . . . . . . . . . . . . 4.1.7 Mission . . . . . . . . . . . . . . . . . . . 4.2 Application functionalities . . . . . . . . . . . . . 4.2.1 Targets and observation requests definition 4.2.2 Mission planning . . . . . . . . . . . . . . 4.2.3 Mission displaying . . . . . . . . . . . . . 5 Application architecture 5.1 System overview . . . . . . . . . . . 5.2 Used technologies . . . . . . . . . . . 5.2.1 Java SE 8 . . . . . . . . . . . 5.2.2 Google Maps JavaScript API 3

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . . . .

. . . .

. . . . .

. . . . . . . . . . . .

. . . .

. . . . .

17 18 20 23 24 26

. . . . . . . . . . . .

29 29 29 30 30 31 31 32 32 34 34 34 35

. . . .

37 37 37 37 41

4

CONTENTS 5.2.3 5.2.4 5.2.5

GMapsFX . . . . . . . . . . . . . . . . . . . . . . . . . 41 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . 42 Automated planners . . . . . . . . . . . . . . . . . . . 43

6 Model, View, Controller of the system 6.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Target class . . . . . . . . . . . . . . . . . . . . . 6.1.2 Sensor and SensorSuite classes . . . . . . . . . . . 6.1.3 ObservationRequest and ClusteredRequest classes 6.1.4 UAV and UAVAvailability classes . . . . . . . . . 6.1.5 Mission and Plan classes . . . . . . . . . . . . . . 6.1.6 The model.plan.actions package . . . . . . . . . . 6.1.7 PDDLObject interface . . . . . . . . . . . . . . . 6.1.8 Database class . . . . . . . . . . . . . . . . . . . . 6.2 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 PDDLMissionEncoder class . . . . . . . . . . . . 6.2.2 Planner class . . . . . . . . . . . . . . . . . . . . 6.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Target insertion . . . . . . . . . . . . . . . . . . . 6.3.2 Mission definition . . . . . . . . . . . . . . . . . . 6.3.3 Mission plan visualisation . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

45 46 46 46 46 47 48 48 49 49 50 51 54 55 55 56 59

7 Testing scenarios 7.1 Available information 7.2 The testing phase . . 7.2.1 Test case 1 . . 7.2.2 Test case 2 . . 7.2.3 Test case 3 . . 7.2.4 Test case 4 . . 7.3 Performance analysis

. . . . . . .

. . . . . . .

. . . . . . .

65 65 66 66 69 71 71 75

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

8 Conclusions

77

A Entity-Relationship diagram

81

List of Figures 3.1

CPU-Time performances of MetricFF and Colin dealing with unconstrained problems ([2]) . . . . . . . . . . . . . . . . . . . 24

5.1

A sketch of the system architecture . . . . . . . . . . . . . . . 38

6.1 6.2 6.3 6.4 6.5 6.6

The target insertion interface. . . . . . . . . . . . . . . . . . The steps of a sample linear target path definition. . . . . . The observation request definition interface. . . . . . . . . . The dialog that asks to the user to confirm data fusion. . . . On date pick, UAV availabilities are shown. . . . . . . . . . When setting the area of interest, observation requests appear in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 The system checks the selected observation requests to be a consistent set. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.8 The interface through which mission definition is detailed. . 6.9 The mission plan visualisation interface. . . . . . . . . . . . 6.10 The tree view that details the returned plan. . . . . . . . . . 6.11 The representation of a cluster observation. . . . . . . . . . . 6.12 The test case 3 KML mission plan file, as shown by Google Earth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 7.2 7.3 7.4 7.5

. . . . .

. 60 . . . . .

60 61 63 63 64

. 64

The targets observed in test cases. . . . . . . . . . . . . . . . . Test case 1 solving plan path, as displayed by the application. Test case 2 solving plan path, as displayed by the application. The application alerts about the inability to solve Test case 3. Test case 4 solving plan path, as displayed by the application.

5

56 57 57 58 59

67 67 69 71 74

6

LIST OF FIGURES

List of Tables 4.1

The typical technical information of UAV classes . . . . . . . . 30

6.1

The colours associated with sensors on the graphic representation of a mission plan. . . . . . . . . . . . . . . . . . . . . . 62

7.1 7.2 7.3 7.4 7.5 7.6 7.7

The observations requests dated December 15th, 2015 . . . . Test case 1 returned plan . . . . . . . . . . . . . . . . . . . . Test case 2 returned plan . . . . . . . . . . . . . . . . . . . . The observations requests’ assignments in test case 4 . . . . Test case 4 returned plan (MAME N4) . . . . . . . . . . . . Test case 4 returned plan (MALE N6) . . . . . . . . . . . . The planning results of each test case: values in bold correspond to the application displayed result. . . . . . . . . . . .

7

. . . . . .

66 68 70 72 72 73

. 76

8

LIST OF TABLES

Listings 3.1 3.2 3.3 3.4 3.5 5.1 5.2 6.1 6.2

The “visitall” domain, introduced in IPC 2011 . . . . . . . . A basic problem defined on the “visitall” domain, introduced in IPC 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . A PDDL 2.1 domain and problem specification: a plan metric is specified at line 59. . . . . . . . . . . . . . . . . . . . . . . A sample MetricFF output. . . . . . . . . . . . . . . . . . . A sample COLIN output. . . . . . . . . . . . . . . . . . . . Comparison between enhanced for loop and Java 8 streams . A simple marker insertion in a Google Map using pure JavaFX and GMapsFX . . . . . . . . . . . . . . . . . . . . . . . . . The query that selects all the observation requests that are relative to a certain area and a specific date. . . . . . . . . . The Quality Threshold algorithm’s pseudo-code . . . . . . .

9

. 19 . 20 . . . .

21 25 27 40

. 41 . 49 . 53

10

LISTINGS

Chapter 1 Introduction Planning is an important task that concerns human daily activities: planning capabilities are considered an essential property to consider an agent as “intelligent”. The main purpose of a planning process is the definition of a plan, meaning a sequence of actions that allows the achievement of a goal. This is not a trivial task, as it usually involves logical inferences as well as numerical ones, such as time constraints and available resources: a lot of components have to be considered, often making manual planning execution so much complex that the use of automated planners becomes almost mandatory. An automated planner is an intelligent system that, starting from a representation of the initial state, a goal specification and a formal description of the executable actions, is able to generate a problem satisfying plan. Inside a planner, states are usually represented as a conjunction of logical propositions, and the goal corresponds to one or more states that satisfy a set of conditions. An action is specified through its preconditions, meaning the required properties of a state in order to execute the action on it, and its effects, that are the changes in the status of the world produced by its execution. Such changes are often divided in two groups: in one hand, all facts that are removed from the state, becoming false, and in the other hand all facts that have to be added to the state as the action makes them true. The planning, as described above, is now referred to as Classical (or Propositional) Planning ([5]). The simplest approach to the resolution of a classical planning problem is state space search: state space represents the set of all the states that are reachable, starting from the initial one, executing all possible sequences of actions. The earliest planning algorithms were purely logic, meaning that they tried to understand what to do and in which order, without considering numeric factors that can change during the execution, such as time and resources consumption; more recently, the development 11

12

CHAPTER 1. INTRODUCTION

of computer performances let automated planning research consider more realistic problems that involve numeric requirements as actions preconditions and numeric changes as their effect. The development of planning with resources constraints has been facilitated by the release of version 2.1 of PDDL, the standard language for domain model representation, that provides a considerable modelling capacity ([4]). It can model domains that involves resources time usage through numeric fluents, allowing the modeller to distinguish, within the problem, the predicative part and the numeric one. The aim of this thesis is the development of a system that intelligently supports the human agent in creating domain-specific problems, executes the planning phase and shows its result in a user-friendly way: the final outcome is an application that does not require the user to know anything about PDDL language nor automated planning algorithms. The considered domain involves a set of Unmanned Aerial Vehicles, equipped with observation sensors, and their aim to efficiently perform target observations, respecting numeric constraints such as time bounds, fuel availability, sensors specified in target observation requests ([1]). The system will support the user in creating targets, specifying observation requests, defining missions and understanding the returned mission plans. The application exploits two state-of-art automated planners, COLIN, developed in King’s College of London ([3]), and MetricFF, developed in Saarland University ([7]). Both perform a forward-chaining state search, guided by domain-independent heuristics: MetricFF is used to find optimal plans, while COLIN aims to reach admissible ones. A set of test scenarios has been devised, in order to show the application features and highlight further the benefits of offering automated planning capabilities to users that are inexperienced about artificial intelligence: the plans returned by the considered planners will be described and analysed, comparing each other qualitatively as well as quantitatively.

1.1

Outline of the thesis

The thesis is organized as follows: Chapter 2 describes the SMAT-F2 project in general terms, and illustrates its domain in order to allow the reader to understand the problems the system described in the thesis deals with. Chapter 3 gives an overview on planning research over the years and reports the state of the art in the context of standardized Artificial Intel-

1.1. OUTLINE OF THE THESIS

13

ligence languages regarding automated planning, describing the main characteristics of PDDL and its extensions, in particular regarding numeric fluents and durative actions. Chapter 4 examines in depth the domain introduced in chapter 2. Chapter 5 illustrates the system developed in this thesis, including a general overview and the technologies used by the software. Chapter 6 describes the development phase, following the application’s MVC architecture and analysing its single components. Chapter 7 shows four test cases in order to highlight automated planner’s performances and the developed application’s flexibility in exploiting more than one planner. Chapter 8 draws the conclusions of the thesis.

14

CHAPTER 1. INTRODUCTION

Chapter 2 Domain specification The system described in this thesis takes inspiration from the SMAT project, developed by Comitato Distretto Aerospaziale Piemonte and funded by Regione Piemonte and European Regional Development Fund ([1]). The aim of SMAT is to create an integrated territory monitoring system through unmanned aerial vehicles (UAV), remotely handled from data processing stations, placed on ground. This will permit the development of a support system that will be useful in preventing and controlling a wide set of tasks, such as floods, fires, landslides, traffic control, city planning, pollution analysis. The latest phase of the project, coordinated by Alenia Aermacchi and developed by research institutes, big businesses and small-medium sized enterprises, is called SMAT-F2. It started on January 2013 and lasted 30 months: one of its goals was to build interfaces that maximize the ease of use of the system through an interface that hides the complexity to the enduser, showing him nothing more than what he needs: this thesis describes the development of a mission-defining interface, that also displays the resulting plan in an easy to understand way. The typical use scenario is made up by the following components: • A set of one or more UAVs, each of them placed on an airport and equipped of a sensor suite; • A set of one or more targets that are requested by the client to be observed through a certain sensor, specifying the observation’s time interval and its minimum duration. The project makes use of three different classes of UAV, each of them designed for a specific type of task and supporting different sensor suites: 15

16

CHAPTER 2. DOMAIN SPECIFICATION • Medium-altitude long-endurance unmanned aerial vehicle (MALE), designed to cover region-sized areas: the typical MALE has a wing span of 10 meters, weighs 800 kilograms and has an operating time of 9 hours; • Medium-altitude medium-endurance unmanned aerial vehicle (MAME), designed to cover province-sized areas: typical MAME has a wing span of 7.2 meters, weighs 490 kilograms and has an operating time of 8 hours; • Light, reduced-speed, low-flying unmanned aerial vehicle (Light), designed to observe local areas: the typical Light has a nine-meter span wing (partially inflated with helium, thus providing a high lift capacity even at very slow speeds), weighs 150 kilograms and has an operating time of 3 hours.

Targets can be a single point on the map or a polyline that describes a geographic path. The available sensors are a subset of five pre-defined devices: video camera, infra-red camera, electro-optic camera, hyper-spectral camera and radar. Technical specification of the used entities is available on chapter 4. From the final user’s point of view, the application will intelligently generate, if possible, a mission plan that suggests the most suitable way to observe a subset of targets, minimizing the available resources (total fly time, fuel consumption and, consequently, economic cost).

Chapter 3 An overview of plan solving techniques The developed system aims to generate a mission plan: planning is a deliberation process that chooses and organizes a list of actions that achieves a goal, starting from description of the initial state. This task involves a specific area of Artificial Intelligence, automated planning, that studies this process computationally ([5]). Given an exhaustive description of the initial state of the represented domain, a description of the desired goals, and a well-formed description of every possible action (including its preconditions and effects), the automated planner tries to find a sorted list of actions that leads to a goal state: such list corresponds to a plan. Classical Planning Problems have only one initial state and deterministic actions, meaning that the application of an action to a state results to a single state. Classical Planning is represented in a factorized way, meaning that each state of the world is a set of variables, and each action specifies a set of propositions that must belong to the state in order for the action to be applicable and which propositions the action will add or remove, leading to a new state of the world. Consequently, planning problems have historically been faced making use of state space search algorithms, based on forward and backward chaining, often based on heuristic functions. Automated planning arose, beyond state space search, from automated theorem proving, control theory and from practical needs of various domains, such as robotics and scheduling ([9]). These influences are clear in STRIPS, the first important planning system, developed in 1971 by Richard Fikes and Nils Nilsson, whose action representation has been very influential during the years. Action Description Language (ADL), proposed in 1987 by Edwin Pednault, relaxed some STRIPS’ restrictions, allowing to describe 17

18 CHAPTER 3. AN OVERVIEW OF PLAN SOLVING TECHNIQUES more realistic problems. The PDDL language, described in next section, introduced by Drew McDermott and his colleagues in 1998 as a standard, domain-independent language, is directly inspired by STRIPS and ADL.

3.1

The PDDL planning language

Planning Domain Definition Language (PDDL) is an attempt to standardize artificial intelligence planning languages, mainly developed to be used in the first International Planning Competition (IPC, 1998) ([9]). It is designed to be domain-independent and neutral, meaning that it would not favour any particular planning system, and one of its main features is the strong distinction between the domain and the problem defined on it. Thus, a planning problem is created paring the descriptions of parametrized actions that characterize domain behaviour and the description of specific objects, initial conditions and goals that characterize a problem instance. Every state is represented as a conjunction of fluents, that are ground atoms without functions inside them. As the database semantic is used, any unmentioned fluent is assumed as false (closed-world assumption), and any different name always refers to different entities in the world (unique name assumption). States have the possibility to be considered as fluent conjunctions, making logic inferences applicable, or as fluent sets, allowing mathematical operations like intersection and union. Actions are described through action schemas, that are made of: Parameters The list of all variables used by the action; Precondition A conjunction of literals that defines the states in which the action can be executed; Effect A conjunction of literals that defines the effect of the action: all literals that are not mentioned in this part of the action schema are assumed as unchanged. When an action schema contains variables, meaning that the parameters list is not empty, there is usually more than one instance applicable: therefore, an action schema represents a set of actions without variables, called ground actions. If it has v variables and the domain contains k unique variable names, finding the schema’s ground actions set is a task that has, in the worst case, O(v k ) time performance: some automated planners’ approach includes PDDL schema propositionalization, that is replacing every action

3.1. THE PDDL PLANNING LANGUAGE

19

schema with a set of ground actions, converting the planning problem instance into an instance of the boolean satisfiability problem. However, this approach is not applicable if v and k are big values. The effect of the execution of an action a on a state is often split in the action’s add list add(a), that contains the propositions that become true, and its delete list del(a), including the propositions that become false. PDDL language expresses negating prepositions through the (not ?p) operator. Thus, the effect of the execution of the action a on the state s can be formally defined as the function effect(a, s) = (s − del(a) ∪ add(a))

(3.1)

A goal is similar to an action schema’s precondition: a conjunction of literals that can contain variables, that are by assumption existentially quantified. Listings 3.1 and 3.2 are a basic example of PDDL domain and problem files. The domain models a robot placed into a chessboard-like space, in which pairs of positions are declared to be connected each other through the (connected ?x ?y) predicate. The robot position is expressed with the fluent (at-robot ?x) and information about which cells it has already visited are available through (visited ?x). The only action schema defined is move, that has two parameters, two preconditions and three effects: add(a) contains (at-robot ?nextpos) and (visited ?nextpos), while del(a) is a single-element containing (not (at-robot ?curpos)). The problem places the robot on the north-western cell of a 2x2 space, with the aim to visit the south-eastern cell. Listing 3.1: The “visitall” domain, introduced in IPC 2011 1 2 3 4 5 6

( define ( domain visitall ) (: predicates ( connected ? x ? y ) ( at - robot ? x ) ( visited ? x ) )

7 8 9 10 11 12 13 14

(: action move : parameters (? curpos ? nextpos ) : precondition ( and ( at - robot ? curpos ) ( connected ? curpos ? nextpos ) ) : effect ( and

20 CHAPTER 3. AN OVERVIEW OF PLAN SOLVING TECHNIQUES ( at - robot ? nextpos ) ( not ( at - robot ? curpos )) ( visited ? nextpos )

15 16 17

)

18

)

19 20

)

Listing 3.2: A basic problem defined on the “visitall” domain, introduced in IPC 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

( define ( problem visitall ) (: domain grid ) (: objects nw ne sw se ) (: init ( at - robot nw ) ( visited nw ) ( connected nw ne ) ( connected nw sw ) ( connected ne nw ) ( connected ne se ) ( connected sw nw ) ( connected sw se ) ( connected se ne ) ( connected se sw ) ) (: goal ( visited se ) ) )

3.1.1

PDDL 2.1

PDDL, as originally defined, can’t handle any sort of numeric information: the need to express both temporal and numeric properties of planning domains (distances, consumptions, durations. . . ) brought to the definition of PDDL 2.1 ([4]), that introduced numeric expressions, plan metrics and durative actions. This last feature won’t be described in details, as the PDDL domain used in this thesis does not exploit it. Numeric expressions Numeric expressions are constructed from primitive values returned by functions associated with the domain. All arithmetic operators, including com-

3.1. THE PDDL PLANNING LANGUAGE

21

parison predicates, use a prefix syntax in order to simplify parsing. Conditions on numeric expressions are always comparisons between pairs of numeric expressions, while effects are expressed through a direct assignment operation, assign, and relative ones, increase and decrease. Numbers are not distinguished in their possible roles, so values are treated by planners in the same way, whether they represent quantities of resources, accumulating utilities, indices, counters or any other kind of values. It is worth noting that numeric expressions can not be used as action parameters, as well as functions can not return anything but numeric values, making the declaration of return types superfluous. Obviously, functions can be used by action’s preconditions and effects to get numeric values associated to the parameters. Plan metrics An immediate consequence of the adoption of numeric expressions is the need of a new, optional field within the problem specification: a plan metric. Plan metrics specify, for the benefit of the planner, the basis on which a plan will be evaluated as a “good” one: of course, a planner is not forced to use the metric to guide its execution, but it is always able to evaluate the solution it achieves. This means that output plans might be optimal, sub-optimal, or possibly even poor quality ones. Metrics are contained in the problem file, allowing the modeller to explore the effect of different metrics on output plans of the same problem: listing 3.3 is example of use of a plan metric. Such example introduces some predicates as well as four functions, whose initial values are specified within the problem. It is worth noting that there are some numeric fluents that behave dynamically, such as (fuel-used ?v vehicle), decreased by the (drive ?v ?from ?to) action, and (total-fuel -used), minimized by the metric. Conversely, other ones, like (fuel-required ?p1 ?p2 - location), maintain the same value during the execution, as they are not changed by any action schema effect. Action preconditions, as well as their effects, can involve both propositional and numeric fluents, making PDDL 2.1 much more expressive that its previous version. Listing 3.3: A PDDL 2.1 domain and problem specification: a plan metric is specified at line 59. 1 2 3 4

( define ( domain metricVehicle ) (: types vehicle location ) (: predicates ( at ? v - vehicle ? p - location )

22 CHAPTER 3. AN OVERVIEW OF PLAN SOLVING TECHNIQUES ( accessible ? v - vehicle ? p1 ? p2 - location )

5

) (: functions ( fuel - level ? v - vehicle ) ( fuel - used ? v - vehicle ) ( fuel - required ? p1 ? p2 - location ) ( total - fuel - used ) )

6 7 8 9 10 11 12

(: action drive : parameters (? v - vehicle ? from ? to - location ) : precondition ( and ( at ? v ? from ) ( accessible ? v ? from ? to ) ( >= ( fuel - level ? v ) ( fuel - required ? from ? to ) ) ) : effect ( and ( not ( at ? v ? from )) ( at ? v ? to ) ( decrease ( fuel - level ? v ) ( fuel - required ? from ? to ) ) ( increase ( total - fuel - used ) ( fuel - required ? from ? to ) ) ( increase ( fuel - used ? v ) ( fuel - required ? from ? to ) ) ) )

13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

)

41 42 43 44 45 46 47

( define ( problem metricVehicle - example ) (: domain metricVehicle ) (: objects truck car - vehicle Paris Berlin Rome - location )

3.2. AUTOMATED PLANNERS (: init ( at truck Rome ) ( at car Paris ) (= ( fuel - level truck ) 100) (= ( fuel - level car ) 100) ( accessible car Paris Berlin ) ( accessible car Berlin Rome ) ( accessible truck Rome Paris ) ( accessible truck Rome Berlin ) ( accessible truck Berlin Paris ) (= ( fuel - required Paris Berlin ) 40) (= ( fuel - required Berlin Rome ) 30) (= ( fuel - required Rome Paris ) 35) (= ( fuel - required Rome Berlin ) 40) (= ( fuel - required Berlin Paris ) 40) (= ( total - fuel - used ) 0) (= ( fuel - used car ) 0) (= ( fuel - used truck ) 0) ) (: goal ( and ( at truck Paris ) ( at car Rome ) ) ) (: metric minimize ( total - fuel - used ))

48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

23

)

3.2

Automated planners

At present, the most diffused and efficient approaches to automated planning are the following ([9]): • Reduction to the propositional satisfiability problem; • Forward chaining state space search, using domain-free heuristics; • Research using planning graphs. The application developed in this thesis exploits, in particular, two automated planners, MetricFF and COLIN, both based on the forward chaining state space search and supporting PDDL 2.1. In the next sections they will be introduced, in order to fully understand their role in the application.

24 CHAPTER 3. AN OVERVIEW OF PLAN SOLVING TECHNIQUES

Figure 3.1: CPU-Time performances of MetricFF and Colin dealing with unconstrained problems ([2])

3.2.1

MetricFF

In order to describe MetricFF, it is necessary to introduce the planner it derives from, FF. FF (short for Fast-Forward) has been developed by Jörg Hoffmann in late ‘90s and won the second International Planning Competition in 2000, outperforming all the other fully automatic systems and being nominated Group A Distinguished Performance Planning System. FF relies on forward state space search, using a heuristic that ignores delete lists to estimate goal distances, without assuming facts to be independent. It exploits a search algorithm, Enhanced Hill-Climbing (EHC), that combines local and systematic search, followed by two different pruning techniques, obtained as a side effect of the base heuristic method. If local search fails, then FF skips everything done so far and switches to a complete best-first algorithm. FF has been developed before the introduction of PDDL 2.1, supporting only STRIPS and ADL problems: Hoffman extended the planner in 2002: the resulting application, MetricFF, includes numeric expressions and plan metrics support ([7]). The main underlying idea is an heuristic that ignores the actions’ delete list as well as all the numeric effects that decrease the value of a variable: the relaxed task becomes, consequently, monotonic in a certain sense, preserving FF’s original theoretical properties. The search algorithm and the pruning

3.2. AUTOMATED PLANNERS

25

techniques are roughly the same as in FF: in case of local search fail, the used best-first algorithm is weighted A*, a complete algorithm that simply expands search nodes according to the value of the function f (s) = wg ∗g(s)+ ws ∗ h(s), where g(n) is the node reaching cost, h(n) its heuristic function’s value and wg = 1 and wh their weight. Actually, MetricFF can be called with 5 different search configurations: 1. Standard-FF: EHC+H then BFS (cost minimization: NO) 2. BFS 3. BFS+H 4. Weighted A*, with cost minimization 5. A*epsilon, with cost minimization 6. EHC+H, then A*epsilon, with cost minimization Even if the last one is MetricFF’s default configuration, the application described in this thesis induces to be interested in pure weighted A* approach, in which the value of wh , that is equal to 5 by default, can be user-defined. It is worth noting that the heuristic function is not admissible, meaning that it can overestimate the cost of goal reaching: thus, calling weighted A* with wh = 1 doesn’t assure the optimality of the output plan. Setting wh = 0 will result in Dijkstra’s algorithm, that finds the optimal solution at the risk of a very heavy computation. A sample MetricFF output, generated from the PDDL problem 3.3, is shown on listing 3.4. It is worth noting that the only numeric information about the domain is the plan cost, lacking of halfway and final states’ information, such as predicates that are true of function values. Listing 3.4: A sample MetricFF output. 1 2 3 4 5 6

ff : parsing domain file domain ’ metricVehicle ’ defined ... done . ff : parsing problem file problem ’ metricVehicle - example ’ defined ... done .

7 8 9 10 11

warning : numeric precondition . turning cost - minimizing relaxed plans OFF .

26 CHAPTER 3. AN OVERVIEW OF PLAN SOLVING TECHNIQUES 12 13 14 15 16

ff : search configuration is Enforced Hill - Climbing , then A * epsilon with weight 5. Metric is ((1.00*[ RF2 ]( total - fuel - used )) - () + 0.00) COST MINIMIZATION DONE ( WITHOUT cost - minimizing relaxed plans ).

17 18

Cueing down from goal distance :

19 20 21

3 into depth [1] 2 [1] 1 [1] 0

22 23 24 25 26 27

ff : found legal plan as follows step 0: drive car Paris Berlin 1: drive truck Rome Paris 2: drive car Berlin Rome plan cost : 105.000000

28 29

time spent :

30 31 32 33 34 35 36 37 38 39

3.2.2

0.00 seconds instantiating 5 easy , 0 hard action templates 0.00 seconds reachability analysis , yielding 6 facts and 5 actions 0.00 seconds creating final representation with 6 relevant facts , 5 relevant fluents 0.00 seconds computing LNF 0.00 seconds building connectivity graph 0.00 seconds searching , evaluating 4 states , to a max depth of 1 0.00 seconds total time

COLIN

COLIN (short of COntinuous LINear process planner) is an automated PDDL planner developed by Amanda Coles et al. in 2009 ([3]). It is capable of reasoning with Continuous Linear numeric change, using a combination of forward-search and linear programming to reason about what are the actions to apply and when, given the relationship between time and numbers. COLIN supports numeric expressions and durative actions, but it completely ignore plan metrics: its plans are not supposed to be optimal, even if it often leads to a solution when MetricFF fails ([2]). COLIN is built on the planner CRICKEY3 (K. Halsey et al, 2002), from which inherits its representation of states, the machinery for confirming the temporal consistency of plans and the basis for the heuristic function. The

3.2. AUTOMATED PLANNERS

27

forward-chaining search heuristic is similar to the one used by FF (i.e. it is based on the same relaxed planning graph that is used in FF), while the pruning techniques are based on temporal constraints and are much less aggressive. A sample COLIN output, generated from the PDDL problem 3.3, is shown on listing 3.5. It is worth noting that it shows the plan cost as well as actions’ durations (even if we are not interested about them in this thesis), lacking of halfway and final states’ information, such as predicates that are true of function values, just like MetricFF. Figure 3.1 shows the different performances of MetricFF and Colin dealing with unconstrained problems defined in a multi modal journey domain that defines both qualitative (e.g. the traveller position) and quantitative (e.g. the distance between two cities) information of the world state as PDDL propositions and numeric fluents. While MetricFF is much faster in smaller problems, it fails attempting to solve bigger ones, while COLIN leads to a solution, even if spending a lot more time ([2]). Listing 3.5: A sample COLIN output. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Number of literals : 6 Constructing lookup tables : Post filtering unreachable actions : No semaphore facts found , returning Have identified that bigger values of ( fuel - level truck ) are preferable Have identified that bigger values of ( fuel - level car ) are preferable No analytic limits found , not considering limit effects of goal - only operators Not looking for earlier - is - better time - dependent rewards : no goal limits Initial heuristic = 3.000 b (2.000 | 0.000) b (1.000 | 0.001);;;; Solution Found ; States evaluated : 4 ; Cost : 105.000 ; Time 0.00 0.000: ( drive truck rome paris ) [0.001] 0.001: ( drive car paris berlin ) [0.001] 0.002: ( drive car berlin rome ) [0.001]

28 CHAPTER 3. AN OVERVIEW OF PLAN SOLVING TECHNIQUES

Chapter 4 Characterising the problem of mission planning As described on chapter 3, the chosen way to deal with the problem is to make use of automated planners, like COLIN and MetricFF, that accept PDDL files as input. To create such files, we need a more precise specification of the problem and of the application’s desired functionalities.

4.1 4.1.1

Entities of the domain Human agents involved

End user The end users are the human agents that are able to create targets and requests observations. They are the final addressee of the service, meaning that they will receive the data collected by the UAVs and will use them for specific activities, such as traffic control, city planning or pollution analysis. Thus, an end user is not aware about the UAV availability, other users’ requests, mission definitions or mission plans. Operator The operator is the internal employee that actually uses the system’s planning features. His work arises from the end users’ requests, and includes his awareness of the UAV availabilities, the sensor suites they mount, the airports they are placed in. The main goal of the operator is to exploit the system to create mission plans that minimize the resources usage. 29

30CHAPTER 4. CHARACTERISING THE PROBLEM OF MISSION PLANNING Table 4.1: The typical technical information of UAV classes Class MALE MAME Light

4.1.2

Wing span (m)

Weight (kg)

Cruising speed (m/s)

Cruising altitude (m)

Operating time (h)

10 7.20 9

800 490 150

50 46 10

1500 1450 200

9 8 3

UAV models

Unmanned Aerial Vehicles are aircrafts without a human pilot aboard. As specified on chapter 2, SMAT makes use of three different classes of UAVs, MALE, MAME and Light, whose typical technical information are reported on table 4.1.

4.1.3

Sensors and sensor suites

Sensors All observation tasks are associated to an observation device, according to the client’s request. SMAT considers five different sensors: video camera, infrared camera, electro-optic camera, hyper-spectral camera and radar. In some configurations, UAVs are able to perform data fusion during the mission, before sending the data on ground: specifically, this feature is available with electro-optic and infra-red cameras, electro-optic camera and radar, infra-red camera and radar. Sensor suites The compatibility between the sensors specified on the observation requests and the effective UAV support is guaranteed by sensor suites. A sensor suite is the logical representation of a set of sensors that can be installed on an UAV: once a sensor suite is installed, the vehicle won’t be able to carry any other sensor. The UAVs used in the project supports the following suites: • Electro-optic camera, hyper-spectral camera; • Electro-optic camera, hyper-spectral camera, infra-red camera, radar; • Electro-optic camera, hyper-spectral camera, radar; • Electro-optic camera, infra-red camera;

4.1. ENTITIES OF THE DOMAIN

31

• Electro-optic camera, infra-red camera, radar; • Electro-optic camera, radar; • Hyper-spectral camera, radar; • Clearly, any single sensor can be mounted on UAVs as a “sensor suite”.

4.1.4

Airports

A mission plan is well formed if all its UAVs are on ground at the starting time and at the ending time. An UAV can only land on an airport, more precisely on the same airport from which it took off to perform its part of the mission. The system is able to store information about any airport, but as the SMAT considered area is the north-western part of Italy, this project implementation includes the Piedmont region’s two main airports: “Sandro Pertini” Airport located at Caselle Torinese, 16 km north-northwest of the city of Turin, coded TRN by International Air Transport Association; Cuneo Levaldigi Airport located at Levaldigi (fraction of Savigliano), 21 km north-east of the city of Cuneo, coded CUF by International Air Transport Association.

4.1.5

Targets

A target is a location on Earth that is supposed to be somehow “interesting” for the client that requests its observation. On this stage, SMAT considers two kinds of target, point and polyline ones. Point targets A point target is simply described by its coordinates. It is worth noting that in some cases a set of close point targets can be considered as a single one, making the planning computationally easier. Polyline targets A polyline target is described by a sorted list of coordinates defining a polygonal chain, that permits to calculate its length. A polyline target can be observed from its first point to the last, or indifferently from its last point to the first.

32CHAPTER 4. CHARACTERISING THE PROBLEM OF MISSION PLANNING

4.1.6

Observation requests

An observation request represents a client’s need to observe a target. It must specify a date and, within it, the earliest and the latest time of observation, along with its minimum duration. It is worth noting that the minimum duration includes the sensor’s setup, its pointing phase and, clearly, the observation itself. Each observation request is linked to a single target and to a sensor type (or to a data fusion sensors set), whereas it is not yet linked to any UAV.

4.1.7

Mission

A mission is the set of actions through which one or more observation requests are satisfied using a limited set of UAVs that depends on their availability. Mission definition The operator that creates a mission must specify its minimum duration, its date and, within it, the earliest and latest time in which all operations (takeoffs, landings, transfers and observations) must be performed. The state of art of automated planners’ computational complexity impose the assignment of each observation request to an available UAV by the human agent. The operator can also specify another kind of constraint called MultiObs between pairs of observation requests. There are two types of MultiObs: BEFORE(request1, request2) request1 is forced to be performed before request2; OVERLAPS(request1, request2) the intersection between requests’ observation windows (i.e. the period between their earliest and latest times) must not be empty. A mission definition is valid if and only if: 1. its earliest time precedes its latest time; 2. the earliest time and the latest time belongs to the same date; 3. all observation requests it contains are relative to the mission definition’s date; 4. for each pair , the UAV’s availability is so that the UAV mounts a sensor suite that permits to satisfy the observation request and the distance between the airport it is placed into

4.1. ENTITIES OF THE DOMAIN

33

and the target to observe is less than or equal to the UAV’s maximum operability distance; 5. for each MultiObs: • if it is a BEFORE constraint, the first observation request’s latest time precedes the second one’s; • if it is an OVERLAPS constraint, the intersection between its observation requests’ time windows is not empty. Mission plan Given a mission definition, a mission plan is the automatic planner’s output that specifies the actions that have to be performed in order to satisfy the definition’s requirements. It is worth noting that the actions performed by the UAVs and by the sensor suites they are set up with are deeply different and conceptually separated, even if the geographic position of the owning agent can be the same: consequently, in this representation both UAVs and sensor suites are considered as parallel and independent “agents”. A mission plan is also needed to keep information about the initial state of all used UAVs, that is made up of the airport in which they are placed, the sensor suites they mount and the time of their first action. A mission plan relative to a mission definition m is conforming to m if and only if: 1. at the end of the plan execution, all UAVs are placed in their originating airports; 2. at the end of the plan execution, all targets specified by the observation requests are covered by their assigned UAV; 3. for each observation request r, the monitoring action it expects is completely performed within r’s time window and has a duration that is more than or equal to r’s minimum duration; 4. for each MultiObs, given the monitoring actions m1 and m2 , fullfillments of its observation requests: • if it is a BEFORE constraint, m1 ’s ending time precedes m2 ’s starting time; • if it is an OVERLAPS constraint, the intersection between m1 and m2 ’s time windows is not empty;

34CHAPTER 4. CHARACTERISING THE PROBLEM OF MISSION PLANNING 5. the earliest takeoff action’s starting time follows m’s earliest time; 6. the latest landing action’s ending time precedes m’s latest time; 7. the period between the earliest takeoff action’s starting time and the latest landing action’s ending time lasts less than m’s maximum duration;

4.2

Application functionalities

The application is requested to support end-users in defining targets, describing observation requests, planning missions and understanding mission plans.

4.2.1

Targets and observation requests definition

The user will be able to define point and line targets and setting their name, directly selecting coordinates on a map. All the targets that have been defined and their details (name and coordinates) are shown on the user interface. In the same interface, the user will be able to create observation requests starting from previously defined targets, specifying the client’s name, the observation’s earliest and latest time and its minimum duration. All data is saved on a database, and it will be possible to edit and delete both targets and requests.

4.2.2

Mission planning

Another interface will permit to define a date and a rectangular area: the system will automatically show to the user the corresponding observation requests. The user will be allowed to choose a subset of them, according to their compatibility with UAV availability in the chosen date. The following step is assigning each request to a compatible UAV, defining the mission time constraints (earliest time, latest time, maximum duration) and restrictions between pairs of observations (before, overlap). When all data will be correctly set, the user will be able to request the system to call MetricFF to find an optimal solution and, if this computationally heavy task fails, COLIN, that looks for a suboptimal solution.

4.2. APPLICATION FUNCTIONALITIES

4.2.3

35

Mission displaying

The plan output will be shown in a geographic way, displaying every agent’s path on the map, with different shapes according to the current action (takeoff, loiter, monitoring, transferring. . . ), providing at the same time information about the time in which every action is performed by the owning UAV or sensor suite.

36CHAPTER 4. CHARACTERISING THE PROBLEM OF MISSION PLANNING

Chapter 5 Application architecture 5.1

System overview

The planning system can be summarized as in figure 5.1. It is possible to distinguish on it two different human agents: End user He is an external client that requests some target to be observed, without access to any information about the UAVs’ availabilities or their location on the requested date; Operator He is supposed to be an internal employee with full access to the UAVs and airports information, as well as to previously planned missions. His task is defining missions that will satisfy the end users’ observation requests, minimizing the resources usage. The plans will be saved on the database, so that the operator will be able to view them whenever he wants. It is worth noting that the mission defined by the operator is not passed to the PDDL encoder as it is: section 6.2.1 describes how clustering and heuristic-based improvements are performed before calling the automated planners.

5.2 5.2.1

Used technologies Java SE 8

The 8th version of the Java Platform, Standard Edition was released on 18 March 2014 and included some features that were planned for Java 7 but later deferred. This section reports the most interesting ones from the point of view of the application described on this thesis. 37

38

CHAPTER 5. APPLICATION ARCHITECTURE

Figure 5.1: A sketch of the system architecture

5.2. USED TECHNOLOGIES

39

Date-Time packages Java 8 introduces new Date-Time APIs, a set of packages that model the most important aspects of date and time, replacing java.util.Date, java.util.Calendar, java.util.TimeZone and their subclasses. This update was needed because the Calendar class was not type safe, the classes could not be used in multithreaded applications because of their mutability, bugs in application code were common because of the unusual numbering of months and, again, the lack of type safety. The new core classes in the java.time package solve those issues and use, by default, the Gregorian calendar system. In particular, the application makes extensive use of the following classes: java.util.LocalDateTime A date-time without a time-zone in the ISO8601 calendar system, such as 2007-12-03T10:15:30. It is used to represent earliest and latest times of both observation requests and missions, the planned agent’s state in a specific instant, the planned actions’ begin and ending time. java.util.LocalDate A date without a time-zone in the ISO-8601 calendar system, such as 2007-12-03. It is used to represent the begin and ending date of a UAV availability. java.util.Duration A time-based amount of time, such as ‘34.5 seconds’. It is unity of measure independent and it is used to represent an observation request’s minimum duration, a mission’s maximum duration, the airports’ takeoff and landing durations and the durative actions’ durations. Lambda expressions and streams Lambda expressions are a smart and concise way to define anonymous functions, not bounding them to an identifier. Java 8 borrows lambda expressions from functional programming: they provide a very useful way to replace anonymous inner classes, whose issue is that, if they implement an interface that contains only one method, then their syntax may seem unwieldy and unclear. In these cases, they are typically used to pass functionality as an argument to another method, such as what action should be taken when someone clicks a button. Lambda expressions enable the programmer to treat a functionality as a method argument, making code clearer and more readable. A stream is a sequence of elements supporting sequential and parallel aggregate operations, whose functionality aims to replace Java’s enhanced

40

CHAPTER 5. APPLICATION ARCHITECTURE

for loop. Starting from version 8, the java.util.Collection interface has the method Stream stream(), starting point of a pipeline, that is a sequence of aggregate operations that ends with a terminal one. The pipeline methods often require simple interfaces as arguments that can be easily expressed as lambda functions. The convenience of streams becomes very clear analysing an example of implementation, like listing 5.1, that shows a simple piece of code in both Java 7 and Java 8 styles. The application described in this thesis totally embraces Java 8’s philosophy, always using streams in place of enhanced for loops and implementing single method interfaces through lambda expressions. Listing 5.1: Comparison between enhanced for loop and Java 8 streams 1 2 3 4 5 6 7 8 9 10

// Java 7: enhanced for loop double average = 0; for ( Item item : collection ) { if ( p . g e t So m e Bo o l ea n F ie l d () { int intField = p . getSomeIntField (); average = average + intField ; } } average = average / collection . size (); return average ;

11 12 13 14 15 16 17

// Java 8: streams and lambda expressions return collection . stream () . filter ( p -> p . g e t So m e Bo o l ea n F ie l d ()) . mapToInt ( p -> p . getSomeIntField ()) . average () . getAsDouble ();

JavaFX According to Oracle Corporation, JavaFX is “the next step in the evolution of Java as a rich client platform, designed to provide a lightweight, hardwareaccelerated Java UI platform for enterprise and business applications”. It provides an innovative GUI library that is intended to replace Swing as the standard Java graphic APIs. Thus, the developed software’s graphic user interface is purely JavaFX. Its most interesting class used by the application is javafx.scene.web.WebEngine, a non-visual object capable of managing HTML pages, that supports two-way communication between a Java application and the page’s JavaScript code. Every WebEngine instance is managed by a javafx.scene.

5.2. USED TECHNOLOGIES

41

web.WebView widget. The application exploits JavaFX web capabilities to bring Google Maps features to a desktop application, as descrived in sections 5.2.2 and 5.2.3.

5.2.2

Google Maps JavaScript API

Google Maps is certainly the most widely used web mapping service. Google launched the free Maps JavaScript API in June 2005 to allow developers to embed a map into external websites, with the opportunity to enrich that map with data related to the website purposes. Over 1,000,000 websites use this package, making it the most heavily used web application development API. Google Maps JavaScript API allows developers to draw shapes on the map, such as markers, polygons, polylines and circles. Even if this library is designed for web development, JavaFX technology can be exploited to integrate Google Maps into the desktop application described in this thesis. The resulting graphic interface has the ability to represent in the most user-friendly way the domain-specific geographic entities, such as targets and mission plans.

5.2.3

GMapsFX

A pure JavaFX and Google Maps JavaScript API approach would force the developer to write “dirty” Java class files that contain JavaScript code as strings. The debugging phase would forcely be moved from compilation time to runtime: the result would be a slower, less accurate development of messy and low-readable code. A good way to avoid putting JavaScript code on Java source files is wrapping the Google Map JavaScript API’s classes in corresponding Java ones, allowing the developer to use and interact with maps using a pure Java API: the open-source library GMapsFX is made for this. Listing 5.2 compares a marker insertion in the map with and without the help of GMapsFX. Listing 5.2: A simple marker insertion in a Google Map using pure JavaFX and GMapsFX 1 2 3 4 5 6 7

// JavaFX and Google Maps JavaScript API WebEngine webEngine = webView . getEngine (); engine . executeScript ( " var ␣ map ␣ = ␣ document . getElementById ( ’ map - canvas ’) " ); JSObject map = engine . executeScript ( " map " ); engine . executeScript ( " var ␣ latLng ␣ = ␣ new ␣ google . maps . LatLng ( " + 47.6 + " ,␣ "

42 8 9 10 11 12 13 14 15 16 17 18 19 20

CHAPTER 5. APPLICATION ARCHITECTURE

+ -122.3 + " ) " ); JSObject latLng = engine . executeScript ( " latLng " ); engine . executeScript ( " var ␣ markerOptions ␣ = ␣ new ␣ google . maps . MarkerOptions () " ) JSObject markerOptions = engine . executeScript ( " markerOptions " ); markerOptions . setMember ( " position " , latLng ); markerOptions . setMember ( " visible " , Boolean . TRUE ); markerOptions . setMember ( " title " , " Sample ␣ marker " ); engine . executeScript ( " var ␣ marker ␣ = ␣ new ␣ google . maps . Marker ( markerOptions ) " ); JSObject marker = engine . executeScript ( " marker " ); marker . call ( " setMap " , map );

21 22 23 24 25 26 27 28 29

// GMapsFX GoogleMap map = googleMapView . getMap (); MarkerOptions markerOptions = new MarkerOptions () . position ( new LatLong (47.6 , -122.3)) . visible ( true ) . title ( " Sample ␣ marker " ); Marker marker = new Marker ( markerOptions ); map . addMarker ( marker );

5.2.4

PostgreSQL

PostgreSQL is a powerful, well documented, standard-compliant, open source object-relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It runs on all major operating systems and it is fully ACID compliant. PostgreSQL has full support for foreign keys, joins, views, triggers, and stored procedures in multiple languages. It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, VARCHAR, DATE and TIMESTAMP and has native programming interfaces for the most popular programming languages, including Java Database Connectivity (JDBC). The application described in this thesis leans on a PostgreSQL relational database, in which it stores both static and dynamic information. Static information like airports, UAV models and UAV availabilities are pre-loaded directly during the deployment using Data Manipulation Language instructions, whereas dynamic data, such as targets, observation requests, UAVs, missions and their plans, is inserted by the application through JDBC.

5.2. USED TECHNOLOGIES

5.2.5

43

Automated planners

Section 6.2.2 explains how the planning task is divided in two stages, each one corresponding to the call to a different program: first MetricFF, with the aim of finding an optimal solution, and then, in case of fail, COLIN, that has no heuristic guidance and “simply” searches an admissible solution, if it exists. MetricFF As described in section 3.2.1, MetricFF ([7]) offers to its end-user five different search algorithms: within them, A* is the only one that looks for an optimal plan, but its space and time complexity is, in the worst case, exponential in the length of the solution. This means that MetricFF won’t often find a complex mission’s plan, but its opportunity to find a solution that is far better than the ones returned by COLIN is a good reason to try anyway. COLIN COLIN is a PDDL planner that uses a combination of forward-search and linear programming ([3]). It supports the language version 2.1, that introduced numeric fluents and durative actions, and returns admissible solutions that are not guaranteed to be optimal (they aren’t in most cases).

44

CHAPTER 5. APPLICATION ARCHITECTURE

Chapter 6 Model, View, Controller of the system The system implementation is based on the Model–view–controller (MVC) software architectural pattern, originally introduced in 1978 by Trygve Reenskaug for implementing user interfaces. The MVC pattern has evolved during the years: today it’s used in many development frameworks, such as Ruby on Rails, Django and ASP .NET MVC, and it’s the most used pattern not just in desktop programs that uses a graphical user interface, but in web applications as well. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user: Model It captures the behavior of the application in terms of its problem domain, independent of the user interface and usable by different ones (websites, mobile applications, desktop programs. . . ). It directly manages the data, logic and rules of the application. In a Java application, each domain entity usually corresponds to a class. View It corresponds to any output representation of information, such as a desktop GUI or an HTML. Thanks to the pattern modularity, multiple views of the same information are possible. Controller It accepts input from the view and converts it to commands for the model, or vice versa. Sections 6.1 6.2, and 6.3 describe those three parts inside the application described in the thesis. 45

46 CHAPTER 6. MODEL, VIEW, CONTROLLER OF THE SYSTEM

6.1

Model

As described before, the aim of the Model implementation is to supply the application with an internal representation of the domain. As Object Oriented Programming encourages the correspondence between domain entities and Java classes, most files contained in the model package consist in a simple structure that offers a constructor and getter/setter methods, and are consequently very easy to understand; other classes adds more sophisticated features, that will be described in the next sections.

6.1.1

Target class

This class is a representation for both punctual and linear targets: it carries a list of Coordinates: the method boolean isPointTarget() will return true if this list has only one element, allowing the other components to distinguish the target type when they need. The length double field will be more than 0 only if the target is linear: in this case, it is calculated on method void calculateLength() call, that iterates over the positions list.

6.1.2

Sensor and SensorSuite classes

The Sensor class has a nested enum that describes all sensor types listed in section 4.1.3 and offers the method boolean dataFusionIncompatible(Set sensors), useful in observation requests definition. SensorSuite is an enumerated type that contains members like S_EO and S_CAMERA, that corresponds to a single sensor suite, and members like SUITE_1 and SUITE_7 that represent suites with more than one sensor. The mapping between a SensorSuite enumerator and the SensorTypes they carry is done by the private method Set getSuite(), called by the package-private one boolean contains(Set sensors).

6.1.3

ObservationRequest and ClusteredRequest classes

As an observation request contains time information, the ObservationRequest class offers some interesting time-related methods that are useful to intelligently generate consistent mission definitions: long bestTimeFor(UAV uav) It returns the time needed by the parameter UAV to fly through the request’s target. The method is called only on instances that represent linear targets.

6.1. MODEL

47

boolean timeCompatibleWith(ObservationRequest request) It indicates if the actual request and the parameter one are “compatible”, meaning that their earliest and latest times, as well as minimum duration times, are such that the two requests may be clustered. boolean timeIncompatibleWith(UAV uav) It checks the correspondence between the time needed by the parameter UAV to fly through the request’s target and the minimum duration time, with a 15% tolerance. ClusteredRequest is a subclass of ObservationRequest, and represents a set of requests that can be considered as a single one by the PDDL planner, reducing its execution’s complexity. The represented requests are contained in the representedRequests field, and the class can be instantiated through the static ClusteredRequest clusterOf(Set cluster) method, that chooses a representative from the cluster and assigns values in this way: earliestTime The latest earliestTime among cluster elements; latestTime The earliest latestTime among cluster elements; minDuration The sum of all minDurations; id The representative’s id; client The representative’s client name; target A new point target, whose coordinates are the average between those of the cluster’s targets. Obviously, an ObservationRequest can be checked to be a cluster with the boolean expression request instanceof ClusteredRequest.

6.1.4

UAV and UAVAvailability classes

UAVAvailability associates an UAV and a date period (i.e. a beginDate and an endingDate) to the airport in which the UAV is located and to the sensor suite mounted on the vehicle in that time interval. It includes the boolean canHandle(ObservationRequest request) method, that checks the compatibility of the request in terms of date, requested sensors and target distance in relationship to the UAV maximum operability distance. The UAV class representation stores a list of UAVAvailability instances, used to implement the following methods:

48 CHAPTER 6. MODEL, VIEW, CONTROLLER OF THE SYSTEM boolean canHandle(ObservationRequest request) It iterates over the availabilities, calling the same named method on each of them and returning their return values’ disjunction. UAVAvailability getAvailabilityFor(ObservationRequest req) It returns the UAVAvailability that is able to handle the parameter request, or null if it does not exist.

6.1.5

Mission and Plan classes

The Mission class contains all operator defined mission definition data: earliest time, latest time, maximum duration, a set of MultiObs and all the UAVAvailability assigned to the ObservationRequests, stored into the class as an hash table. It also offers all PDDL decoding methods, such as Airport decodeAirport(String pddlAirport) or UAV decodeUav(String pddlUav), and two functions used by the PDDL encoder to ease the problem to pass to the automated planners: LocalDateTime getFirstUsefulTakeoffTime(UAVAvailability uavAv)) It returns the earliest time in which the parameter UAV can take-off ensuring that it won’t arrive too soon, from the point of view of the request’s earliest time, to its first target. void QTClustering() It internally modifies the object, executing the Quality - Threshold clustering algorithm on the observation requests, as described in section 6.2.1, and replacing all those that are part of a cluster with a ClusteredRequest class, described above. The resulting set of UAV availabilities corresponds to the initial state of the plan returned by the automated planners: in addition to that, the Plan class contains the start times of each UAV and every agent’s action list, stored in two fields, Map