1

UAV Swarm

Jason Hahn, Christopher Peterson, Ryan Downey, Sima Noghanian, Prakash Ranganathan

Electrical Engineering, University of North Dakota

Grand Forks, North Dakota, USA jason.c.hahn@und.edu

christopher.peters.4@und.edu

ryan.downey@und.edu

sima.noghanian@engr.und.edu

prakash.ranganathan@engr.und.edu

Abstract – A swarm is a collection of objects or particles that are in

coordination with each other. The concepts of swarm movement

and communication are applied in a variety of applications such as

traffic control or in military tactics. This project applies swarm

principles to a network of unmanned aerial vehicles (UAVs) in

order to achieve optimal communication between each vehicle and

to lower the amount of energy used to coordinate the movement of

multiple vehicles. A network optimization algorithm has been

developed to work with wireless channel data from Wireless InSite,

a wireless channel modeling software program, to control each

UAV in the swarm network and choose the best wireless

communication channels between UAVs based on characteristics

such as path loss and power received. The results from this

algorithm are implemented in a simulation environment

constructed with OMNeT++, which also provides model

visualization. This model has been evaluated in simulation in two

dimensions on a 120x120 meter grid and is capable of choosing

optimal paths between nodes in the network by comparing channel

characteristics such as path loss and power received.

Keywords – swarm, unmanned aerial vehicle, particle swarm

optimization, wireless channel, network simulation

I. BACKGROUND

In general terms, a swarm is a large group of objects or

particles, with the objects often moving in coordination. This

term originates from biology to describe the behavior of

organisms such as insects, fish, and birds. These animals

organize amongst themselves in order to move fluidly in relative

unison with each other. A simple mathematical model of this

can be produced by having each individual in the swarm follow

three key rules [1]:

The individual will move in the same general direction

as its closest neighbors.

The individual will stay close to its neighbors.

Individuals will avoid collisions with each other.

Inspired by the biological equivalent, systems are being

developed to use swarming principles to simulate an organism’s

collective behavior using robotics. This has been applied in a

number of ways, including for optimizing automobile traffic

control [2] and planetary mapping [3]. Swarm intelligence has

also been applied to the battlefield, in what is called military

swarming. This combat tactic uses fully or semi-autonomous

action units (such as unmanned aerial vehicles (UAVs) or small

infantry units) to attack an enemy in coordination with each

other in order to overwhelm the target [4].

This new project focuses on this idea in a civilian

setting. The goal is to create a simulated model of a swarm of

UAVs to operate in a cooperative setting, and use the properties

of a controlled swarm to find the most efficient channels of

communication between units. The wireless channels are

studied and modeled, and an optimization program has been

created to test the swarm network.

II. SYSTEM DIAGRAM

As demonstrated in Fig. 1, the system comprises of a

data interface program that links three major subsystems: the

Wireless InSite network simulation dataset, the network

optimization algorithm, and the OMNeT++ network framework

and visualization tool. UAV objects in the swarm output

characteristics such as location, heading, speed, as well as

sensor data that depends on the mission objective. This data is

fed into the network optimization algorithm, which employs a

Fig. 1: UAV Swarm system block diagram

2

form of particle swarm optimization (PSO) to choose where the

most efficient connections can be made between each member

of the swarm. It does this by querying the Wireless InSite

dataset that contains wireless channel information on all

possible connections in the swarm. These have been pre-

calculated within the testbed. Once the network optimization

algorithm determines the most efficient channels, it interfaces

with the OMNeT++ visualization tool to create a network

distribution (NED) file that outlines the resulting structure of the

network, including the active network connections and positions

of each of the objects in the swarm. This image is captured

from OMNeT++ in order to obtain the output network from the

swarm state in question.

III. INDIVIDUAL TASK SUMMARY

A. Particle Swarm Optimization – Ryan Downey

Ryan was tasked with algorithm development and

research primarily focused on particle swarm optimization. The

algorithm itself is a very general heuristic to approximate very

complicated problems. The implementation of the algorithm will

vary quite a bit depending on the specific application but all

variants share some similarities. The algorithm works by assuming a group of particles.

Each particle has a known position and velocity. “Particle”,

“position”, and “velocity” are not always literal but serve as an

analog to the original incarnation of the algorithm. The position

serves as the function to be optimized and the velocity is the

engine in which the position is modified over successive

iterations of the algorithm for each particle. Particle swarm

optimization follows the basic design flow chart shown in Fig.

2. For each iteration of the algorithm, each particle in the

swarm has three distinct options to adjust its velocity. The

particles can explore neighboring positions, head toward a

previously discovered best personal position, or head toward the

best global position discovered thus far. Some implementations

choose one of the three options based on probability while

others simply weigh the effect each possibility has on the total

velocity with pseudorandom numbers. Every particle has a

memory of its best discovered position and the swarm keeps

track of the global best position found. Over many iterations the

particles will tend to converge to the global best position. There

is no way to test whether the algorithm has found the optimal

position and a stopping criteria must be applied. This is usually

either a set number of total iterations or a certain number of

iterations without the global best position being improved.

There are many applications for particle swarm

optimization when it comes to UAV swarms. It can optimize

pathing for drones that are traveling in a group to maximize

battery life, optimally spread out a swarm for maximum sensor

coverage over an area of interest and find the best routing for

wireless communications between drones in the swarm. We

decided to set our sights first on tackling the communication

optimization. In order to become familiar with the concept of

particle swarm optimization we first applied the algorithm to a

well-known computer science problem known as the traveling

Fig. 2: Particle swarm optimization flowchart

salesman which can be described as follows. Given a certain

number of cities and the distances from each city to every other

city, find the shortest route from a starting city that travels

through every city only once and returns to the starting city. This

is also a beneficial starting point because of its similarities to

3

finding efficient routes for multi-hop wireless communication in

UAVs.

In order to address the traveling salesman problem it

was necessary to redefine some of the key terms in the original

algorithm. Each particle's position is a potential solution to the

problem (that is a continuous loop starting in one city and

connecting to all others before returning to the starting city).

Velocity defines the way in which the particle changes its

position. Exploring is done by randomly inverting sequences in

the loop. Migration toward personal and global best solutions

occurs by shuffling a random part of the path from the target

solution into the current solution. The particles in this

implementation choose one of the three options for movement

per iteration of the algorithm. In order to increase algorithm

efficiency, the decision on which velocity modifier to adopt for

each loop of the algorithm is determined by a shifting

probability. These probabilities start out in such a way that the

particles are more likely to explore solutions around them than

converge toward known solutions in the beginning. As the

algorithm progresses, the particles become less likely to explore

and more likely to converge.

Tests were run on the efficiency of this algorithm and

results have been promising. Tests were performed with twenty

particles and the algorithm was stopped after 2000 iterations. All

tests concluded in under five seconds. In tests between five and

fifteen cities, the particle was always able to arrive at the

optimal solution. On tests between twenty and forty cities, the

algorithm managed to get within 25% of the optimal solution.

This could easily be improved with more particles, more

iterations or a more efficient local search algorithm.

B. Network Framework – Jason Hahn

Jason’s primary task was the creation of the OMNeT++

network framework tool. OMNeT++ is an object based C++

simulation library and framework construction tool [6]. In this

application, OMNeT++ was used to create a model framework

for the wireless network between each node in the swarm

including the base station. It is important to note that

OMNeT++ is not specifically a network simulator but rather is a

simulation platform that provides an object architecture for

network models. Fig. 3 shows an example network model in an

OMNeT++ GUI visualization. The diagram represents each

node as a white circle. The lines connecting the nodes represent

transmission and reception lines.

OMNeT++ frameworks start with a component

architecture, written in C++. These modules define the

parameters that create each node in the simulation network.

Modules can be mapped into a communication hierarchy and be

nested into a compound module for organization of larger

parameter sets.

The structure of the network is then created using the

network description (NED) language. The NED file contains

instructions describing how the nodes in the network are linked,

as well as parameters used in the visualization portion such as

the definition of images used to portray each node in the

network and the control of the results when the simulation is

run.

Fig. 3: Example of OMNeT++ network model

An initialization file is also written to define

parameters within the NED model file. This can be configured

for several simulation trials to maximize testing capabilities and

efficiency.

After modules are linked with the simulation kernel in

a make operation, the network simulation can be modeled within

the OMNeT++ GUI and studied. The results are also output into

vector and scalar files that can be further processed in other

tools such as Matlab or a similar program. Fig. 4 (next page)

demonstrates the data flow and structure of an OMNeT++

simulation framework.

Jason learned the NED language and studied how to

best implement the OMNeT++ simulation structure within the

whole of the system. Since the visualization portion of this

software is the primary point of use, he has created the

subsystem that parses the algorithm output into an OMNeT++

readable NED file that contains the network structure

information. This system will be discussed more thoroughly in

the System Prototype section of this report.

4

C. Site Specific Simulation – Christopher Peterson

Chris’ primary task was to lead development of

dataflow and network simulation using the Wireless InSite

software from Remcom [6]. This task involved gathering data

from simulated UAV objects in the swarm and creating a nodal

network with a model of the wireless channels between nodes.

Fig. 5 shows an example of this.

Wireless InSite can be used in the simulation two

separate ways.

The first method uses Wireless InSite to calculate

wireless channels in real time. As the positions of each node in

the network are updated, the Wireless InSite simulation space is

updated, and the simulation is repeated. This provides real time

information about the status of the network, and allows for very

accurate path loss information, as well as other channel

parameters such as power received, path gain, and spread. This

also allows the simulation to be updated with pertinent

information about the environment, including building data and

foliage. The drawback is that this method requires considerable

computing resources to be available at any deployment location.

There is an express version of Wireless InSite that can be used

for real time applications that may help alleviate this

shortcoming, and deserves some further research for this

application.

The other method is to run many possible simulated

environments filled with possible locations of transmitters and

receivers. This data is used to create a database of the

information that can be quickly accessed during the deployment

which allows for quicker response times of the algorithm, and

thus better performance of the system as a whole. Unfortunately,

it can be difficult to account for factors such as buildings and

foliage, as well as network congestion in given areas. This type

of dataset is shown in Fig. 6.

Due to the necessity of a fast, real-time response from

the PSO algorithm, this database method has been chosen. This

framework allows for faster reaction time to changes in the

structure of the swarm which results in a rapidly evolving

network, with communication channels being gained and lost

throughout the lifetime of the simulation.

Fig. 4: OMNeT++ system flowchart Fig. 5: Swarm objects in Wireless InSite

Fig. 6: Database grid in Wireless InSite

5

Wireless InSite outputs the properties of the connection

quality between each node (shown in Fig. 7). It calculates

information on:

Paths: Information about each individual path between

a pair of nodes. Includes all points of interaction for

each given path.

Path loss: The reduction in attenuation of a

transmission wave as it moves through a space. This is

measured in dB.

Path gain: The inverse of path gain.

Received power (signal strength): The transmitter

output that is received by the desired recipient node.

This is measured in dBm.

Delay spread: Difference in time between the first

received signal component, and the last received signal

component. These paths can be created by reflections

and refractions caused by objects in the environment.

This is measured in seconds.

IV. NETWORK OPTIMIZATION ALGORITHM

The network optimization algorithm, written in C++,

uses an iterative approach to determine wireless channel

connections between nodes in the swarm. Some assumptions

are made regarding the characteristics and goals of the swarm:

Nodes will not be transmitting and receiving at the

same time; this means that signal power will not be

divided amongst multiple nodes for concurrent

transmissions so signal power can be dedicated to one

transmission at a time.

Every node in the swarm is equal. All objects produce

the same signal characteristics.

Wireless channels are considered independently of each

other. They are not summed to consider to a whole

path in the event of a single or multiple bridging nodes.

In its current state, the network optimization algorithm evaluates

one parameter at a time to determine the best wireless

communication channels. For the current round of testing,

power received and path loss were the two parameters focused

on.

A. Overview of Operation

UAV objects, containing positional data (i.e. x, y, and

z-coordinates), identification tags, and characteristics calculated

in the Wireless InSite database such as the aforementioned path

loss and power received information from the other active nodes

in the swarm, are imported into the algorithm stage of the

simulation. All of this information will be used to calculate the

final output wireless channels that are depicted using

OMNeT++.

In the initial configuration of the simulation, the

desired characteristic to be evaluated in the algorithm is

specified. Based on this characteristic chosen, threshold values

are set as upper and lower bounds on pass/fail criteria for a

wireless channel. Multiple threshold ranges can be tried for

each test case.

Only the wireless channels of one of the nodes in the

swarm are calculated in an iteration through the algorithm. This

simplifies the OMNeT++ output so the image is readable, and

also allows for easier comparison of the algorithm results from

node to node in the swarm.

B. Pseudocode

The process creates a wireless channel “map” that

contains one less connection than the number of nodes present

in the swarm. In the event a connection does not meet the

prescribed threshold based on the chosen characteristic, the

simulation can be configured to either take the next best

connection whose values are closest to the threshold values or

not connect the node to the rest of the swarm, indicating that

there is no valid connection present.

C. Example Process

In this section, an overview of how the algorithm

operates in a general case is detailed. In this example, the

connections from node 1 to the surrounding target nodes will be

calculated. Fig. 8 (next page) shows the initial, unconnected

state of the nodes.

441 75 85 4 15.9374 -55.7029 442 80 85 4 20.7123 -50.5362 443 85 85 4 25.5734 -59.3397 444 90 85 4 30.4795 -52.3598 445 95 85 4 35.4119 -53.2187 446 100 85 4 40.3609 -61.2706 447 105 85 4 45.3211 -65.0727 448 110 85 4 50.2892 -71.44 449 115 85 4 55.263 -66.0835 450 120 85 4 60.2412 -62.5924 451 0 90 4 60.0333 -63.9571 452 5 90 4 55.0364 -63.6514 453 10 90 4 50.04 -62.939 454 15 90 4 45.0444 -60.6147 455 20 90 4 40.05 -57.3991 456 25 90 4 35.0571 -54.0845 457 30 90 4 30.0666 -52.5123 458 35 90 4 25.0799 -49.5098 459 40 90 4 20.0998 -48.9302 460 45 90 4 15.1327 -45.0735 461 50 90 4 10.198 -76.6604 462 55 90 4 5.38516 -41.9581 463 60 90 4 2 -57.4748 464 65 90 4 5.38516 -41.6698 465 70 90 4 10.198 -63.7766 466 75 90 4 15.1327 -44.7398 467 80 90 4 20.0998 -49.199 468 85 90 4 25.0799 -49.4244 469 90 90 4 30.0666 -53.235 470 95 90 4 35.0571 -54.4997 471 100 90 4 40.05 -57.0081

Fig. 7: Output example from Wireless InSite. This data shows path

information, path loss, path gain, power received, and spread.

6

The algorithm begins by looking at the connection

between the home UAV, UAV 1, and the first target node,

designated as UAV 2. The connection between UAV 1 and UAV

2 is determined based on the algorithm characteristic. If the

desired characteristic is within the specified threshold, the direct

connection passes the criteria and is approved, as shown in Fig.

9.

If the connection fails the criteria, then the target node

needs to be connected through another bridging node. The

characteristic parameter between the target node and the other

field nodes is compared to determine which node best meets the

criteria to bridge the node to the home node. Fig. 10 shows an

example of this type of connection. Note that at this point in the

algorithm, a connection between the subsequently found

bridging node and the home node is not created, but rather, this

is done iteratively as the algorithm cycles through the rest of the

nodes.

After finding a connection for the first target node, the

algorithm iterates through the rest of the nodes in a similar

fashion. Some simple connection error-checking is done to

prevent redundant connections from being made, which also

ensures that that all nodes are connected. Fig. 11 depicts an

example of the order in how nodes are connected to each other.

V. SYSTEM PROTOTYPE

A. Prototype Overview

Network connections are simulated in Wireless InSite

to create a database of node information within a specified

testbed. The network optimization algorithm chooses with

Fig. 9: The first case of connection in an iteration. If the algorithm determines that the tested characteristic is within the threshold, the connection passes the

criteria.

Fig. 11: An example result from the algorithm, showing the iterative process through which connections are made.

Fig. 10: The second case of connection in an iteration. If the algorithm

determines that the tested characteristic is not within the threshold, the

connection fails the criteria and a bridging node is connected that best meets the criteria.

Fig. 8: The initial state of the swarm before the algorithm determines the wireless channels.

7

connections are optimal. These calculations are dependent on

the different parameters of the wireless channels between each

of the nodes in the swarm such as path loss and power received.

The output of the algorithm is translated into a NED file

readable by OMNeT++. The resulting simulation run in the

OMNeT++ GUI environment displays the nodes and active

connections calculated by the algorithm. When data within the

swarm changes, such as the movement of one of the active

nodes, the algorithm runs again and this cycle repeats.

B. Testbed Overview

A 25X25 node database has been created in Wireless

InSite, with each node five meters apart resulting in a 120X120

meter sized grid. For initial testing done so far, each node in the

database has the same fixed z-coordinate, creating a two-

dimensional space of operation.

Each of the points in the database represents a possible

node location of a UAV within the swarm network. All of the

possible connection paths between nodes are pre-calculated at

one time before the swarm simulation is initialized, creating a

set of values for every possible node connection within the

database. This was done due to Wireless InSite taking too much

time to calculate new paths when the swarm changes. The

database is represented in Wireless InSite as shown in Fig. 12.

Each possible node is shown as a green cube.

To allow for testing communication behavior with

nodes both in direct line of sight (LOS) and non-line of sight

(NLOS), which in turn affects the signal parameters such as path

loss and power received, buildings were added as obstacles, as

denoted by the gray blocks in Fig. 12. These provided a more

rigorous test of network communication paths as they could

bounce off of these buildings to create more complex

connections between nodes.

C. Swarm Operation Testing

The goal of the system prototype is to be able to use the

network optimization algorithm to gather information about the

connection characteristics between the nodes in the swarm

network, and then show these results in OMNeT++ in an

elegant, easy to read way. Note that in Fig. 13 (next page), the

network information shown in the Wireless InSite calculations

on the left side of the image are difficult to read and understand.

After network optimization, however, the output to OMNeT++

as shown on the right side of Fig. 13 is simple to read and shows

which nodes are directly connected to each other. For the sake

of readability of output, all of the images shown here and later

in this report will focus on the connections based around the

control node, which in Fig. 13 resides in the bottom left hand

corner of the Wireless InSite testbed. As the swarm evolves,

these images from OMNeT++ can be stitched together to

visualize the swarm movements throughout its lifetime.

1. Swarm Network Initial State

The initial states of each UAV object in the swarm are

manually entered into the simulation. Our test runs have

involved five regular swarm UAVs and one UAV deemed the

control node. There is no operational difference between this

object and any other in the swarm; rather, it is the node that

connections are calculated for in each iteration of the simulation.

Information about each UAV in the swarm is input into

the network optimization algorithm. Currently the algorithm

considers the positioning of the UAVs within the testbed,

ignoring parameters such as speed and heading, as well as the

signal parameters. This essentially gives us an instantaneous

solution to the swarm at the given state input.

In its current state, the algorithm then begins

comparison of the possible network paths between the UAV

network nodes. The algorithm parses through the pre-calculated

Wireless InSite node dataset and determines which of these

nodes are active. Once this is done, the algorithm begins

looking at the connections to determine which is the most

efficient. Currently, it looks at the power received or path loss

characteristics of each of the connection possibilities. It also

checks if the connections are even possible between different

nodes due to obstacles obstructing the wireless channel between

transmitter and receiver.

As described earlier in this report, the algorithm

operates by iterating through each node that is to be connected

to the control node. A comparison is done of the specified

signal parameter to the threshold values that indicate a good

Fig. 12: Wireless InSite testbed

8

path. If the path is deemed to be acceptable, the connection is

confirmed and created. During most of our testing, the

algorithm paths that were chosen within the specified parameter

threshold were between LOS paths. However, if a node was

NLOS with the control node, bridging nodes were chosen since

signal parameters were usually beyond the threshold values.

Some these test results are detailed in Appendix B.

Once the algorithm is finished parsing through the

possible paths, the wireless channel connections chosen are

parsed into an OMNeT++ NED file, which contains the

structural information for the final visualization of the state of

the swarm. A simple text file is also output with the path

telemetry calculated from Wireless InSite, including path loss,

path gain, power received, and spread. The simulation is

compiled and the final visualization of the swarm output is

captured as an image file.

2. Swarm Network States 1-N

The process outlined in the previous section is repeated

for each subsequent state of the swarm. Figures 14-17 outline

examples of this process and iterations through a few states,

using power received as the evaluated signal parameter.

Fig. 14 shows the output of the algorithm in OMNeT++

of the initial state, also known as state 0. The control node that

is being analyzed is located in the bottom left hand corner of the

image. For the example outlined in this report, the Wireless

InSite testbed used is the one previously mentioned in Fig. 12

(page 7). The algorithm has analyzed the wireless channels

between each other node in the swarm, labeled as nodes A-E in

the figure. For this instance, the algorithm has determined that

the direct paths between the control node and corresponding

receiver are the most efficient in terms of power received in the

Fig. 13: Output from Wireless InSite versus final swarm network output from OMNeT++

Fig. 14: Initial state (state 0) of the swarm example

9

cases of nodes A, B, C, and E. However, since the power

received between the control node and node D did not meet the

threshold values for an acceptable signal, a direct path was not

determined for this. Instead, using node C as a jumper

betweenthe control node and node D was determined by the

algorithm as the best course of action, as it had the most

desirable value of power received.

Fig. 15 shows the output of the algorithm in OMNeT++

at following phase, state 1. Node C was manually relocated

behind the building obstacle in the Wireless InSite testbed. This

meant that there was no line of sight between the control node

being analyzed and the receiver node C, resulting in a poor

power received value. Node D also remained behind the

building obstacle. In this case, the algorithm again determined

direct paths to nodes A, B, and E as there had been no change in

the swarm network structure on this end. However, since the

connection to node C did not meet the threshold value for power

received, the algorithm chose to use node B as a jumper between

it and the control node. Likewise, for node D, a similar path

was found with the connection traveling from the control node

to node B to node C then finally to node D. The connection

between node B and node D was deemed outside of the

threshold by the algorithm than the extra link to node C.

Fig. 16 shows the next iteration of this swarm network

example, state 2. The control node was manually moved out of

the corner approximately 20 meters at an angle of 45 degrees.

After evaluation with the algorithm, none of the paths changed

as a result from state 1 due to relatively little change in terms of

power received signal characteristics between the nodes.

Fig. 15: State 1 of the swarm example

Fig. 17: State 3 of the swarm example

Fig. 16: State 2 of the swarm example

10

Fig. 17 shows the final test state, state 3, of this swarm

example outlined here. Node D was manually moved back into

line of sight with the control node, increasing power received

between these two nodes, moving approximately 75 meters to

the left. All of the other nodes have stayed in the same location

on the testbed as the previous state. In this instance, the

algorithm outputs the direct connection between the control

node and node D. As with the previous iterations, connections

between node A and E remain direct to the control node. Also,

despite node D moving into a similar position on the testbed as

node B, the algorithm kept the previous state’s connection

between node B and node C as the path from C to the control

node.

By combining these images into a video or animated

.gif format, the change in the swarm network can be seen as the

shape of the swarm evolves. Connection paths are both created

and lost through each iteration.

VI. FURTHER STUDY

One of the chief concerns with the network

optimization algorithm has to do with the time it takes to

complete an analysis of the wireless channels calculated in

Wireless InSite. A typical computation time for the size of

swarm we employed during testing would take between ten and

twenty minutes to complete. One way to fix this would be to

keep history of the previous paths calculated so that the

algorithm does not have to start from scratch every time there is

a change in the swarm shape. This method would allow for

much faster computation times in that not all node connections

would have to be recalculated.

In a real world scenario, much of the relevant path data

will be measured by each node, rather than simulated with

Wireless InSite. Location data will be gathered by methods such

as GPS, and possibly reinforced with radar, LiDAR, or IMU

data. Path data can be measured directly from each node, the

received power, and RSSI values between a pair of nodes. This

would be advantageous, as the data used in the routing

algorithm will be the actual data, rather than simulated values.

This will allow the network to truly adapt to the environment

that the swarm is in. Gathering the path data live does present

some disadvantages, however. One is that the pathfinding will

take a hit. We will not be able to as accurately predict how

moving a node will affect the connection quality until the node

has actually moved to a new location, which will consume time

and energy. Prediction methods can be used to guess how

possible location changes will affect the connection quality, but

that is another project in of itself. .

The algorithm also needs improvement so it can move

to a more true particle swarm optimization implementation. As

it stands, the algorithm employs a version of Djikstra’s

algorithm as a precursor to full PSO implementation. Further

testing of this algorithm will give us a better idea of how well

the PSO implementation will potentially work once that is ready.

Furthermore, the current network optimization

algorithm only looks primarily at paths found, path loss, power

received, and distance metrics to determine what the best path is

to communicate node-to-node. A weighted system could be

developed to look at other properties such as spread and power

received to make the algorithm more efficient. Testing needs to

be done to determine how these values need to be used

depending on the scope of the particular simulated mission.

New testbeds should be developed in Wireless InSite to

test algorithm performance further. Different scenarios with

new characteristics such as different obstacles are being

modeled to have a wider base on algorithm efficiency within

these testbeds. A three-dimensional simulation, as shown in Fig.

18, needs to be tested. However, computational limitations are

significant as the Wireless InSite database grows; further

research may be necessary in this portion.

More development within the OMNeT++ visualization

is necessary in order to make it more robust and show more

information about the network paths besides the basic

connections and node placements. Variables for future three-

dimensional testing, such as the z-coordinate, need to be

considered. The drawing of obstacles found in the Wireless

InSite testbed also could be added in the future to make the node

connections more clear.

It may be preferable to create a customizable GUI to

replace the OMNeT++ visualization altogether. While

OMNeT++’s network simulation tools are very powerful, by the

end of the project it was only used for the final output

visualization where actual operation of the network in

OMNeT++ as a simulation was unnecessary. A customizable

GUI may also allow for more flexible output in later stages of

this project, perhaps to visualize movements in the swarm as an

animation rather than a batch of images stitched together.

Fig. 18: A three-dimensional Wireless InSite database testbed

11

At this time, the algorithm deals primarily with the

optimization of an input node set. That is to say, the location of

each node is specified manually, then the algorithm is run to

determine the optimal communications network for that setup.

Another area for future study is creating a path finding

algorithm. This would be useful, as the swarm could decide

where each node would travel, provided a set of parameters.

Some possible considerations could include a tendency to have

the swarm remain more densely packed to get better resolution

of a specified area, or conversely, spread out more to gather a

larger volume of data on the area of interest as a whole. Another

consideration for data collection could include a tendency to

loiter around certain area or wander. Considerations for the

swarm could include how movements will affect the flight times

of each node, and the swarm as a whole. For example, fast

moving nodes will be able to gather data about a larger area, but

they will also consume more power by moving. Another factor

to consider could be the amount of data to be transferred. If a

node needs to transmit a large amount of information, then

moving far away may not be a wise decision, as it will have a

negative effect on the achievable data rate. Or, maybe the swarm

modifies itself to be able to find the balance of data acquisition

and transmission. These are all things to consider for future

iterations of a path finding algorithm.

Another area of concern is detection and avoidance

(DAA) of obstacles and non-cooperative intruders. While the

swarm is airborne, it is important to be able to see obstacles that

may not have been accounted for in the preparations before the

mission, both stationary, and mobile. This is an area that is

receiving more attention as consumer drones are becoming more

common and the Federal Aviation Administration (FAA) is

needing to create regulations for these to interact safely in the

national air system. Some current efforts to develop DAA

methods involve using radar, LiDAR, and optical vision

systems.

VII. GANTT CHART

The Gantt chart is shown in Fig. 19. As of April 19,

2016, the project has reached its completion for this semester.

Sufficient testing of the currently implemented version of the

algorithm within the rest of the Wireless InSite and OMNeT++

testbed has been completed. The algorithm development itself

is not a true particle swarm optimization algorithm per the initial

goal, but a good base has been established for further

development of this project with future design groups. We have

been able to accomplish quite a bit of testing with the current

algorithm and have been able to demonstrate its ability to find

the best wireless communication channels given a signal

parameter.

Fig. 19: UAV Swarm Gantt Chart

12

VIII. ETHICAL REVIEW

Concepts from this project can be applied to the control

of multiple UAVs in a variety of settings. One of these

applications is the controversial use of UAVs in surveillance. As

UAV technology has improved to make vehicles more versatile,

privacy issues have developed, bringing to rise questions on

what restrictions should be in place in regards to what entities

should be allowed to fly them, in what circumstances is it

appropriate, and where they can be flown. These ethical

concepts must be kept in mind for further application of this

project beyond a computer simulation.

IX. CONCLUSION

This project applies swarm principles to a network of

UAVs in order to achieve optimal communication between each

vehicle and to lower the amount of energy used to coordinate the

movement of multiple vehicles. A network optimization

algorithm has been developed to work with wireless channel

modeling software, Wireless InSite, to determine the best paths

of communication for maximum efficiency through evaluation

of channel characteristics such as path loss, power received, and

others. The results from this algorithm have been visualized in

OMNeT++. This model has been evaluated in simulation in two

dimensions on a 120X120 meter grid and is capable of choosing

optimal paths between nodes in the network by comparing

channel characteristics such as path loss and power received.

X. REFERENCES

[1] C. Reynolds, “Flocks, herds, and schools: a distributed

behavioral model,” Computer Graphics, vol. 21, no. 4, pp.

25-34, July 1987.

[2] A. Olivera, J. Garcia-Nieto and E. Alba, “Reducing vehicle

emissions and fuel consumption in the city by using

particle swarm optimization,” Applied Intelligence, vol.

42, no. 3, pp. 389-405, 2015.

[3] C. Colombo and C. McInnes, “Orbit design for future

SpaceChip swarm missions in a planetary atmosphere,”

Acta Astronautica, vol. 75, pp. 25–41, 2012.

[4] R. Jankovic, “Computer Simulation of an Armoured

Battalion Swarming,” Defence Science Journal, vol. 61,

no. 1, pp. 36-43, January 2011.

[5] OMNeT++. (2014). User Manual: OMNeT++ Version

4.6. [PDF]. Available: https://OmNETpp.org

/doc/OmNETpp/manual/usman.html

[6] Remcom. (2011). Wireless InSite – Wireless EM

Propagation Software form the Leaders in High-Fidelity

Propagation. [PDF]. Available : http://static1.1.sqscdn.

com/static/f/323055/13830566/1314205709293/WI2.6_We

b.pdf?token=kdVoyRwPE6ecs3uedELzwO

13

APPENDIX A.

I. BUDGET

The budget for this project is three hundred dollars.

This is provided by the University of North Dakota Electrical

Engineering Department. A breakdown of the costs acquired

thus far is as follows:

TABLE I

UAV SWARM PROJECT COST BREAKDOWN

Software Systems

OMNeT++ $0

C++ $0

Wireless InSite $0

Simulation Hardware $0

Total $0

Since this is an entirely software-based project, all software has

either been provided by UND (such as Wireless InSite) or is

open-source and free to download (OMNeT++ and C++). This

makes this project easily sustainable and could possibly be

continued by future design groups.

VI. ADVISOR MEETINGS

Weekly meetings are being conducted with the advisors

of the project. In these meetings, we discuss the progress made

this far, and the next steps required to complete the project.

September 10th

was the first such meeting. The initial tasks were

divided among the group members, and a base set of the

collaboration tools were set up. In subsequent meetings, we

shared the details of our specific areas of research and

developed an initial plan of how to complete this project.

A. Meeting Summary – 9/10/15

Determined division of work

Ryan: optimization algorithm

Chris: Wireless InSite

Jason: simulation program

Create Dropbox folder for all work

B. Meeting Summary – 9/16/15

Clean up S1R1 report

Jason: explore different network simulators such as

OMNeT++

TCP/IP or RF communication will depend on Wireless

InSite

Find best way to transport data

Data structures need to be written for each node

Central unit will control all nodes

C. Meeting Summary – 9/23/15

Continued progress with OMNeT++

Focus on creating a network structure

1-way and 2-way communication

Implement PSO in C++

D. Meeting Summary – 9/30/15

Continued progress with Wireless InSite

PSO code was created – traveling salesman problem

Import I/O from Wireless InSite to C++

Finish simulation in Wireless InSite, add more

parameters to OMNeT++ network framework

E. Meeting Summary – 10/7/15

Most efficient path through nodes

Battery life is an important factor

The swarm lifetime needs to be maximized

Create lookup table for properties

Chris: work on database

Jason: create methods for nodal structure, start with a

10x10 database

F. Meeting Summary - 10/14/15

Chris: Continue work on database and lookup table

Jason: Continue creating nodal structure methods

G. Meeting Summary – 10/21/15

Continue progress on previous tasks

Complete first paper & presentation slides

H. Meeting Summary – 10/28/15

Prepare for first presentation

Discussed database methods in Wireless InSite

I. Meeting Summary – 11/11/15

Database completed in Wireless InSite

Continue developing final touches on OMNeT++

framework

J. Meeting Summary – 11/18/15

Begin work on transposition from Wireless InSite to

OMNeT++

Discussed best methods to transpose

Chose to parse using a Python script to go through the

WI files

14

K. Meeting Summary – 11/25/15

Continue work on transposition tool to create WI

topology in OMNeT++

L. Meeting Summary 1/20/16

Recap progress from previous semester

Continue develop on all categories

Ryan: begin PSO algorithm development refinement

M. Meeting Summary 1/27/16

Jason and Chris: implement Ryan’s algorithm into the

parsing system

N. Meeting Summary 2/3/16

Jason and Chris: continue testing and implementation

of Ryan’s algorithm

O. Meeting Summary 2/10/16

Jason: new OMNeT++ output system with iteration

Chris: continue development of more testbeds for

Ryan

Prep for presentation and paper

P. Meeting Summary 2/24/16

Create simple algorithm until Ryan has his working

Come up with better test system and continue creating

automated procedures for each part

Q. Meeting Summary 3/2/16

Jason and Chris: Familiarize ourselves with common

path optimization techniques

R. Meeting Summary 3/9/16

Identify some metrics to use in optimization algorithms

S. Meeting Summary 3/23/16

Create a basic simulation program that is able to

o Record node locations

o Gather the appropriate connection information

o Output a .ned file for OMNeT++

T. Meeting Summary 3/30/16

Continue to develop network selection algorithm

Fully incorporate OMNeT++ visualizations with

program

U. Meeting Summary 4/6/16

Prepare paper and slides for next deadline

V. Meeting Summary 4/13/16

Expand algorithm capabilities

Document code to ease future students transitioning

into this project

Prepare demonstration for final class presentation

15

APPENDIX B

Testing Assignment Sheet

Project:

Members:Contractor:

Test ID# Nodes Signal Parameter Threshold Min

Resultant Path

Param Pass/Fail Notes

1 control Power Received -70

a -55.9784 p

b -62.1692 p

c -62.7609 p

d -58.4549 p control-d = -74.4648, fails

e -58.0881 p control-e = -107.131, fails

2 control Power Received -80

a -55.9784 p

b control-b -62.1692 p

c control-c -62.7609 p

d control-d -58.4549 p

e e-d -74.4648 p control-d = -107.131, fails

3 control Path Loss 0

a 60.2802 p

b 66.4710 p

c 67.0627 p

d 62.3899 p control-d = 78.7666, fails

e 62.0438 p control-e = 111.4320, fails

4 control Path Loss 0

a 60.2802 p

b 66.4710 p

c 67.0627 p

d 78.7666 p

e 62.0438 p control-e = 111.4320, fails

UAV Swarm

J. Hahn, C. Peterson

EE 481 Senior Design - University of North Dakota

UAV Swarm Algorithm Test Plan Log

Node Locations (in WI) Threshold Max Resultant Paths

0,0 0.00

35,50 control-b

15,15 control-a

45,110 e-d

0,0 0.00

10,75 control-c

15,105 d-c

10,75

15,15 control-a

35,50

15,105

15,15 control-a

35,50 control-b

45,110

0,0 70.00

45,110 e-d

0,0 80.00

10,75 control-c

15,105 d-c

10,75 control-c

15,105 control-d

15,15 control-a

35,50 control-b

45,110 e-d