1. Introduction
For more sustainable mobility solutions, the next generation aircraft is expected to reduce
emissions significantly during flights while providing a better overall aircraft performance and
safety [
1
]. In line with this, future intelligent flight systems are required to adapt to varying
conditions, to the system’s dynamics, and to handle faults while keeping the pilot informed.
A fault-tolerant flight path planning system is an essential part of an intelligent flight system.
In addition to increasing fuel eficiency, it is also expected to reduce damage and casualties in
emergency situations caused by unforeseen events, e.g. faulty mechanics or human errors 1.
In the previous work [
4
], an automated flight path planning system was developed to assist
the pilot in a single-pilot ultralight aircraft. The system was implemented using a PDDL+
compatible automated planner [
5
], which uses a forward state-space search and heuristics
capable of coping with non-linear mathematical operations. In this paper, we report an ongoing
work aimed at extending the previous work, by exploring the benefits of the UPF [
6
]. We first
provide a brief summary of the previous work, followed by an overview of the adapted system
nEvelop-O
(J. J. Kiam)
CEUR
Workshop
Proceedings
medical requirements [
3
].
architecture and underline the expected benefits of exploiting the UPF. Subsequently, we discuss
the ongoing progress and challenges faced, alongside with the future work considered.
2. Exploring the UPF for the Flight Path Planning System
(a) Automated fault-tolerant flight path
planning with ENHSP.
(b) A more flexible flight path planning system with
the UPF
The aim of the automated fault-tolerant flight path planning system is to determine a flight
trajectory meant to guide an aircraft (e.g. a single-pilot ultralight in [
4
]) from its current position
to a goal position placed within the vicinity of a safe landing area. This is helpful especially
when the pilot is overwhelmed, typically when an emergency landing is required due to low-fuel
level, or to a mechanical fault. Figure 1a illustrates the architecture adopted in the previous
work [
4
], in which the automated flight-path planning system considers weather information
known at planning time2, the current state (i.e. position and fault detection state variables) of
the aircraft, and the goal position, all encoded as part of the (PDDL+) problem instance. The
aircraft’s physical model is encoded as a problem domain adapted from [
8
]. The ENHSP planner
solver [
5
] is exploited to compute an executable temporal plan =< 0( 0), 1( 1), ⋯ , ( ) >,
with each ∗ representing a set of control parameters, namely the turn rate and the climb rate,
which will be used to predict the sequence of waypoints < 0( 0), 1( 1), ⋯ , ( ) >, setting
therefore a feasible reference trajectory for the autopilot to guide the airplane, in case the pilot
is incapable of steering the aircraft. A learning module built on k-means clustering is part of the
planning system to determine the optimal planning parameters for non-nominal situations (i.e.
emergency landing with low fuel or maneuvering a faulty aircraft) using flight data generated
from flight simulations, for tuning the ENHSP planner solver, as well as for selecting the ranges
of the state variables in the planning problem, in order to simplify the search [
9
].
Nevertheless, there are several shortcomings worth mentioning in the previous works [
4, 9
].
To call the ENHSP planner solver, another bash instance is created within the flight path
planning system, and run as an external process, limiting therefore the interaction with the
planner solver. Furthermore, minimum changes in the problem instance, due to either a new
2The weather information used is from the National Oceanic and Atmospheric Administration (NOAA) [
7
].
goal condition, e.g. if a better landing area is detected, or to minimal changes in the weather
information, the problem domain and instance have to be parsed and grounded entirely, which
can be time-consuming for a more complex problem model. Therefore, we have identified the
UPF as a more compact and eficient framework that can overcome these shortcomings, and
ofer more meaningful extensions to the fault-tolerant flight path planning system.
2.1. The Unified Planning Framework (UPF)
The UPF [
6
] is a collaborative efort under development within the AIPlan4EU project, with the
purpose of providing flexibility in the planning problem definition (similar to Tarski [
10
]) and
making a wide range of planning technologies accessible (similar to Planutils [
11
]), via their
integration as Python libraries within a single framework.
2.2. Benefits of using UPF for the Flight Path Planning System
Based on the published information and objectives of the UPF in [
6
] and [
12
], we identified
some features of the UPF that can be exploited to develop a more flexible and integrated flight
path planning system, of which the architecture is as depicted in Figure 1b. The benefits drawn
from the UPF-based flight path planning system architecture are described below.
Overcoming the shortcomings of the previous work: Without having to invoke an external
bash process, it is more flexible to interact with the planning engines within the same Python
framework, which is particularly useful when we consider a human-in-the-loop planning system,
in which the pilot can modify a solution plan, for example by adding an intermediate waypoint.
In this case, the P l a n V a l i d a t o r can be called programmatically.
A more prominent improvement the UPF will bring forth is the coping with a dynamic
environment, as it allows to change state variables programmatically without having to parse
the entire problem instance completely, reducing thereby the overall computational time. With
this flexible parsing, a partial planning problem containing typically weather data and airspace
constraints can be pre-encoded, later completed by the pilot (with goals or additional constraints),
who interacts with the flight path planning system via a cockpit user interface. Domain-specific
validator can check the pilot’s inputs for conflicts (with the constraints of the existing partial
problem) before including them into the planning problem. Having this implemented, the flight
path planning system will conform with the EASA Roadmap for the use of AI in a cockpit: the
system is pilot-centered, with AI playing an assisting role [
13
].
Other potential extensions: To date, the only planner solver used for the (kinodynamic) flight
path planning problem at hand is ENHSP. The main hindrance in using other planners is the
lack of support for non-linear mathematical operations encoded in the problem domain. With
the parser of UPF supporting the encoding of non-linear mathematical operations, it is likely
that more planner solvers capable of solving this class of problem will be included in the UPF,
leading to the possibility of creating multiple planning instances in parallel for diferent planners
or for diferent heuristics of the same planner, emulating thereby “diverse planning” to obtain
multiple solutions that can be presented to the pilot for assisting him/her in decision-making.
Since the current implementation relies only on one solver (ENHSP), plan repair, although can
be considered, can only be done externally to the AI planning module, and in a “programmatic”
and domain-specific manner, as in [
8
], where partial plans are “stitched” together by adding an
artificial “bridge” to ensure continuity between them. With the UPF, even if the planner solver
does not include plan repair capabilities, another planning engine can be used for repairing a
plan, which is relevant to our use case, given the dynamic environment, e.g. a no-fly-zone is
determined during flight due to detected moving objects nearby (such as drones, cranes, etc.).
The learning module in the previous work was based on an unsupervised learning method,
with the aim to select the set of planning and control parameters to optimize the likelihood of a
safe landing in non-nominal situations. This learning module can be extended to include inverse
reinforcement learning to learn aircraft maneuvers from an experienced pilot in emergency
landing, and use these “pre-learned” maneuvers as actions in the planning problem. Having
planning libraries implemented in Python enables the exploitation of Python libraries such as
scikit-learn [
14
] or OpenAI Gym [
15
] within the same Python-based system.
3. Discussion and Future Work
Having identified the benefits of the UPF for our current flight path planning system that was
developed in Matlab in [
4
] and in C++ in [
8
], we are currently working towards porting the
parser for weather data, the automated encoding of problem models, and the learning module
into Python3. As soon as the integration of PDDL+ syntax and global constraints, which have
been proven to be extremely handy in defining no-fly zones in a compact manner, is realized in
the UPF, the architecture shown in Figure 1b can be fully implemented without much adaptation
and its performance can be compared to the previous work. Subsequently, the improvements
and extension described in Section 2.2 can also be included.
3.1. Future Work to Include Hierarchical Task Network Planning
As pointed out in the “Future Work” of [
6
], hierarchical structures will be added into the UPF,
enabling thereby the solving of Hierarchical Task Network (HTN) planning problems. This will
further benefit the extension of the flight path planning system to an even more versatile flight
management system capable of assisting the pilot with tasks of higher abstraction levels3 while
simultaneously communicating a flight path plan to reach the desired goal location. With this
extension, not only that (high-level) task and motion planning can be supported by the same
framework and communicated to the pilot in a hierarchical manner (that is more comprehensible
for human cognition), plan and goal recognition can also be performed in an automated fashion
using HTN planning engines [
17
], resulting in a close-loop assisting system.