The proposed approach is used to identify challenging situations (specifically, mid-air collision situations) for SVO. In this section, some key implementation details are introduced.
As a preliminary demonstration and evaluation, for simplicity, the simulations were confined to two-UAV encounters, where the two UAVs run the same SAA algorithm. Some dynamic constraints for the UAVs are shown in Table 4-1, which were converted from the performance data of Global Hawk given in [7]. For SVO, when in the “avoid” mode, it is desirable for the host UAV to select a new velocity vector outside its velocity obstacle induced by others but still obey the right-of-way rules. However, considering the dynamic constraints, it was assumed that each UAV avoids others only by turning right at a rate of 2.5deg/s. It means that during one simulation run, the magnitude of each UAV’s velocity vector keeps constant, and only the direction of the velocity vector will change. Note that, between simulation runs, the magnitude of velocity also varies.
Table 4-1 UAV performance limits.
Max speed 92.6 m/s Min speed 51.4 m/s
Normal speed 77.2 m/s Max turning rate 2.5 deg/s
A. Agent-Based Simulation
MASON27, an open source agent-based simulation platform in Java, was used as the agent-based
simulation framework. In a typical agent-based simulation, there are three core elements: agents, environment, and their interactions. The agents in our simulation are UAVs with SVO as the collision avoidance algorithm. They have attributes, such as maximum and minimum speed, and maximum turning rate, and they also have behaviours, such as sensing other UAVs and avoiding them. The environment in our simulation is simplified as a 2-D rectangular flight area in the horizontal plane. The size of the flight area was set according to the detection range for the “Traffic Advisory (TA)” of the TCAS (i.e. 40 sec ahead of the CPA) so that it is large enough to accommodate the collision avoidance simulations. Apart from UAVs, some other entities in the environment are waypoints for navigation, and the start point and target of each UAV. The interactions between the UAVs are only via the SAA algorithms — explicit communication between UAVs was not modelled. The interactions between UAVs and the environment include UAVs following waypoints and generating new waypoints for collision avoidance.
74
To validate the SVO algorithm, a wide variety of encounters should be simulated and evaluated. An “encounter generator” was developed that can generate three kinds of encounters, each involving two UAVs: (1) head-on encounters, (2) crossing encounters, and (3) overtaking- overtaken encounters. We refer to one of the UAVs as the own-ship and the other as an intruder. Using the “encounter generator”, the intruder's start point, velocity vector, and target can be decided on the premise that the type of the encounter, the own-ship's start point, velocity vector, and target have been fixed. The three encounters are shown in Figure 4-3 and explained as follows:
The head-on encounter is where the own-ship and the intruder approach each other in opposite directions, as illustrated in Figure 4-3(a). The intruder can approach the own- ship from either the left side or the right side with a certain offset.
The crossing encounter is where the own-ship and the intruder approach each other at an encounter angle ranging from 0° (exclusive) to 180o (exclusive) from either the left side
or the right side, as illustrated in Figure 4-3(b). If the encounter angle equals 180o, it is a
head-on encounter without offset. If the encounter angle equals 0°, it is an overtaking- overtaken encounter without offset, which will be discussed next.
The overtaking-overtaken encounter is where the intruder overtakes or is overtaken by the own-ship flying on parallel tracks, as illustrated in Figure 4-3(c). The intruder can overtake or be overtaken by the own-ship from the left side or the right side with a certain offset.
Note that the above definition of encounters is a little different from SVO’s definition of encounter types as illustrated in Figure 4-1. This is mainly because the above definition is convenient to implement. In principle, SVO’s definition could also be used. Here, by using a model different from the model used for system development, it may help to reveal faults neglected by the system development (especially as it is more general than the original as it includes offsets).
75
V
Own-ship Left side
Right side V’ Encounter angle Intruder V Own-ship Left side Right side V’ Intruder V’ V’ Offset Offset V V’ Intruder Own-ship V’ V’ Left side Right side Offset Offset
(a)
(b)
(c)
Figure 4-3 Our definition of three encounter types: (a) head-on; (b) crossing; (c) overtaking-overtaken. Some global agents were utilized to monitor the simulations: a “proximity measurer” measures the nearest distance between the two UAVs in every simulation step and the most dangerous proximity during a simulation run; an “accident detector” monitors the simulations, and logs accidents and terminates a simulation run when an accident happens. These global monitoring agents play a major role in gathering information for computing the fitness function, which was used to guide the search towards increasingly challenging situations.
Note that when using the global agents to monitor the simulations, the distance (d) between two UAVs is defined as shown in Figure 4-4. Here, r denotes the enlarged size of a UAV and is set to
76
be half of radius of the collision volume (rather than a physical UAV). When d is less than or equal to zero, an accident happens and the simulation would be stopped by the “accident detector”.
Figure 4-4 Definition of distance between two UAVs.
As mentioned above, the simulations were configured by a series of parameters, which can be divided into three categories:
Parameters for encounter instances, e.g. the parameter to decide which encounter type should be simulated in a simulation run, and the parameters used to generate an instance of that type;
Parameters for the own-ship, e.g. the own-ship’s target, its speed, and turning rate; Parameters for the intruder, e.g. the intruder’s speed and turning rate.
B. Evolutionary Search
The evolutionary search part of the approach was implemented by using ECJ28, which is a Java-
based evolutionary search library. GA was chosen as the evolutionary search algorithm because of its popularity and the convenience to use it.
The use GA is illustrated in Figure 4-5. First, the initial population is set up with n individuals, with the genome of each representing the settings for the configuration parameters identified above. Then each individual of the population is evaluated by a simulation run, and the fitness of that individual can be calculated. According to the fitness, the selection process (re)sample n individuals from the population, and the selected individuals' genome will be “crossed-over" and mutated. After these genetic operations, the individuals are used to form the next generation of the population, which will replace the old population. This process goes on until it run out of time, or the ideal individual(s) has been found.
77 Individual 1 Individual 2 Individual n Individual 3 Selection Crossover Mutation Fitness Simulation Update Sampled by Evaluated by Referred by
Genetic Algorithm Flow
Out of time or find the ideal Config Para
Fitness
Figure 4-5 GA flow.
There are two typical approaches to select individuals from the old population for further genetic operations (i.e. crossover and mutation): Fit-proportionate Selection and Tournament Selection [104]. In Fit-proportionate Selection, the probability of selecting an individual to be a parent is proportionate to its fitness value. In Tournament Selection, several “tournaments” are run among a fixed size (i.e. tournament size) of individuals chosen randomly from the population. The winner of each tournament (i.e. the one with the best fitness value) is selected. The larger the tournament size, the smaller the chance a weak individual will be selected.
The crossover of genomes involves mixing and matching parts of two old genomes to form new genomes. The Uniform Crossover approach swaps every corresponding gene in the genome with certain probability as illustrated in Figure 4-6 (a). The One-point Crossover approach randomly selects a position for crossover and swaps the genes before that position as illustrated in Figure 4-6 (b), and the Two-point Crossover approach randomly selects two positions and swaps the genes in between as illustrated in Figure 4-6 (c).
78
(b) One-point Crossover
swap
swap
(c) Two-point Crossover (a) Uniform Crossover p
p
p p p p p p p p pp
p
p
Figure 4-6 (a) Uniform Crossover, (b)One-point Crossover, and (c) Two-point Crossover. The mutation of genomes involves modifying each gene in a genome with a certain probability. If a gene is selected to mutate, some noise is applied to the information stored in that gene, or the gene is set to some certain values. If the applied noise is Gaussian noise 𝑁(0, 𝜎2), this type of
mutation is named as Gaussian Mutation. In Gaussian Mutation, if the current value stored in one gene is value, then the new value (𝑣𝑎𝑙𝑢𝑒′) in the mutated gene is defined by equations (4-1) and
(4-2).
𝑣𝑎𝑙𝑢𝑒′= (1 + 𝑟𝑛𝑑) ∗ 𝑣𝑎𝑙𝑢𝑒
(4-1) 𝑟𝑛𝑑 ~ 𝑁(0, 𝜎2)
(4-2) The fitness of an individual was calculated by applying a “fitness function” to it. Defining an adequate fitness function is a crucial task for the successful use of GA, as it will ultimately determine the direction of the search. In our case, a good fitness function should favour those individuals that embody challenging situations, while avoiding premature convergence (i.e. avoiding the population becoming very homogenous too early). Since the main concern of SAA is mid-air collisions, we defined a fitness function based on the nearest distance between the pair
79
of UAVs during each simulation run observed by our “proximity measurer”. More details of the fitness function will be given in Section 4.4.1.C.
Several parameters (e.g. the population size, generations of evolution, crossover type, and mutation probability) are used to configure a specific GA flow. The source code for the experiments presented in the next section as well as the specific values for these GA parameters can be found from