• No results found

Intuitive Mission Handling with Automatic Route Re-planning using Model Predictive Control

N/A
N/A
Protected

Academic year: 2021

Share "Intuitive Mission Handling with Automatic Route Re-planning using Model Predictive Control"

Copied!
64
0
0

Loading.... (view fulltext now)

Full text

(1)

Institutionen för systemteknik

Department of Electrical Engineering

Master thesis report

Intuitive Mission Handling with Automatic Route

Re-planning using Model Predictive Control

Examensarbetesrapport för examensarbete i Reglerteknik vid Tekniska högskolan vid Linköpings universitet

av

Emma Andersson LiTH-ISY-EX--12/4605--SE

Linköping 2012

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(2)
(3)

Intuitive Mission Handling with Automatic Route

Re-planning using Model Predictive Control

Examensarbetesrapport för examensarbete i Reglerteknik

vid Tekniska högskolan i Linköping

av

Emma Andersson LiTH-ISY-EX--12/4605--SE

Handledare: Sina Khoshfetrat Pakazad, sina.kh.pa@isy.liu.se

isy, Linköpings universitet

Eva Anjou, eva.anjou@saabgroup.com

Saab Aeronautics

Kenny Stjernström, kenny.stjernstrom@saabgroup.com

Saab Aeronautics

Examinator: Daniel Axehill, daniel@isy.liu.se

isy, Linköpings universitet

(4)
(5)

Avdelning, Institution

Division, Department

Division of Automatic Control Department of Electrical Engineering Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2012-06-19 Spr ˙ak Language  Svenska/Swedish  Engelska/English   Rapporttyp Report category  Licentiatavhandling  Examensarbete  C-uppsats  D-uppsats  Övrig rapport  

URL för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-80638 http://www.ep.liu.se ISBNISRN LiTH-ISY-EX--12/4605--SE

Serietitel och serienummer

Title of series, numbering

ISSN

Titel

Title

Intuitiv uppdragshantering med modellbaserad prediktionsreglering för automa-tisk ruttomplanering

Intuitive Mission Handling with Automatic Route Re-planning using Model Predictive Control Författare Author Emma Andersson Sammanfattning Abstract

The system for mission handling in the Gripen fighter aircraft, and in its ground supporting system, consists for example of ways to plan mission routes, create mission points and validate performed missions. The system is complex and for example, the number of different mission points used increases due to changing

demands and needs. This master thesis presents suggestions for improvements

and simplifications for the mission handling system, to make it more intuitive and more friendly to use. As a base for the suggestions, interviews with pilots from Saab, TUJAS and FMV have been conducted, this is to obtain opinions and ideas from those using the system and have deep knowledge about it.

Another possible assistance and improvement is to provide the possibility of

on-line automatic re-planning of the mission route in case of obstacles. MPC

(Model Predictive Control) has been used to estimate the obstacle’s flight path, and calculate a new route to the next mission point which does not conflict with the estimated enemy’s path. This system has been implemented in Matlab and the concept is demonstrated with different test scenarios where the design parameters (prediction horizon and penalty in the cost function) for the controller are varied, and stationary and moving obstacles are induced.

Nyckelord

Keywords Mission handling and planning, Mission polygon, Route re-planning, Model

(6)
(7)

Abstract

The system for mission handling in the Gripen fighter aircraft, and in its ground supporting system, consists for example of ways to plan mission routes, create mission points and validate performed missions. The system is complex and for example, the number of different mission points used increases due to changing demands and needs. This master thesis presents suggestions for improvements and simplifications for the mission handling system, to make it more intuitive and more friendly to use. As a base for the suggestions, interviews with pilots from Saab, TUJAS and FMV have been conducted, this is to obtain opinions and ideas from those using the system and have deep knowledge about it.

Another possible assistance and improvement is to provide the possibility of on-line automatic re-planning of the mission route in case of obstacles. MPC (Model Predictive Control) has been used to estimate the obstacle’s flight path, and calculate a new route to the next mission point which does not conflict with the estimated enemy’s path. This system has been implemented in Matlab and the concept is demonstrated with different test scenarios where the design parameters (prediction horizon and penalty in the cost function) for the controller are varied, and stationary and moving obstacles are induced.

Sammanfattning

Systemet för uppdragshantering i stridsflygplanet Gripen, och i dess markstöd-system, består bland annat av uppdragsplanering, skapande av uppdragspunkter och möjligheter att validera utförda uppdrag. Systemet är komplext och exempel-vis växer antalet uppdragspunkter med omvärldens ökande krav och behov. Detta examensarbete presenterar förslag till förenklingar och förbättringar i uppdrags-hanteringssystemet, för att göra det mer intuitivt och användarvänligt. Som grund för förslagen har intervjuer med piloter från Saab, TUJAS och FMV gjorts, för att samla in åsikter och idéer från de som använder systemet och har bred kunskap om det.

En förbättring är en möjlighet till online automatisk omplanering av upp-dragsrutten vid hinder. MPC (modellbaserad prediktionsreglering) har använts för att estimera den dynamiska fiendens flygväg, och beräkna en ny rutt till nästa uppdragspunkt som inte ligger i konflikt med den estimerade vägen för hindret. Detta system har implementerats i Matlab och konceptet demonstreras med olika

(8)

vi

testscenarion där prestandaparametrar (prediktionshorisont och straff i kostnads-funktionen) för regulatorn varieras, och stationära och rörliga hinder induceras.

(9)

Acknowledgments

Firstly I would like to thank all the people at Saab who have helped me during this master’s thesis, and a warm-hearted thank you is especially aimed at my supervisors at Saab, Eva Anjou and Kenny Stjernström for your guidance and help. Thanks especially also Jan-Erik Eriksson and Sören Molander for interesting discussions, and to Zoran Sjanic and Tina Erlandsson for guiding me to interesting related work. Thanks to all the test and fighter pilots who dedicated time for me and for interesting discussions about mission handling and sometimes fighter aircraft in general.

I would then especially like to thank my supervisor Sina Khoshfetrat Pakazad at LiU for all your help and support. Thanks to my examiner Daniel Axehill for guidance and tips. Thanks to Johan Löfberg for Yalmip support.

Finally I would like to thank my supportive family and friends.

(10)
(11)

Contents

1 Introduction 1 1.1 Abbreviations . . . 1 1.2 Problem Formulation . . . 1 1.3 Background . . . 1 1.4 Method . . . 5 1.5 Limitations . . . 5

1.6 Purpose and Goal . . . 5

1.7 Outline of the Report . . . 6

2 Theory 7 2.1 Model Predictive Control . . . 7

2.1.1 The MPC Algorithm . . . 7 2.2 Cost Function . . . 8 2.3 Modeling . . . 8 2.3.1 Discretization . . . 9 2.4 Quadratic Programming . . . 9 2.4.1 Matrix Definitions . . . 10

2.4.2 The Quadratic Programming Problem Formulation . . . 11

2.5 Representation of Obstacles . . . 13

3 Algorithms 15 3.1 The Model . . . 15

3.2 The Cost Function . . . 18

3.3 The Quadratic Programming Problem . . . 18

3.4 Obstacle Representation . . . 18

3.4.1 Hyperplanes with Binary Variables . . . 19

3.4.2 Obstacle Avoidance with a Single Hyperplane . . . 21

3.5 The MPC Formulation . . . 23

3.5.1 Using the Obstacle Avoidance Method with Binary Variables 23 3.5.2 Using the Obstacle Avoidance Method with a Single Hyper-plane . . . 25

(12)

x Contents

4 Results 27

4.1 Suggestions for Improvements in the Mission Handling System . . 27

4.1.1 Reduced Number of Different Types of Points . . . 27

4.1.2 Continuous Curve . . . 29

4.1.3 Flexibility . . . 30

4.1.4 More Efficient Use of the AR Point . . . 31

4.1.5 Flexibility in the Fuel Calculations . . . 31

4.1.6 Reconnaissance . . . 32

4.1.7 Area Points . . . 34

4.1.8 Flight Corridors . . . 34

4.1.9 Support for Landing . . . 34

4.2 The Route Re-planning System . . . 36

4.2.1 Test Scenarios . . . 36

4.2.2 The Approximation Algorithm . . . 36

4.2.3 Results from the Test Scenarios . . . 36

5 Conclusions 43 6 Discussion and Future Work 45 6.1 Discussion on Improvement Suggestions . . . 45

6.1.1 Future Work . . . 46

6.2 Discussion on the Re-planning System . . . 46

6.2.1 Future Work . . . 47

(13)

Chapter 1

Introduction

This chapter gives an introduction to the master thesis and includes a description of the problem and the method to solve it. The abbreviations used throughout the report are also introduced here.

1.1

Abbreviations

Table 1.1 shows the nomenclature and abbreviations used in the report.

1.2

Problem Formulation

The master thesis is about reviewing how the present system for mission handling in the Gripen aircraft, and its support system for mission planning, the MSS, could be simplified and improved. As an improvement, a system for re-planning the route in case of presence of an obstacle has been implemented in Matlab, using MPC to predict the obstacle’s and the aircraft’s movement, and re-plan the mission route if there is any possibility of collision with the obstacle’s estimated path.

1.3

Background

The mission handling system in the Swedish JAS 39 Gripen aircraft includes ways of creating routes to be followed. Every route consists of different types of route points. The number of route points grow due to change of the surrounding world, which gives increasing complexity in the planning and creation of missions. The master thesis was therefore formulated with the purpose to review the system to find simplifications and improvements to make the system better, and more friendly to use.

(14)

2 Introduction

MPC Model Predictive Control

MSS Mission Support System (ground system)

QP Quadratic Programming

YALMIP An optimization toolbox for Matlab

W Waypoint

WL Waypoint for landing

L Landing base

C Combat Air Patrol point

R Reconnaissance point

OF Offset point

AR Air Refuel point

T Target point

Polygon leg The line between two points in the mission

polygon

Mission polygon (Mission route) See Example 1.1

SID (Standard Instrument Departure), Predefined

take off polygon (civil take off base)

STAR (Standard Terminal Arrival Route),

Prede-fined landing polygon (civil landing base)

UAV Unmanned Air Vehicle

Table 1.1. Abbreviations and definitions.

The report consists of two main parts: firstly, the results from interviews with pilots that have used the mission handling system are presented. Those results consist of suggestions on functionalities that could make the system better and more intuitive to use. The second part is an implementation of an MPC controller that could be a solution for mission re-planning in case of change in the surround-ing, including appearance of obstacles or threats.

The automatic route re-planning suggests a new path to avoid an obstacle (or multiple obstacles), in order to reach the next mission point. The obstacle could be, for example, an enemy aircraft that has to be avoided. In some cases the enemy is not to be avoided, but to be attacked. In those cases the re-planning is unnecessary since the pilot must make many decisions on his/her own in air-to-air fight. However, in many other cases, for example if the originally planned route could not be followed and has been diverged from for some reason, it can be of great use to have a system where a new route is automatically suggested. The same system could be used for collision avoidance between aircrafts, or in UAV:s where the newly planned route is then not only a suggestion, but also it can be used for steering and controlling the UAV directly. Though, for that use the system needs to be improved and tested extensively, and should include better models for the vehicle to be steered in the three dimensional space.

(15)

informa-1.3 Background 3

tion is used for estimating the obstacle’s path to see if it is expected to conflict with the planned route at some point in time. In case of conflict, a new route is calculated which avoids the obstacle but still reaches the next active mission point in the shortest way possible, and without too much change in the reference speed. Dynamic obstacles have been considered here, to make the re-planning pro-cedure more general. Another example of an obstacle could be an anti-aircraft artillery, that is stationed on the ground and whose hitting range must be avoided; stationary obstacles could be modeled in the same way but with zero speed.

What is used today in some aircrafts are collision avoidance systems, for ex-ample in passenger flights. These systems have both the models and the given reference paths of the airplanes to predict their movements. The same system for collision avoidance in both airplanes can be used, since it is in their mutual interest not to collide. Systems for collision avoidance and path generation have been studied for example in [3], [4], [6], [7], [8] and [9]. For fighter aircrafts the paths are often rather unpredictable since it is unknown where the obstacle is heading. Also, fighter aircraft can turn and fly faster. However, here it will be assumed that the obstacle is not aware of the aircraft’s position, nor has its own re-planning system, and therefore it will not change its path to avoid the aircraft. However, any change in the movement of the obstacle is monitored.

Studies of previous work about MPC being used for obstacle avoidance and on-line route re-planning have been done. It seems that mostly stationary obstacles have been used, and the dynamics in the obstacles have not been modeled. The MPC calculations was in some cases done using nonlinear MPC (NMPC) since nonlinear motion models were used. In this master thesis, the models are linearized in each time step instead of using a solver for nonlinear MPC, which makes the solution more intuitive.

In one previous work the re-planning has been done in three dimensions, whereas only two dimensions are used here. Re-planning in three dimensions require the possible "next step" to be discretized to give a manageable number of possible future ways, which requires a discrete control signal (u in the models). This might give the consequences that the solution obtained (see section 2) is not the best one, or perhaps even no solution is given. The obstacle representation also become more complicated if three dimensions were used. However, when three dimensions are used you can also obtain a shorter path when using the terrain to "hide" from an obstacle, and change in altitude can also be included. If you fly at a low altitude the terrain must be considered in order not to fly into the terrain. The most desirable solution would be a flexible method that uses three dimensions for route re-planning, but still can use a continuous control signal, see chapter 6.2. Example 1.1 illustrates what a mission route can look like with today’s mission planning system.

(16)

4 Introduction

Figure 1.1 shows an example of what a mission route can look like. The abbrevi-ations for the mission points are given in table 1.1. Notice that the polygon legs (the lines between the points) are not visible from the start base, L0, to the first point in the mission route, W1, and equivalently the polygon leg between the last mission point, W4 and the first WL point is not visible.

In the landing polygons, (the procedure for landing is a separate polygon), only the polygon leg between the first WL point and the L point is visible until the first WL point becomes the destination. Then the pilot can see the whole landing polygon. W2 OR1 L0 R11 C1 W4 WL1 L1 L2 R12 W1 Mission polygon Polygon leg

Figure 1.1. An example of what a planned route can look like (today’s system). The different mission points in this example are waypoints (W), reconnaissance points (R), offset point for reconnaissance (OR), combat air patrol point (C), waypoints for landing (WL) and landing bases (L).

There are a lot of different types of points for describing the different "activities" in a mission. This increases the complexity of the system, which makes it more complicated to create route points and to plan missions. Most of the mission planning is done in the MSS (Mission Support System, ground system), but the pilot can use many of the same functionalities in the aircraft. It is necessary that the pilot also can re-plan the missions and manage the different points while on a mission, even if it is not very common to do a lot of changes in the aircraft, since there are usually several pilots on the same mission and the planned route must be followed. (More information about how pilots prepare themselves before a

(17)

mis-1.4 Method 5

sion and how they cope with all the information in the cockpit can be found in [10].) When the system is used, even if the ground crew or the pilots plan the missions, it is of great importance that the system makes sense to the user. Considering both the computational power, and the time it will take to plan the mission, the system must be easy to use and preferably not too complicated to be handled by the computer in the aircraft, with its even more limited resources.

1.4

Method

A literature study was done, both to get better understanding of the mission handling system, and to study related work where MPC was used for trajectory generation, obstacle avoidance or solving other optimal path problems. Interviews with pilots from Saab, from FMV and from TUJAS (Taktisk Utveckling JAS) was done, to get opinions and ideas about what could be improved in today’s mission handling system, from those with deep knowledge about how to use the system. These ideas were then assembled which resulted in suggestions on improvements presented in Chapter 4.1.

Models for the aircraft’s and for the obstacle’s movements where used in the automatic re-planning system. These models are in general nonlinear, and are therefore linearized in each time step so that linear MPC could be used to solve the control problem. This results in quadratic programming minimization problems with constraints on the control signal and the states.

1.5

Limitations

Note that the suggestions of functionalities for improvement that resulted from the interviews with the pilots are not implemented, but merely summarized and described in this report. The implementation of the MPC controller for route re-planning was done in Matlab with the purpose to illustrate a concept for obstacle avoidance using motion models and predictive control. The controller has some limitations, that are stated here and further discussed in chapter 6.2: The re-planning is done in two dimensions, (as most studied previous collision avoidance systems), and therefore does not use a terrain database. The obstacle representa-tion is approximated according to chapter 3.4, and the aircraft model is simplified to a two-dimensional polar model. In Matlab the optimization toolbox Yalmip [5] has been used, together with the solver Gurobi [2].

1.6

Purpose and Goal

The aim of the master thesis is to review the usability of the mission handling sys-tem and provide suggestions for improving the functionality to make it easier and more intuitive to use. This was done by interviewing pilots that use the system,

(18)

6 Introduction

who have great knowledge about how it works, and therefore have many ideas and opinions about what could be improved. A summary of the pilots opinions, and concrete suggestions for improvements in the system, can contribute to the development of a more user-friendly and efficient mission handling system.

One of the requirements of a good planning algorithm is its responsiveness with respect to changes in the environment. Of such changes, one can mention the appearance of obstacles and/or threats in the surroundings of the aircraft, which are to be avoided. As a result, automatic suggestion on a re-planned route when an obstacle is to be avoided, was implemented in Matlab to illustrate how MPC (Model Predictive Control) can be used to solve this problem. This becomes even more valuable when the number of obstacles are high enough that it is not trivial to find a safe path manually. This Matlab implementation of the MPC controller is a demonstration for a technical solution that can be further analyzed before integration in the rest of the mission handling system, but is an approach worthy of further development.

1.7

Outline of the Report

The following chapters are included in the report:

• Chapter 1: This chapter is an introduction to the master thesis and presents purpose and goal, the used abbreviations, a background to the problem and the method and limitations for the master thesis.

• Chapter 2: In this chapter the general theory is given, with description of the MPC approach, the modeling and the quadratic programming problem. • Chapter 3: This chapter describes the theory behind the problem, with the

used model and the obstacle representation.

• Chapter 4: This chapter consists of two main parts where the first presents the results from the interviews, as suggestions for functions for improvements and simplification, and the other part presents results from the implementa-tion of the MPC controller.

• Chapter 5: In this chapter the conclusions are shortly presented.

• Chapter 6: In this chapter the results and methods are discussed, and suggestions on future work are presented.

(19)

Chapter 2

Theory

In this chapter the general MPC approach is described, and it is shown how the minimization problem can be expressed as a quadratic programming problem.

2.1

Model Predictive Control

Model Predictive Control (MPC) is a useful control strategy which can consider constraints in the controlled process. A model of the system is used to predict the behavior of the plant and the control problem is formulated as a constrained optimization problem and can be solved on-line. Section 2.1.1 describes how the MPC loop works. For more about MPC, refer to [1].

2.1.1

The MPC Algorithm

The MPC algorithm that has been used here can be described in the following (N is the prediction horizon):

1. Measure the current state x(k), (or estimate x(k) with observer).

2. Use future reference xref(k + 1), ..., xref(k + N ) and current state x(k).

Cal-culate the future control signals, u(k), ..., u(k + 1 − N ), by minimizing the cost function: minimize the future deviation from reference while avoiding the obstacle (constraints in x). Consider possible constraints in u.

3. Apply the first control signal u(k), and calculate the first output y(k), and the next state x(k + 1) = f (x(k), u(k)).

4. Time update, k = k + 1. 5. Repeat from step one.

(20)

8 Theory

2.2

Cost Function

To calculate the optimal control signals a cost function is minimized. The cost function is formulated with the purpose to penalize deviations from different de-sired conditions. A cost function can consist of one part for steering the states and one part for the control inputs, where you can for example penalize the size, changes or deviation from a reference. See Equation 2.1 for a general look of a cost function.

COST =

| {z }

Penalty for States

+

| {z }

Penalty for Control inputs

(2.1)

In the following example of a cost function, Equation 2.2, it is desired to follow a reference for the states, and to minimize changes in the control signals.

COST = N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − u(k + j − 1) 2 Q2 (2.2) y is the output, r is the desired reference for y and u is the control signal, (all might be vectors). Q1and Q2are penalty matrices (or scalars) for deviating from

the reference and for changes in u respectively.

2.3

Modeling

In this section, the general modeling, and linearization of it, are described. The nonlinear, time continuous state space model can be described as:

˙

x(t) = f (x(t), uin(t))

y(t) = Cx(t) uin∈ U

(2.3)

where x(t) are the states, y(t) the outputs and uin ∈ U are constraints on the

control signals.

This model is linearized at each time step, around the point (¯x, ¯u), using first order Taylor expansion around that point. This gives the approximate linear model: ˙ x(t) ≈ f (¯x, ¯u) + ∂f (x, uin) ∂x x,¯¯u (x(t) − ¯x) +∂f (x, uin) ∂uin x,¯¯u (uin(t) − ¯u) y(t) = Cx(t) (2.4)

The model is then discretized according to Section 2.3.1. The discrete time, linear model is:

x(k + 1) = F x(k) + Guuin(k) + xconst

y(k) = Cx(k) uin∈ U

(21)

2.4 Quadratic Programming 9

The constant terms xconstare included in the model by defining

G =Gu xconst  and u =uin 1  which gives x(k + 1) = F x(k) + Gu(k) y(k) = Cx(k) u ∈ U (2.6)

2.3.1

Discretization

Discretization of the model is done using the c2d command in Matlab. Theoret-ically, this would be according to below. T is the sample time, and F is here in the general case called Ad, and G is Bd.

Continuous time model: ˙

x(t) = Acx(t) + Bcu(t)

y(t) = Ccx(t)

This gives the discrete time model:

x(k + 1) = Adx(k) + Bdu(k) y(k) = Cdx(k) where Ad= eAcT Bd=   T Z τ =0 eAcτ  Bc Cd= Cc (2.7)

The first order approximation of the above, gives Ad and Bd as:

Ad≈ I + AcT Bd≈   T Z τ =0 (I + Acτ )dτ  Bc= BcT + AcBcT2 2 (2.8)

2.4

Quadratic Programming

(22)

10 Theory

To calculate the future control signals u(k), ..., u(k + N − 1), while minimizing deviation from the reference states and changes in the control signals, leads to the following MPC problem: min u∈U N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − u(k + j − 1) 2 Q2 (2.9) subject to x(k + 1) = F x(k) + Gu(k) y(k) = Cx(k) u ∈ U (2.10)

Where N is the prediction horizon and Q1and Q2are diagonal weight matrices

of sizes nx× nxand nu× nu respectively.

The constraints on u have the form umin≤ u(k) ≤ umax.

2.4.1

Matrix Definitions

In this section the matrices, used for describing the quadratic programming prob-lem, are defined. The control signals, the states and the outputs for the prediction horizon are included in the following matrices:

U =      u(k) u(k + 1) .. . u(k + N − 1)      , X =      x(k + 1) x(k + 2) .. . x(k + N )      , Y =      y(k + 1) y(k + 2) .. . y(k + N )     

The matrix C that gives the relation from future states to future outputs are used to define C: C =      C C . .. C      which gives Y = CX

The definition of future states, Equation 2.6, repeated gives: X = F x(k) + GU where F =      F F2 .. . FN      , G =      G 0 . . . 0 F G G . . . 0 .. . . .. . .. ... FN −1G . . . F G G     

(23)

2.4 Quadratic Programming 11

The weight matrices, Q1and Q2are used to define the block diagonal matrices:

Q1=      Q1 Q1 . .. Q1      , Q2=      Q2 Q2 . .. Q2     

The future references are summarized in the vector R:

R =      r(k + 1) r(k + 2) .. . r(k + N )     

The part in the MPC minimization problem penalizing changes in u, if this is to be used, could be written on the following vector form:

     u(k) − u(k − 1) u(k + 1) − u(k) .. . u(k + N − 1) − u(k + N − 2)      =      I −I I . .. . .. −I I      U −      u(k − 1) 0 .. . 0      = ΩU − δ

2.4.2

The Quadratic Programming Problem Formulation

The MPC minimization problem can now be formulated as a quadratic problem. If the cost function is as in Equation 2.9 the following is obtained:

min u∈U N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − u(k + j − 1) 2 Q2 = (C(F x(k) + GU ) − R)TQ1(C(F x(k) + GU ) − R) + (ΩU − δ)TQ2(ΩU − δ)

Which is rewritten as:

RTQ1R + (F x(k) + GU )TCTQ1C(F x(k) + GU ) − 2RTQ1C(F x(k) + GU )+

+δTQ2δ − 2δTQ2ΩU + UTTQ2ΩU

where the second term (F x(k) + GU )TCTQ

1C(F x(k) + GU ) = (F x(k))TCTQ1C(F x(k))+

+UTGTCTQ

1CGU + 2(F x(k))TCTQ1CGU

The terms (F x(k) + X0)TCTQ1C(F x(k)), RTQ1R and δTQ2δ are independent

of the optimization variables and are removed from the minimization problem, which now looks like:

UT(GTCTQ

(24)

12 Theory

Division by 2 gives the following QP problem formulation: min U 1 2U THU + fTU subject to AU ≤ b where H = GTCTQ 1CG + ΩTQ2Ω f = GTCTQ 1(C(F x(k)) − R) − ΩTQ2δ

To calculate the future control signals u(k), ..., u(k + N − 1), minimizing devi-ation from the reference states and from the reference control signals instead, the cost function would have the appearance as in Equation 2.11.

minu∈U N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − uref(k + j) 2 Q2 (2.11)

The future references are summarized in Uref:

Uref =      uref(k) uref(k + 1) .. . uref(k + N − 1)     

The Quadratic Programming problem formulation would then be:

min u∈U N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − uref(k + j) 2 Q2 = (C(F x(k) + GU ) − R)TQ1(C(F x(k) + GU ) − R) + (U − Uref)TQ2(U − Uref)

which would result in the QP form (equivalent to above): min U 1 2U THU + fTU subject to AU ≤ b where H = GTCTQ 1CG + Q2 f = GTCTQ1(C(F x(k)) − R) − Q2Uref

(25)

2.5 Representation of Obstacles 13

2.5

Representation of Obstacles

Obstacle avoidance can either be implemented using constraints for the states. These can be seen as "hard constraints" since a solution where the aircraft crossed the forbidden area can not be tolerated. Another way of implementing obstacle avoidance could be to set "soft constraints" instead, which means that it is included in the cost function, and penalized very hard. This way, a solution might be given to fly into a dangerous area. In this master thesis hard constraints are chosen for obstacle avoidance, but one could also consider to mix this with soft constraints, for example if the terrain was included in the avoidance procedure. In that case the terrain could be included using hard constraints, whilst dangerous areas were penalized in the cost function. If for example penalty for fuel consumption was also added, there would be a trade-off between re-planning a long route to avoid a dangerous area, in relation to the fuel needed for the re-planned route.

(26)
(27)

Chapter 3

Algorithms

In this chapter the theory from Chapter 2 is applied on the actual problem, and for example, the cost function and obstacle avoidance are described here. The summarized MPC formulation is given in Section 3.5.

3.1

The Model

In this section the model used in this implementation is described. The model used is a polar point model in two dimensions, x and y are cartesian coordinates. (The altitude is assumed constant.) The nomenclature is presented in Table 3.1.

˙ xa(t) = va(t)cos(αa(t)) ˙ ya(t) = va(t)sin(αa(t)) ˙aa(t) = 0 (3.1) xa Aircraft position in x ya Aircraft position in y xo Obstacle position in x yo Obstacle position in y va Aircraft speed vo Obstacle speed aa Aircraft acceleration ao Obstacle acceleration

αa Aircraft heading angle

αo Obstacle heading angle

d Distance or radius, from (xo, yo)

Table 3.1. Nomenclature.

(28)

16 Algorithms x1 Aircraft position in x direction

x2 Aircraft position in y direction

x3 Aircraft altitude

x4 Aircraft time

x5 Obstacle position in x direction

x6 Obstacle position in y direction

x7 Obstacle altitude

x8 Obstacle time

x9 Obstacle speed

x10 Obstacle acceleration

x11 Obstacle heading angle

x12 Obstacle angular velocity

u1 Aircraft speed

u2 Aircraft heading angle

u3 Constant = 1, for the constants

from the linearization

Table 3.2. Definitions of states and control signals. x and y are Cartesian coordinates.

The same model is used for the obstacles movement, with constant speed and heading angle assumed.

˙ xo(t) = vo(t)cos(αo(t)) ˙ yo(t) = vo(t)sin(αo(t)) ˙ao(t) = 0 (3.2)

With the speed and heading angle as controllable inputs for the aircraft, and as states for the obstacle, the complete model becomes the following, where the states and control signals are defined as in Table 3.2.

˙ x1(t) = u1(t)cos(u2(t)) ˙ x2(t) = u1(t)sin(u2(t)) ˙ x3(t) = 0 ˙ x4(t) = 1 ˙ x5(t) = x9(t)cos(x11(t)) ˙ x6(t) = x9(t)sin(x11(t)) ˙ x7(t) = 0 ˙ x8(t) = 1 ˙ x9(t) = x10(t) ˙ x10(t) = 0 ˙ x11(t) = x12(t) ˙ x12(t) = 0 (3.3)

(29)

3.1 The Model 17

If more than one obstacle is modeled, eight new states for that obstacle are added (in the same order as the first obstacle). The "time" state is only used to save the time points for each position, to be able to give new reference speeds for the new, re-planned path. Since the model for the obstacle is a constant velocity and constant heading angle model, the states for acceleration and angular velocity might be excluded. However, here they are merely set to zero, to keep the flexi-bility in the model description.

The model is linearized in each time step, around (¯x, ¯u), as described in Section 2.3.

˙

x1(t) = ¯u1u¯2sin(¯u2) + u1cos(¯u2) − u2u¯1sin(¯u2)

˙

x2(t) = −¯uu2cos(¯u2) + u1sin(¯u2) + u2u¯1cos(¯u2)

˙

x3(t) = 0

˙

x4(t) = 1

˙

x5(t) = ¯x9x¯11sin(¯x11) + x9cos(¯x11) − x11x¯9sin(¯x11)

˙

x6(t) = −¯xx11cos(¯x11) + x9sin(¯x11) + x11x¯9cos(¯x11)

˙ x7(t) = 0 ˙ x8(t) = 1 ˙ x9(t) = x10(t) ˙ x10(t) = 0 ˙ x11(t) = x12(t) ˙ x12(t) = 0 (3.4)

Formulated as ˙x(t) = Ax(t) + Bu(t), A and B are given by:

A =                     0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 cos(¯x11) 0 −¯x9sin(¯x11) 0 0 0 0 0 0 0 0 0 sin(¯x11) 0 x¯9cos(¯x11) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0                    

(30)

18 Algorithms B =                    

cos(¯u2) −¯u1sin(¯u2) u¯1u¯2sin(¯u2)

sin(¯u2) u¯1cos(¯u2) −¯u1u¯2cos(¯u2)

0 0 0 0 0 1 0 0 x¯9x¯11sin(¯x11) 0 0 −¯x9x¯11cos(¯x11) 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0                    

The discretization is then done according to Section 2.3.1, which would give the matrices F and G.

3.2

The Cost Function

The problem is to follow a reference towards a point in space, while avoiding an obstacle using constraints. The cost function that is defined for this purpose pe-nalizes deviation from the reference path, as well as deviation from the reference control signals. The reference control signals are defined by calculating a new speed to reach the goal point at the given time, and the reference angle is defined as the heading angle needed to reach the goal point in a straight line from the current position. A point can be reached in different ways, and a unique solution is not guaranteed. Therefore, it is also necessary to steer the solution (the control signals) for reaching the next reference point, towards the desired solution.

The cost function used is given by Equation 3.5.

N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − uref(k + j) 2 Q2 (3.5)

3.3

The Quadratic Programming Problem

When Yalmip (with Gurobi) is used the problem is re-formulated to suit a method automatically, but the theory behind how the quadratic programming problem would look like if it was to be formulated manually, is given in Section 2.4.

3.4

Obstacle Representation

(31)

3.4 Obstacle Representation 19

The way for representing the obstacle or area to be avoided also affects the constraints in the optimization problem. The forbidden area around the obstacle can be represented by a circle, as depicted in Figure 3.1, where the aircraft must be outside the circle given by

p

(xa− xo)2+ (ya− yo)2≥ d

This state constraint is nonlinear, and since the problem is also a non-convex

d xa,ya

xo,yo

Figure 3.1. The obstacle and its "forbidden" circle.

quadratic problem (the area outside the forbidden area is non-convex), it is hard to solve. Therefore this circle is approximated with linear constraints instead. Two different approaches have been explored here to obtain linear constraints, as stated in Section 3.4.1 and Section 3.4.2. One of them, see Section 3.4.1, is a variant of hybrid-MPC, where binary variables are introduced to be able to alternate between different constraints. This results in a Mixed Integer Quadratic Programming problem, since there are also integer variables in the control problem.

3.4.1

Hyperplanes with Binary Variables

Here a number, nc, of hyperplanes are used to define the "forbidden" areas. This is

illustrated in Figure 3.2. (In the figure ncis 6). This approach results in a number

of linear "or-conditions", where at least one condition has to be fulfilled at each time point, and is implemented using binary variables. The aircraft is outside the area if at least one of the or-conditions is satisfied, that is, that at least one of the binary variables δc is one (see below), which makes the corresponding condition

(the hyperplane) "active". For example, the position where the aircraft is located in Figure 3.2, δ1and δ6 are one, and the others are zero.

When four planes are used the obstacle is represented by a square instead, see Figure 3.3. This approximation has been used in the implementation. (The number of constraints and binary variables grows rapidly as the approximation becomes finer.)

(32)

20 Algorithms δ1 δ2 δ3 δ4 δ5 δ6 xo,yo xa,ya d

Figure 3.2. Approximation using nc numbers of hyperplanes.

d xa,ya xo,yo δ1 δ2 δ3 δ4

Figure 3.3. Approximation using four hyperplanes.

variable respectively: xa− xo≥ d ⇔ (−xa+ xo+ d ≤ 0) ↔ (δ1= 1) or xo− xa ≥ d ⇔ (xa− xo+ d ≤ 0) ↔ (δ2= 1) or ya− yo≥ d ⇔ (−xy+ yo+ d ≤ 0) ↔ (δ3= 1) or yo− ya ≥ d ⇔ (ya− yo+ d ≤ 0) ↔ (δ4= 1) (3.6)

The or-constraints above are implemented as follows, where  is a small threshold for when the constraint is violated, and m is a small scalar (a large negative scalar),

(33)

3.4 Obstacle Representation 21

M a large positive scalar.

−xa+ xo+ d ≤ M (1 − δ1) −xa+ xo+ d ≥  + (m − )δ1 xa− xo+ d ≤ M (1 − δ2) xa− xo+ d ≥  + (m − )δ2 −ya+ yo+ d ≤ M (1 − δ3) −ya+ yo+ d ≥  + (m − )δ3 ya− yo+ d ≤ M (1 − δ4) ya− yo+ d ≥  + (m − )δ4 (3.7)

Since the aircraft can not be on two sides of the square at the same time, δ1

and δ2 can not be active at the same time, and not δ3 and δ4 either. Therefore

the following also holds:

δ1≤ 1 − δ2

δ2≤ 1 − δ1

δ3≤ 1 − δ4

δ4≤ 1 − δ3

(3.8)

At least one of the constraints has to be active, which gives

δ1+ δ2+ δ3+ δ4≥ 1 (3.9)

3.4.2

Obstacle Avoidance with a Single Hyperplane

Another way to implement the obstacle avoidance constraint is to use a single hyperplane that is not to be crossed. This hyperplane is calculated at each time point and is estimated for future states during the prediction using the reference positions. An illustration of this is given in Figure 3.4. In the picture the hyper-planes for two points in time are depicted. The constraint for the states is given by the blue line in the picture. The lines equation is

L = ya,ref − yo,ref xo,ref− xa,ref  · t +xo,ref− d · cos(β) yo,ref− d · sin(β) 

where the angle β is defined as in Figure 3.4.

Figure 3.5 illustrates the same concept, but with a stationary obstacle and a prediction horizon N = 2. The colored dots are predictions for the three different points in time (green, orange and purple correspond to the different points in time), and the lines in the same colors are the hyperplanes for each prediction. The gray symbol is the goal point, and the gray line is the original path.

The obstacle avoidance constraint is formulated by defining the vectors:

¯

a =xa− xd ya− yd



(34)

22 Algorithms d xa,1,ya,1 xo,2,yo,2 xa,2,ya,2 d xo,1,yo,1 xd,1,yd,1 xd,2,yd,2 β1 β2 β1 β1 Time point 1 Time point 2

Figure 3.4. Obstacle avoidance using one hyperplane (the blue, dashed line).

Figure 3.5. Obstacle avoidance using one hyperplane, three different time points, sta-tionary obstacle and prediction horizon N = 2.

¯ r =xd− xa,ref yd− ya,ref  (3.11) xd yd  =xo,ref− d · cos(β) yo,ref− d · sin(β)  (3.12) As a result the constraint is

¯

a · ¯r ≤ 0 (3.13)

(35)

3.5 The MPC Formulation 23

¯

a · ¯r ≥ 0.

The constraint and the definitions of the introduced variables are illustrated in Figure 3.6. xa,ya d xo,ref,yo,ref xd,yd β r aa⋅r≤0 xa,ref,ya,ref

Figure 3.6. Obstacle avoidance using one hyperplane: definition of the avoidance constraint.

3.5

The MPC Formulation

The MPC formulation is given by minimizing the cost function subject to the constraints, that are given by the model, the obstacle avoidance constraints and also for example the constraints on the control input. This is illustrated in Figure 3.7. As a result from Section 3.1, 3.2 and 3.4 the MPC formulation is summarized in Section 3.5.2 and Section 3.5.1, depending on the obstacle representation.

3.5.1

Using the Obstacle Avoidance Method with Binary

Variables

The MPC formulation using the method in Section 3.4.1 is:

min u∈U,δi N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − uref(k + j) 2 Q2 (3.14)

Subject to model constraint:

x(k + 1) = F x(k) + Gu(k)

(36)

24 Algorithms ... Cost function Constraints Obstacle avoidance Alt. 1 ... Model ... Alt. 2 ... ... Performance The MPC formulation

Figure 3.7. Illustration of the MPC formulation.

And subject to constraints on the control input:

uminspeed≤ u1(k) ≤ umaxspeed uminangle≤ u2(k) ≤ umaxangle u3(k) = 1 δ1≤ 1 − δ2 δ2≤ 1 − δ1 δ3≤ 1 − δ4 δ4≤ 1 − δ3 δ1+ δ2+ δ3+ δ4≥ 1 (3.16)

(37)

3.5 The MPC Formulation 25

And subject to constraints on the obstacle avoidance: −xa+ xo+ d ≤ M (1 − δ1) −xa+ xo+ d ≥  + (m − )δ1 xa− xo+ d ≤ M (1 − δ2) xa− xo+ d ≥  + (m − )δ2 −ya+ yo+ d ≤ M (1 − δ3) −ya+ yo+ d ≥  + (m − )δ3 ya− yo+ d ≤ M (1 − δ4) ya− yo+ d ≥  + (m − )δ4 (3.17)

3.5.2

Using the Obstacle Avoidance Method with a Single

Hyperplane

The MPC formulation using the method with in Section 3.4.2 is:

min u∈U N X j=1 y(k + j) − r(k + j) 2 Q1+ N −1 X j=0 u(k + j) − uref(k + j) 2 Q2 (3.18)

Subject to model constraint:

x(k + 1) = F x(k) + Gu(k)

y(k) = Cx(k) (3.19)

And subject to constraints on the control input: uminspeed≤ u1(k) ≤ umaxspeed

uminangle≤ u2(k) ≤ umaxangle

u3(k) = 1

(3.20)

And subject to constraints on the obstacle avoidance: ¯ a =xa− xd ya− yd  ¯ r =xd− xa,ref yd− ya,ref  xd yd  =xo,ref− d · cos(β) yo,ref− d · sin(β)  ¯ a · ¯r ≤ 0 (3.21)

(38)
(39)

Chapter 4

Results

This chapter is divided into two parts. Part one presents the results from the in-terviews with the pilots, and suggestions for improvements in the mission planning system (Section 4.1), and part two describes the re-planning system (section 4.2).

4.1

Suggestions for Improvements in the Mission

Handling System

In this section the suggestions on how to improve the mission handling system are presented. Five pilots, who use the system and have deep knowledge about its advantages and drawbacks, were interviewed. Three of the pilots were from Saab, one was from FMV (Försvarets Materialverk) and one was from TUJAS (Taktisk Utveckling JAS). The interviews were conducted in the form of discussions about the mission handling system and its advantages and limitations. In one of the in-terviews two pilots where present at the same time which contributed to a deeper discussion, when different points of views could be emphasized.

The pilot’s opinions have been used as the base to compile suggestions on functions for improvements that could be implemented in the mission handling system. The main focus has been on the functionalities in the mission planning system in the Gripen aircraft but the discussions have also concerned the ground supporting system (MSS: Mission Support System).

4.1.1

Reduced Number of Different Types of Points

The general opinion among the pilots was that the system works rather good today, which could be the reason why nothing is done to re-do the whole system, since this would be a lot of work. Many of the solutions could though, in the opinions of the pilots, be done easier, better and more efficient. The first thing that came up is that there are too many different types of points used in the system, but at the same time they are too few, since the points are stiff and does not allow enough

(40)

28 Results

flexibility. When this system was created, not so many different types existed and this was not a problem when the planning was (and still is) done by choosing a type of point, and creating and adding it to a mission route. Now however, the number of points has increased a lot but the old system of handling them is still used. When a new type of point is needed it is simply added to the old system and increases the complexity more and more. What could be done now, when the number of points has increased to a nearly unmanageable quantity, is to generalize the way to handle the points. The following is a suggestion for how this could be done:

• The points could be handled in the same way, independent of what type of point it is. When a point is created, it is assigned a position (longitude, latitude, elevation), this could be the first attribute in the attribute vector that every point could have (see below). After the point has been created is when it is decided what type of point it should be. Perhaps it could be a waypoint by default, that should just be passed by, and then it can be given "tasks" as attributes to give it a specific identity.

• The point could look like something like the following:

POINTNAME[position(latitude, longitude, elevation),

altitude(reference, lower bound, upper bound), time(reference, lower bound, upper bound), speed(reference, lower bound, upper bound), ..., Reminder text] where POINTNAME is possible to change, but is given a default name, for example the number it gets in the mission route when it is created. In that way a route is first created, and then points are created and added directly to a specific route, but it must also be possi-ble to create points that are not part of a mission route (like marker points). All attributes might not have to be specified, if there for example are no altitude or speed limits, or a reminder text is not needed.

Since it is not possible to calculate with both reference, lower and upper bounds on the attributes, only one argument could be given instead (refer-ence ...). This would mean that for example the time- and fuel calculations can be done using these values. If three values are given: the upper and lower bounds could be used to include absolute constraints for speed, altitude and so on, whilst the reference value is to be used in the calculations.

The reference altitude and speed are for flight altitude and aircraft speed, and should hold for the next polygon (it is not the height of the point, that is the elevation). When the point is changed from being a waypoint other necessary compulsory attributes might occur, like target specific data if it is a target point, and if it is an air refuel point time for refueling might be a compulsory attribute. This idea, to handle the points in the same way independent of what type of point it is, could make it easier and more intuitive to create points. Even though it could be convenient to automatically assign a point attributes by firstly decide the point type (before creating it) it will not be possible to have a button for every point type when the numbers grow. That is why it would be more intuitive to do

(41)

4.1 Suggestions for Improvements in the Mission Handling System 29

it in the other order, to first create the point and then decide the point type and assign it attributes.

To get a good overview of the mission route it is good that the point desig-nation is visible on the map, (as it is now, when the abbreviation for the point type is used together with the number). This advantage is something that might disappear when all points are "equal", but the graphical representation could be solved by displaying them differently depending on the attributes, or if the point is a waypoint from the beginning and then changed into another point type the same concept can be used as before. However, this change in the ways to handle the points might come with a lot of work, but will probably make it a whole lot easier for the pilots when the system expands even more in the future.

4.1.2

Continuous Curve

A function that two of the pilots desired was to be able to see the actual flight path, the bowed path and not only the straight polygon legs between the mission points. They suggested that when planning in the MSS you could insert points to get a flight route, for example when flying between mountains, but these points should only be used to bend the curve right and then it would be continuous, with some sort of markings for when to turn, see figure 4.1 for illustration.

W1 W2 W3 T T L0 L0

(42)

30 Results

To see the actual flight path might be very useful if it was possible. The path used in the time- and fuel calculations does not consist of the straight polygon legs. The new representation given to the pilot could be more alike how the fuel calculations are done, so that the pilot can see how the aircraft calculates the fuel, for example for turns. If the pilots could see how the aircraft calculate the fuel, it is easier for them to decide if the calculations correspond to how he/she, as an individual, plans to fly, rather than as it is now, when the pilot does not have access to the aircraft’s "calculation path".

4.1.3

Flexibility

Even though all pilots agree on that there are to many different types of points, they also say that there are to few, since the points available are somewhat limited in their use. One functionality that is desired is that in the aircraft, you can not choose whether to turn before or after a point, and this has impact on the time-and fuel calculations. In the aircraft features like this are sttime-andardized time-and not possible to change. Another thing that influences these calculations is the rising profile (how the aircraft should ascending), which is also not possible to specify in the aircraft. For one thing, the aircraft assumes you always rise from a point and always descend to a point, something that should also be possible to choose in the aircraft. The reason for this is that the fuel calculation system (for example) must use one way to do the calculations, however, if the pilot is forced to use another flight profile (for example if he needs to descend as fast as possible) the calculations will not correspond to how the pilot flies at that moment.

All pilots agree on that even though they want more flexibility in the functions that can be used in the aircraft, they must not be too complicated to use, with for example a lot of parameters to be set. This can be solved by giving these parameters default values, but make them able to change, for example the turns could be given a specific appearance, but this should be possible to be changed by the pilot. The functionality of choosing G-force for turnings is available in the MSS, but not in the aircraft, which does the calculations for turns depending on the turn angle. One suggestion is that the same specifications should be used in the two systems, or else the pilots should be able to specify the look of the turn in the same way in the aircraft, as it can be done in the MSS. (The pilot could for example specify that he/she will turn with 5G for a turn).

However, not all pilots agreed on that the functionality of being able to change rising profile in the aircraft was needed: one said that if there is an emergency and the pilot needs to descend fast he/she will not care about changing this in the aircraft anyway. The same pilot stated that all flexibility from the MSS was not needed in the aircraft since that would give the pilots even more functionalities to learn. This holds for specifying the G-force in turnings also, the interviewed pilot said that all pilots will fly differently anyway, and probably not care about the small differences in the fuel calculations that this setting would bring.

(43)

4.1 Suggestions for Improvements in the Mission Handling System 31

Sometimes a mission route needs to be edited in the aircraft, and a desired functionality is to be able to edit in one route in the aircraft, while having another one active, instead of as it is now, when only the active route can be edited.

4.1.4

More Efficient Use of the AR Point

One thing in today’s system that could be improved is the handling of the AR point, which is for Air Refueling. As it is now, that point is always inserted last in a mission route, but the pilots would like the AR point to be more flexible. They want to be able to plan a mission with an AR point in it, instead of in the end of the mission. The AR point should be possible to assign a time (for example 8 minutes, the time they will have to refuel), and then the mission should continue, and be planned with calculations depending on the time that was assigned to the AR point. In this way it is easier to get an overview of the whole mission, and possible to plan a way home after air refueling.

4.1.5

Flexibility in the Fuel Calculations

One functionality that could be implemented to get more flexibility in the fuel calculations is to be able to choose how the remaining fuel to a landing base is calculated. One way these calculations can be done is to first calculate the fuel needed to get to the main landing base (L1) and then to the secondary landing base (L2). In this way the calculations are done assuming that the pilot tries to land at landing base L1 first, before he/she will try at landing base L2, and more details are considered. Another way to calculate the fuel is to do it directly from the current position to the landing base, and not assuming another path to try at another landing base first. The differences are illustrated in Figure 4.2.

A suggestion is that it should be possible to choose how the calculations are done. This could be specified by giving the bases some sort of "flag" for how to calculate the fuel to them, and for long flights alternating landing bases might be specified on the way, for emergency landing, called "en route alternatives". This could be useful for long flights especially. See Figure 4.3 for an illustration.

Another desired function is a graphical clarification of how the fuel for the route is calculated in the aircraft. See for example Figure 4.4. If M2 (outside the route) is chosen as destination, and the pilot steps through the target category, fuel might be calculated from the OR point, and thereby from the current position back to the OR point, and then forward in the route. This might give a warning for low fuel, and is the reason why a clarification of the point where fuel is calculated from is desired.

Some of the pilots think that the MSS have many functions that the aircraft lacks, like the possibility to choose rising profile, but it is also the other way around. Some things must be done in the aircraft, like some personal adjustments that can not be done in the MSS. Naturally, these systems can not be exactly

(44)

32 Results L1 L2 L2 L1 main alternate

Figure 4.2. Illustration of two ways to calculate fuel to landing bases.

the same since the ground supporting system can have advantages in comparison to the aircrafts system. Even though there are some functions that the aircraft could have that also the MSS has, one must be careful not to make the system in the aircraft to complicated and with too much automation to be manageable and understandable. Some of the pilots think that it is more important to have flexibility in the functions in the MSS, and the aircraft does not need all flexibility functions, with for example the possibility to choose rising profile, since all pilots fly differently anyway, so it is too difficult to have something that suits all pilots.

4.1.6

Reconnaissance

A little more flexibility in the reconnaissance is desirable. The mission should be the important thing when planning, and the pilots want to be able to say "look closer at this" and then get the information on how to fly to accomplish that, rather than define how to fly first. That is, the mission should be the important factor and the flying the tool to accomplishment. This could for example be to define what you want to look at and then the altitude, and so on, is calculated to achieve that.

One pilot thought that the Reconnaissance points (R) had rather limited use, and that R0-points together with an OF(R)-point are used more often. He wanted to be able to use the R-points as pinpoints instead, and use them to photograph point goals. This can be solved today too, using other methods like marker points

(45)

4.1 Suggestions for Improvements in the Mission Handling System 33

”En route-alternative”

”En route-alternative” ”En route-alternative”

L1

L2 When passing these lines it is

closer to the next emergency landing base (”en route alternative”), and the calculation is therefor done directly to the next one.

From here the fuel calculations can be done first to L1 and then to L2.

Figure 4.3. Illustration of how to alternate between the ways to calculate fuel with "en route" alternatives. OR W3 W2 L0 L1 W6 W5 M1 M2 L2 R1 W4

Figure 4.4. A route example, when the mission fuel is calculated from the current position back to the OR point, an then forward in the route. (This could be clarified graphically).

(46)

34 Results

One pilot wished that the Reconnaissance points, and their offset points, were excluded from the target category, so that there are fewer points to step through in that category. This category is considered too long, and the pilot was of the opinion that the R, OF(R) and CAP points were better to be excluded from this category (and held in another one), to make the target category easier and faster to step through on the control panel.

4.1.7

Area Points

Area points are used to define areas, and one of the pilots could find much use for areas, but the problem is that one can only have a limited number of areas, that is too small to fill the need. Area points could be used for drawing obstacles, and then for example an audio warning could be given for when you are about to fly into something. Another functionality that is desired for the areas is to connect a reminder text to an area, as you can do now with reminder texts to points. A larger number of allowed area points is also desired, since you can not draw a whole airspace with the current amount.

One pilot wanted to be able to load areas in a flight database so that the aircrafts can be given the same updates. As it is now changes are very complicated to do in the FLD, (Field Loadable Database, a civil navigation database), which is necessary since there are many things that are not allowed to be changed, but the military airspace is often changed, and then it is important that the database is updated, so that changes are loaded directly in to the aircraft.

4.1.8

Flight Corridors

The flight corridors are desired to look a bit different when displayed. Now they look as in Figure 4.5, but one pilot wanted to see the width of the corridor and to be able to change it, as in Figure 4.6. Even better would be if it was possible to do longer corridors, with for example up to five waypoints in it. The altitudes could still be shown in the beginning and end (in the middle it would probably be hard to see them). See Figure 4.7 for an illustration. As it is now the arrows sometimes cover more important things to see: they are set in the display, so that when you zoom in they become larger, which is not necessary.

4.1.9

Support for Landing

Two of the pilots wanted an automatic function for emergency landing, that au-tomatically gives the optimal path to the nearest landing base instead of manual re-planning in case of an emergency (you simply press a button "Emergency land-ing"). Another pilot also wanted some kind of support for emergency landing, and suggested that in case of emergency L1 could automatically be set as the closest landing base. There was another pilot rather skeptical to this, since it is not defi-nitely possible to always choose the nearest landing base and it could be difficult for the algorithm to know which landing base to choose, although he could imagine

(47)

4.1 Suggestions for Improvements in the Mission Handling System 35

8

12

Figure 4.5. Flight corridor today.

8

12

Figure 4.6. Desired display of flight corridors.

8

12

Figure 4.7. Functionality of using several waypoints in one corridor.

it to be useful in an extreme case of emergency. However, he said that it would require good databases that are not yet available today. He also suggested that it in some cases would be useful with some sort of support for optimal landing without creating a landing polygon, for example to fly at optimal height for as

(48)

36 Results

long as possible and then use a landing profile.

4.2

The Route Re-planning System

In this section the results from test scenarios with the MPC controller is presented. The design parameters N (prediction horizon), Q1(penalty for deviation from the

reference) and Q2 (penalty for deviation from reference speed and angle) have

been varied and the results are compared below.

4.2.1

Test Scenarios

The test scenarios that have been used in Section 4.2.3 to illustrate the MPC con-troller’s performance are described in text and in the figure captions. The MPC controller have been tested with different prediction horizons, different penalty matrices, different obstacle representations and different obstacles (moving obsta-cles, stationary obstacles and multiple stationary and moving obstacles). In the results a scenario with one stationary and two moving obstacles is presented.

4.2.2

The Approximation Algorithm

The path suggested by the MPC controller consists of many waypoints and can not be presented directly. Therefore the new waypoints are reduced by taking the proposed path and drawing lines between the waypoints if it is possible. This ap-proximation algorithm will at least give the same solution obtained from the MPC controller, and if possible reduce the number of waypoints used. Pseudo code for this "approximation algorithm" is found below, in Algorithm 1. The input to this algorithm is the path obtained from the controller, and the obstacles path, and output is a new path with hopefully fewer waypoints.

It is assumed that it is possible to draw a straight line between two adjacent points in the path, without crossing any obstacles. (Note: This might not always be the case since the controller returns valid points only, not continuous lines between them, and if the sample time is to large and the resulting valid points lie on the edge of the forbidden area some skittering might occur. This, however, has been neglected.)

4.2.3

Results from the Test Scenarios

In this section the results from test runs are presented, and the controller’s per-formance for different prediction horizons and penalty for reference deviation is shown.

The scenario in the figures shown here is three obstacles. One of the obstacles is stationary, in the point (1000, 480), and two are moving with constant speed and heading angle from point (850, 10) and point (3100, 2500) respectively. The red

References

Related documents

This is valid for identication of discrete-time models as well as continuous-time models. The usual assumptions on the input signal are i) it is band-limited, ii) it is

The Board of Directors and CEO of Entraction Holding AB (publ), corporate registration number 556367-2913, hereby present their report on operations for the

Th e Group’s earnings are aff ected by changes in certain key factors, as reviewed below. Th e calculations proceed from the conditions prevailing in 2006. Th e eff ects

Efficiency curves for tested cyclones at 153 g/L (8 ºBé) of feed concentration and 500 kPa (5 bars) of delta pressure... The results of the hydrocyclones in these new

The goal for the diploma work is to give overall proposals and a concrete plan proposal, based on scientific investigations and analysis of the Hengelo inner-city strengths and

If you release the stone, the Earth pulls it downward (does work on it); gravitational potential energy is transformed into kinetic en- ergy.. When the stone strikes the ground,

Respondent A also states that if a current client makes changes in the ownership, a new credit assessment process will be initiated and if the bank does not get to know

Genom att överföra de visuella flöden av bilder och information som vi dagligen konsumerar via våra skärmar till något fysiskt och materiellt ville jag belysa kopplingen mellan det