UAV Navigation using Local Computational Resources

(1)

UAV Navigation using Local Computational Resources

Keeping a target in sight MAGNUS CARDELL

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ARCHITECTURE AND THE BUILT ENVIRONMENT

(2)

UAV Navigation using Local Computational Resources

Keeping a target in sight

MAGNUS CARDELL

Master’s Programme, Software Engineering of Distributed Systems, 120 credits

Date: January 22, 2021 Supervisor: Anders Västberg Examiner: Gerald Q. Maguire Jr.

School of Electrical Engineering and Computer Science Host company: Carmenta AB

Swedish title: UAV Navigering med Lokala Beräkningsresurser Swedish subtitle: Bevara ett mål i sensorisk räckvidd

(3)

c

2021 Magnus Cardell

(4)

Abstract | i

Abstract

When tracking a moving target, an Unmanned Aerial Vehicle (UAV) must keep the target within its sensory range while simultaneously remaining aware of its surroundings. However, small flight computers must have sufficient environmental knowledge and computational capabilities to provide real-time control to function without a ground station connection. Using a Raspberry Pi 4 model B, this thesis presents a practical implementation for evaluating path planning generators in the context of following a moving target. The practical model integrates two waypoint generators for the path planning scenario: A*

and 3D Vector Field Histogram* (3DVFH*). The performances of the path planning algorithms are evaluated in terms of the required processing time, distance from the target, and memory consumption. The simulations are run in two types of environments. One is modelled by hand with a target walking a scripted path. The other is procedurally generated with a random walker.

The study shows that 3DVFH* produces paths that follow the moving target more closely when the actor follows the scripted path. With a random walker, A* consistently achieves the shortest distance. Furthermore, the practical implementation shows that the A* algorithm’s persistent approach to detect and track objects has a prohibitive memory requirement that the Raspberry Pi 4 with a 2 GB RAM cannot handle. Looking at the impact of object density, the 3DVFH* implementation shows no impact on distance to the moving target, but exhibits lower execution speeds at an altitude with fewer obstacles to detect.

The A* implementation has a marked impact on execution speeds in the form of longer distances to the target at altitudes with dense obstacle detection.

This research project also realized a communication link between the path planning implementations and aGeographical Information System (GIS) application supported by the Carmenta Engine SDK to explore how locally stored geospatial information impact path planning scenarios. Using VMap geospatial data, two levels of increasing geographical resolution were compared to show no performance impact on the planner processes, but a significant addition in memory consumption. Using geospatial information about a region of interest, the waypoint generation implementations are able to query the map application about the legality of its current position.

Keywords

Unmanned aerial vehicle, Path planning, On-board computation, Autonomy

(5)

(6)

Sammanfattning | iii

Sammanfattning

När en obemannade luftfarkost, även kallad drönare, spårar ett rörligt mål, måste drönaren behålla målet inom sensorisk räckvidd medan den håller sig uppdaterad om sin omgivning. Små flygdatorer måste dock ha tillräckligt med information om sin omgivning och nog med beräkningsresurser för att erbjuda realtidskontroll utan kommunikation med en markstation. Genom att använda en Raspberry Pi 4 modell B presenterar denna studie en praktisk applicering utav vägplanerare som utvärderas utifrån deras lämplighet att följa ett rörligt mål. Den praktiska implementationen jämför två vägplaneringsalgoritmer:

A* och 3D Vector Field Histogram* (3DVFH*). Vägplaneringsalgoritmernas prestanda utvärderas genom att studera deras hastighet, avstånd från målet och minnesresurser. Vägplaneringsalgoritmerna utvärderas i två situationer. Den första är en simulationsvärld som är gjord för hand där målet rör sig efter en fördefinierad väg. Den andra är en procedurellt genererad värld där målet rör sig slumpmässigt. Studien visar att 3DVFH* producerar vägar som håller drönaren närmare målet när målet rör sig efter en fördefinierad väg. Med en slumpvandring i en procedurell värld är A* närmast målet. Resultaten från Raspberry Pi visar också att A* algoritmen sätter prohibitivt höga minneskrav på Raspberry Pi 4 som bara har 2 GB RAM. Studerar man påverkan av synbara objekt på avståndet till målet så ser man ingen för 3DVFH* algoritmens egenskap att hålla sig nära, men man ser snabbare bearbetningshastighet när det är färre objekt att upptäcka. A* algoritmen ser en påverkan på dess distans från målet när fler objekt finns att upptäcka.

Denna studie visar också hur en kommunikationslänk mellan vägplaneringsalgoritmer och kartapplikationer som stöds utav Carmenta Engine SDK skall implementeras. Detta används för att studera hur lokal geografisk information kan användas i ett spårningssammanhang. Genom att använda två nivåer av geografisk upplösning från VMap data, jämförs påverkan på vägplaneringarnas prestanda. Studien visar att ingen påverkan på prestandan kan ses men att kartapplikationen kräver mer minnesresurser.

Genom att använda geografisk information om en region av intresse visar denna applikation hur vägplaneringsalgoritmerna kan fråga kartapplikationen om legaliteten om sin nuvarande position.

Nyckelord

Obemannade drönare, Vägplanering, Lokala beräkningar, Autonomi

(7)

(8)

Acknowledgments | v

Acknowledgments

I would like to thank Carmenta for providing me the opportunity to pursue this thesis subject and Emilie Le Moël for her valuable help and guidance in showing how the Carmenta Engine works. I would also like to thank my supervisor Anders Västberg for his advice and my examiner Gerald Q. Maguire Jr. for his helpful feedback on my work.

Stockholm, January 2021 Magnus Cardell

(9)

(10)

CONTENTS | vii

List of Figures

2.1 Context of UAV research. Inspired by Figure 3 from [1] and Figure 3 from [2] . . . 7 3.1 Architectural overview of the complete simulation setup. These

three environments run independently of each other and communicate through message passing. While this diagram reflects the desired setup, subsequent tests show that the nodes with asterisk currently can only run in a laptop. . . 18 3.2 3DVFH* waypoint generation. Inspired by the explanation

given by [3]. . . 24 3.3 A* waypoint generation. Extracted from logic in [3]. . . 28 3.4 Gazebo environment of the simulated world. The square box

(at the end of the vertical line) represents the moving target. . 34 3.5 Gazebo static environment world showing the scripted path of

the moving target as it moves according to five defined map positions. . . 35 3.6 System diagram of connected Raspberry Pi to incorporate

companion computer hardware in the software simulation. . . 38 4.1 3DVFH* implementation visualized in rviz. . . 44 4.2 A* tracking implementation visualized in rviz. . . 45 4.3 3DVFH* path planning Robotic Operating System (ROS)

nodes and how they pass topics to each other. . . 46 4.4 A* path planning ROS nodes and how they pass topics to each

other. . . 47 4.5 3DVFH* algorithm’s distance from the moving target. This

data was collected with the UAV running at an altitude of 2.5 m. Sample rate is 10 Hz. . . 49 4.6 A* distance from target. This data was collected with the UAV

running at an altitude of 2.5 m. Sample rate is 10 Hz. . . 49

(15)

4.7 3DVFH* execution speed. Sample rate is 10 Hz . . . 50 4.8 A* execution speed. Sample rate is 10 Hz. . . 50 4.9 3DVFH* algorithm’s distance from the moving target. This

data was collected with the UAV running at an altitude of 2.5 m and aggregated in 50 executions. . . 52 4.10 A* distance from the moving target. This data was collected

with the UAV running at an altitude of 2.5 m and aggregated in 50 executions. . . 52 4.11 Median execution times at different altitudes. Aggregated

results from 50 executions. . . 53 4.12 Median execution times at different altitudes. Aggregated

results from 50 executions. . . 54 4.13 3DVFH* distance from the moving target at an altitude of

10 m. Aggregated results from 50 executions. . . 55 4.14 A* distance from target at an altitude of 10 m. Aggregated

results from 50 executions. . . 55 4.15 Octree data size fit over time at 2.5 m and 10 m. 2.5 m has an

R-squared number of 0.995, and 10 m has 0.990. . . 56 4.16 Boxplots including the median distance for the Raspberry Pi

hardware. . . 58 4.17 Execution speeds comparing the laptop environment with the

Raspberry Pi hardware. . . 58 4.18 Visualization of VMap0 data with the advertised drone location

marked by the red dot. . . 62 4.19 Visualization of VMap1 data with the advertised drone location

marked by the red dot. . . 62 C.1 3DVFH* path planning ROS nodes and how they pass topics

to each other. . . 104 C.2 A* path planning ROS nodes and how they pass topics to each

other. . . 105

(16)

LIST OF TABLES | xiii

List of Tables

3.1 Iris drone specifications . . . 19

3.2 3DVFH* parameter description (1 of 2) . . . 25

3.4 A* parameter description (1 of 2). . . 29

3.6 3DVFH* parameter configuration . . . 31

3.7 A* parameter configuration . . . 32

3.8 Stereo_img_proc launch parameters . . . 33

3.9 Raspberry Pi 4 hardware details. . . 39

3.10 Laptop environment details. . . 40

4.1 Mean, standard deviation, minimum, and max values for flight at two altitudes. The simulation is static with a scripted moving actor. . . 54

4.2 Mean, standard deviation, count, minimum, and max values for memory consumption at two altitudes. The simulation is static with a scripted moving actor. . . 57

4.3 Mean, standard deviation, count, minimum, and max values for memory consumption in megabytes (MB). The simulation is randomly generated with a random walker. . . 60

4.4 Mean, standard deviation, count, minimum, and max values of metrics extracted from the random environment runs. . . . 60

4.5 Mean, standard deviation, count, minimum, and max values of metrics extracted from the random environment runs with Carmenta Engine using no GIS data. . . 63

4.6 Mean, standard deviation, count, minimum, and max values of metrics extracted from the random environment runs with Carmenta Engine using VMap0 data. . . 63

(17)

4.7 Mean, standard deviation, count, minimum, and max values of metrics extracted from the random environment runs with Carmenta Engine using VMap1 data. . . 63 4.8 Mean, standard deviation, count, minimum, and max values

of memory metrics per process extracted from the random environment runs with Carmenta Engine using no GIS data. . 64 4.9 Mean, standard deviation, count, minimum, and max values

of memory metrics per process extracted from the random environment runs with Carmenta Engine using VMap0 data. . 64 4.10 Mean, standard deviation, count, minimum, and max values

of memory metrics per process extracted from the random environment runs with Carmenta Engine using VMap1 data. . 64

(18)

LISTINGS | xv

Listings

3.1 Distributed ROS node . . . 38

3.2 SSH configuration . . . 39

3.3 Initialization and channel declaration . . . 41

4.1 dmesg -e output . . . 59

A.1 Random environment generator config . . . 85

A.2 Environment loader script. . . 87

B.1 CMake build file . . . 88

B.2 Carmenta Engine ROS wrapper file. . . 90

(19)

(20)

List of acronyms and abbreviations | xvii

List of acronyms and abbreviations

3DVFH* 3D Vector Field Histogram*

FCU Flight Control Unit

GIS Geographical Information System GNSS Global Navigation Satellite System GPS Global Positioning System

IMU Inertial Measurement Unit INS Inertial Navigation System

MAV Micro Aerial Vehicle

MAVROS MAVLink extendable communication node forROS ROS Robotic Operating System

SITL Software in the Loop

SLAM Simultaneous Localization and Mapping UAV Unmanned Aerial Vehicle

VFH Vector Field Histogram

(21)

(22)

Introduction | 1

Chapter 1 Introduction

This chapter introduces a general background to identify the problem area that motivates this thesis work. Section 1.2 outlines the specific problem being addressed in this study, ending with a definition of research questions. Then, Section 1.3 discusses the specific goals of the research questions to define the scope of the thesis project. Section1.4describes the delimitations of this thesis. Finally, the chapter ends with a disposition explaining the structure of this thesis document.

1.1 Background

Autonomous Unmanned Aerial Vehicles (UAVs), provide the unique ability to collect data from the air using a range of on-board sensors [4]. Compared to manned aircrafts and ground vehicles, UAVs offer safe and effective alternatives for dull, dangerous, or otherwise hard to realize missions [5].

However, in the field of vehicle motion planning, UAVs present particular challenges in the form of constraints caused by aerodynamic effects and uncertainties in state caused by partial knowledge of the environment. These limitations contribute to a large fraction of UAV missions being conducted with a human operator or a preplanned sequence of tasks [6]. The ability to make real-time autonomous decisions requires access to sufficient processing capabilities and environmental knowledge to generate satisfactory paths [7].

The steady increase in the computational capabilities of small flight computers and edge computing platforms has further opened up the field to new

possibilities in sophistication and autonomy. However, computing an exact

(23)

solution to the motion planning of aUAV’s path is nontrivial [7]. Algorithms that compute paths forUAVsneed to take into account real-time feedback in an environment that is messy and dynamic. When tracking a specific target, the drone needs to keep this target within sensory range while remaining aware of its surroundings.

Carmenta Geospatial Technologies (here after, simply Carmenta) is a privately held Swedish software development company founded in 1985 that specializes in Geographical Information Systems (GISs). Their vision is to provide mission-critical solutions that increase situational awareness in any location, situation, and environment. This mission has led Carmenta into various sectors and partnerships including traffic, security, and emergency response applications [8]. Carmenta operates globally but has a predominantly European customer base [9].

Depending on the use case, Carmenta integrates the Carmenta Engine, Carmenta Map Builder, and Carmenta Server into their customers’ workflow.

The Carmenta Engine is a software development kit, which interfaces developers with high-performing features supporting dynamic map displays.

These features can be used to create dynamic 2D and 3D renderings of maps and missions with real-time geospatial analysis, such as line-of-sight and terrain calculations. The engine provides scalable solutions and handles a multitude of input data including Open Geospatial Consortium standardized interfaces, sensor data, and other types of geospatial information.

1.2 Problem

Commonly, aUAVcommunicates with a ground node to which it can stream sensory data and receive back navigational instructions [10, 11]. Via some communication network, the UAV transfers data to the ground-based infrastructure giving it access to increased computational capabilities using resources located on the ground [5, 11, 12, 13, 14, 15, 16]. When in areas where connectivity to the ground station may be limited or undesirable, the UAVneeds to pursue its mission using only local resources.

In a real-world scenario, the application domain where a UAV follows a target may already have predetermined information stored as geographical information, that can be utilized in path planning with obstacle avoidance in

(24)

Introduction | 3

mind. For example, this information may define the area in which theUAVis allowed to fly or not. Such zones would be undetectable by onboard sensors while flying, and with the potential of intermittent ground station connection, this information should be stored locally. The Carmenta Engine is used in this thesis project to explore the viability of utilizing aGISapplication onboard a flying drone.

This thesis investigates the state of current research in the context of local computational capabilities of a light-weight UAV that cannot utilize external ground resources. The UAV is tasked to follow a moving target to plan appropriate paths as it identifies and adapts to environmental obstacles.

Additionally, this study explores the the possibility of utilizing aGISapplication onboard the flying drone to connect the local computation with stored geospatial data. These two problem areas are defined with the following two research questions:

• What local computational capabilities are necessary to provide theUAV the ability to autonomously surveil a specific target?

• What geospatial information can be stored locally to reduce the processing and communication required by theUAVto plan paths?

1.3 Scope of the thesis

This thesis aims to enable a lightweight UAV to track a target by keeping it within sensory range through path-finding heuristics. To avoid limitations and difficulties in maintaining connectivity with a ground-based infrastructure, this project seeks to determine the capabilities that need to be locally available toUAVs.

The goal of this thesis project is to define an evaluation model to test autonomous decision-making algorithms. This goal consists of the following subgoals:

1. Create an evaluation model that simulates a UAV in an environment with defined states, such as start state and end state, and perception mechanism.

2. Benchmark path planning algorithms in a 3D simulation where the UAV tracks a moving target. Metrics of algorithmic performance are processing time, distance from target, and memory consumption.

(25)

3. Interface the UAV agent with the Carmenta Engine to define a model where onboard computation has access toGISenvironment models.

1.4 Delimitations

This thesis work implements a target tracking evaluation model within simulation scenarios. It is therefore missing the practical realisation of a real drone flying in a real tracking situation. With a main focus on evaluating the path planning capabilities of a flying drone, other areas identified in the literature review are not investigated. This means that technologies related to the fields of information availability, UAV state estimation, and flight execution are adapted in this study for their relevance in recent research, but their functionality is assumed and not further explored. These fields contribute to many important influences that can impact the results of this study.

In the field of information availability, we assume the make and model of theUAVand the camera that the drone uses to locate itself in its environment.

We also assume that the moving target advertises its position to theUAV. A relevant alternative is the use of onboard target recognition, but this task is considered out of scope for this research study due to the complexity of recent research and the practical problem of combining it with obstacle avoidance heuristics that require the camera angle to be directed in front of theUAV. The make and model of the drone and camera impact theUAVstate estimation as it uses the hardware to understand its environment and detect potential obstacles.

1.5 Structure of the thesis

Chapter 2 describes the relevant information on foundational techniques in UAV navigation as well as a literature review of recent research. Chapter 3 outlines the methodology used to address the research questions and the details of the simulation environment. Chapter4 presents the results with analysis.

Chapter 5 discusses the results and presents conclusions. The chapter ends with proposals for future work and reflections on sustainability and ethical impacts.

(26)

Background | 5

Chapter 2 Background

This chapter provides background information onUAVnavigation and target pathing. Section 2.1 gives an overview of relevant technologies in the field of UAVs. Section 2.2 introduces the reader to UAV guidance. Section 2.3 reviews related work. The chapter concludes with a summary.

2.1 UAV technologies

The termUAVcan denote a wide variety of aerial vehicles from nano-drones weighing 10 grams [15] to massive 12 ton drones [17]. Depending on their application and capabilities, they carry a range of different sensors. This section gives an overview of the relevant technologies that exist along with related research and background information.

2.1.1 Types of UAVs

While UAVs can be grouped in different categories depending on different criteria, two main groups are fixed-wing and rotary-wing UAVs[18]. Fixed- wingUAVstend to be larger and used at a higher altitude. By creating lift from forward airspeed, fixed-wingUAVscan carry heavier payloads and can realize long endurance flights [19]. Rotary-wing UAVs include single- and multi- rotor helicopters. This type of UAV has greater manoeuvrability, making them useful for low altitude and hovering tasks. Single-rotorUAVshave two motors: one for controlling navigation and one for controlling the rotation of the helicopter. Multi-rotorUAVsare designated by the number of rotors they have and one common type is the quadcopter that uses four rotors. Micro Aerial Vehicles (MAVs), especially in the form of quadcopters, have seen

(27)

recent attention in the literature due to their applicability in swarm technology [20] and commercial use cases.

AGlobal Navigation Satellite System (GNSS)is a collection of satellites supporting location services. These location services are widely used in many mobile devices such as mobile phones, cars, and UAVs [21]. Using data from at least four visible satellites, a GNSS receiver can provide accurate positional data [22]. CommercialUAVsmay require data from up to 16 visible satellites before taking off [23]. In situations where GNSS satellite signals are unreliable or unavailable, anInertial Navigation System (INS)orInertial Measurement Unit (IMU) using internal sensors (such as a gyroscope and accelerometer) are used to estimate a relative position from an initial position [24]. Recent developments and refinements in INS and IMU technologies have madeGNSSreceivers augmented with such devices the preferred choice for near continuous positional and attitude data. INS and IMU systems on their own suffer from drift errors [24] that can build up and require occasional correction throughGNSSbased absolute position updates [25].

2.2 UAV guidance

Autonomous UAV guidance considers the path planning of a UAV through an environment given the location of objects within this environment, i.e., a given volume of space – the workspace. The planned path is subsequently used by a control mechanism to guide theUAVbetween two points [26]. This section begins with a description of approaches to sensor-based data collection and then moves on to path planning algorithms and related performance metrics. Figure2.1shows an overview of the interrelated processes (sensing, navigation, guidance, and control).

2.2.1 UAV information availability

The choice of UAV path planning algorithm depends on the type of information available about the environment. Additionally, the solutions depend on whether or not the environment is static or dynamic. Static environment solutions assume that the workspace does not change after an initial data collection. Static solutions are considered to have full knowledge of the environment [7].

(28)

Background | 7

Figure 2.1: Context ofUAVresearch. Inspired by Figure 3 from [1] and Figure 3 from [2]

With full knowledge of the environment, a path-planning algorithm can execute in three steps: decomposition, path planning, and execution.

Decomposition divides the environment workspace into three-dimensional cells to discretise the information. A path-planning algorithm searches the decomposed graph for a solution using predefined performance metrics.

Finally, the selected path is executed. With full knowledge of the environment, the execution is generally insensitive to any external interference that might cause the UAV to deviate from the planned path. However, exception fail- safes may cause theUAVto break away from the planned path [19].

In contrast, in a dynamic environment, information constantly changes.

Dynamic environments require theUAV to carry on-board sensors to gather environment data. These sensors provide additional information to supplement the incomplete knowledge of the environment. However, this introduces the challenge of dynamically constructing and maintaining an environment map.

To execute theUAV’s mission, this map must be updated sufficiently often to deal with the relevant dynamic behaviour of the environment [19].

Different classifications of flight modes employed inUAVguidance with

(29)

varying degrees of autonomy have been described by J. Poza-Luján et al.

[27]. These flight modes start with manual flight, where a remote pilot controls all aspects ofUAVnavigation. With the addition of proximity sensors, the UAV’s software can assist in reactive manoeuvres to avoid obstacles.

Deliberative Flight Mode describes the manual control of aUAV’s flight with the autonomous awareness of not flying into no-flight zones, such as power lines or populated areas. Guided Flight Mode provides an additional level of autonomy where a human pilot defines a flight plan and the UAV carries it out fully autonomously. The final degree of autonomy is Smart Flight Mode, where the UAV is completely autonomous, i.e., it finds its own path while taking into account obstacles, restricted areas, and surrounding areas.

2.2.2 UAV navigation

Y. Lu, Z. Xue, and L Zhang [28] identified three types of UAV navigation methods: inertial navigation, satellite navigation, and vision-based navigation.

Because of their individual drawbacks, none of the three navigation approaches are used in isolation. Recent developments in computer vision algorithms have made the application of vision-based navigation an active area in the literature [1].

GNSS technologies lack the precision, assured reception, and range necessary for lightweightUAVsto navigate in urban environments and indoors [25, 29, 30]. To allow UAVs to navigate in such scenarios, remote sensing techniques, such asSimultaneous Localization and Mapping (SLAM), allow a mobile agent to generate a map of its environment without a priori knowledge and determine its own location relative to perceived objects [31]. SLAM and its variants have had great success in many mobile agents [32], including airborneUAVsystems [31,33]. An issue withSLAMmethods comes from the reliance on INS systems to provide attitude and coordinate data. SinceGNSS services may not be available to correct estimation errors, the environment map can be skewed - this is called pose drift. Tracking each observed object leads to a quadratic growth in computational complexity with the number of objects in the environment. Optimized versions ofSLAMexist that relax the computational requirement by tracking as many objects as possible with the available computational resources [34].

Recent research has observed that the map-heavy requirement of SLAM solutions forcesUAVsto move slowly and advocates more optimized solutions

(30)

Background | 9

that better fit the needs of high-speed UAV navigation. Motivated by the observation that only the most recent window of sensory input is necessary to plan obstacle-free motion, UAVs do not need to maintain a computationally expensive environment map. NanoMap [35] utilizes a sliding observation window to provide an effective mapping model that is capable of quickly navigating through a thick forest. This mapping solution also solves the issue of pose drift. Unlike other reactive navigational implementations, such as optical flow, NanoMap retains a history of estimations. When the planned trajectory lies outside its (current) field of view, this history is used. The authors of NanoMap showed that their Intel NUC i7 flight hardware was sufficient for their computations [36]. In forests, they achieved top speeds of 10 m/s. Similar approaches and results are reported in articles by D. Dey et al. [37] and Gao et al. [12].

In many cases, the degree of dynamism in world knowledge can be relaxed to constitute a partial knowledge of the environment workspace.

When a complete 3D environment model is available, model-based tracking uses feature detection to obtain a 3D position and orientation [38]. Model- based tracing is commonly used in augmented reality and robotic object manipulation. However, inUAV navigation, J. Li-Chee-Ming [39] proposed a pose estimation framework using existing 3D models to match line features with a streaming camera’s output.

2.2.3 UAV target localization

Efficient vision-based object detection is challenging for autonomous UAVs because of the limited resolution and detail of aerial cameras [40]. In 2006, M. Wheeler et al. [41] expressed this concern in their UAV framework for cooperative tracking and used a remote pilot to manually keep a target within the frame of theUAV’s camera. At the time, research involving autonomously tracking of objects distinct from their environment saw greater success [40].

For example, J. Tisdale, Z.Kim, and J. Hedrick [42] implemented on-board image processing on a fixed-wing UAV to calculate the likelihood that an image contained a red tarp. A similar example using quadcopters is found in B. Bethke, M. Valenti, and J. How’s article [11] where they used lightweight UAVs that stream video from its camera to a central image processing server that measures image intensity and return a filtered blob location to the drones.

More recent research involving colour signature detection can be seen in

(31)

J. Sun et al. [14] where on-board image processing is used to look for a specific colour signature. Once this signature is found, the image is sent to an operator who can do extensive postdetection identification. The use of on-boardUAVcolour signature detection has found its way into commercial drone manufacturers. The current market leading [43] drone manufacturer DJI features their ActiveTrack [44] technology that uses distinct colours to distinguish the target from the background.

Another approach to UAV target detection research is motion-triggered algorithms. For example, S. Minaeian, J. Liu, and Y. Son [45] use ground- based autonomous vehicles to detect motion that in turn enables aUAVto map out the area from the air and return the exact location of the moving objects based on trigonometry between known landmark locations. Another common localization method uses various versions of the Kalman filter to predict likely movements of a target [41,46].

Alternative methods employed byUAVsto detect specific objects include laser sensors detecting power lines and objects around them [47]. T. Furukawa et al. [48] uses sensory sensitivity to look for a specific sensor signature emitted by lifeboats to search an ocean for survivors.

In terms of lightweightUAVtarget detection, L. Meier et al. [2] in 2011, were the first to implement on-board image processing. Using ARCore^†, they could decode encoded markers that contained geospatial references. The use of local computation enables their swarm of UAVs to move without having connectivity to a ground station, thus avoiding a range limitation. Stereo cameras captured 3D depth information. Their system placed a 10% load on their Intel Core 2DUO when decoding the visual markers and 70% system load while conducting object avoidance.

In image processing, a popular object detection method is various implementations of edge detection. Siam et al. [46] used the Features from Accelerated Segment Test corner detector to cluster predefined targets, such as vehicles, and then extract their location. Moranduzzo et al. [49] used Scale Invariant Feature Transform to classify edge detection points to count the number of cars in images taken fromUAVs.

Deep learning applications forUAVtarget detection have increasingly been

† Google’s ARCore is a software development kit for augmented reality.

(32)

Background | 11

adopted within the field of computer vision – with the limiting factor being embedding powerful enough hardware to run inference on-board lightweight UAVs[50]. Therefore, such systems typically assume that the data is streamed to a powerful computer that runs the deep learning model [16]. However, recent research shows that deploying convolutional neural network (CNN) mapping technology on nano-drones is viable [15], which may indicate that such limitations are soon irrelevant.

2.2.4 UAV path planning algorithms

When tracking a detected target, a UAV needs to keep the target within its sensory range. This might require the drone to follow the target in an environment that is not free of obstacles and blind spots. Planning-algorithms further optimize their solutions using additional attributes, such as minimizing energy expenditure, total path length, and probability of destruction [51].

Looking at research trends from a 2018 survey by Y. Zhao, Z Zheng, and L. Yang [51], path planning algorithms can be classified into online and offline algorithms. Online path planning algorithms compute UAV paths in real time, thus they are used when changes in the environment can be identified and incorporated into continuous planning. Offline path planning methods compute paths using the available information. Furthermore, Y. Zhao, Z Zheng, and L. Yang noted that 29.9% of research concerning UAV path planning since 2008 were online methods and they saw an increasing trend in the use of online methods. Within online methods, the Genetic Algorithm and Fuzzy Logic path planning algorithms have seen the most attention with neural networks and learning-based applications steadily increasing. They identified further trends inUAV path planning algorithms with 2D and 3D methods in equal proportions in 2018. In 2D space, paths are computed assuming that the UAV maintains a constant altitude. IntricateUAVenvironments increasingly require 3D space solutions; however, the additional dimension adds to the complexity. Fortunately, recent development in hardware capabilities has made 3D planning viable.

A state-of-the-art path-planning algorithm presented in the 2015 article by P. Yao, H. Wang, and Z. Su [52], describes an online 3D path planning algorithm for a UAVtracking a moving target in a complicated environment with static and dynamic obstacles. Using Lyapunov Guidance Vector Field, Interfered Fluid Dynamical Systems, and Model Predictive Control, a real-

(33)

time path could be generated within a planning time constraint. Their study was implemented in Matlab using an Intel i5 processor and takes into account variable parameters such as UAV turn rate, flight path angle, and detection radius to generate feasible paths.

In their 2018 survey, M. Radmanesh, M. Sarim, and M. Kumar [53]

compare common offlineUAVpath planning algorithms using a set of scenarios consisting of 2D grids of various sizes and contents. While they recognize that the algorithms have application-specific advantages, in general, they confirm the trade-off between optimality and computational time. Optimality in this case represents the exactness of the generated path compared to the perfect path within some error tolerance. The Multiserver Location-Allocation Problem algorithm was found to be fastest but not always optimal, while their own genetic algorithm was not as fast but the paths were within their error tolerance. The Mixed Integer Linear Program algorithm found optimal solutions faster than other optimal solutions such as A* and Dijkstra’s shortest path algorithms.

ForUAVsthat perform repetitive tasks, such as flying a fixed surveillance route, a machine-learning based approach can be beneficial in both imitation and reinforcement learning [54]. The sequential nature of UAV path points motivated K. Kelchtermans and T. Tuytelaars to use a Recurrent Neural Network Long Short-Term Memory network [55] that learns to fly across a room containing obstacles. The sequential approach takes the current environment as input to calculate the current optimal navigational action, so it is an online pathing algorithm. Although they comment that their infrastructure can run on board, their system details were not presented.

2.3 Related works

The task of tracking a moving car using the local computational resources of a small fixed-wingUAVwas addressed by C. J. Neal in 2014 [56]. Using an Atmel 2560 on a small model plane, their system was able to use a finite- state machine to track a moving target. Their target carried a transponder capable of sending location updates to the UAV, which prompted the UAV to reevaluate its behaviour according to the defined state. Comparing their approach to existing autopilot Follow-Me software, they achieved 60% better performance. This is largely because of their system’s ability to shift the state

(34)

Background | 13

from following to loitering, when the target stood still. Their performance is calculated by the difference between the preferred and actual distance to the target, and the difference between the desired slant range compared to the actual slant range. Although no specific system expenditure is defined, Neal points to previous work that theorized a 30% increase in flight endurance.

This thesis differs from Neal’s study as it uses a hovering quadcopter instead of a fixed-wing plane. This difference implies that this project must take into account a lower endurance because theUAVis a hovering quadcopter.

However, the use of such a UAV also implies more fine-grained movement control. Additionally, this project is interested in more complex decision algorithms that can optimize on multiple goals such as identifying potential blind spots and undesirable regions.

Autopilot is a software system packaged into many UAV systems. By replacing human input, an autopilot allows a UAV to autonomously perform simpler tasks such as take-off, waypoint flight, and landing. In addition to the mission defined by the remote pilot, the autopilot also handles self-checking, calibration, data processing, and redundancy management. In a 2016 survey, Y. Zhaolin, L. Feng, and B.M. Chen [57] reviewed the most common autopilots found in quadcopters: Pixhawk, DJI, NAVIO2, Snapdragon, OcPoC, and Trinity. Each of these will be described further in the following paragraphs.

Pixhawk [58] is a popular UAV platform due to its open source and open hardware design. The 32-bit Cortex M4 allows the Pixhawk to run the PX4 autopilot to perform hold, return, mission, takeoff, landing, follow- me, and offboard actions. None of these actions fall under the Smart Flight Mode definition defined by J. Poza-Luján et al. [27] and the follow-me implementation uses the target’sGlobal Positioning System (GPS)coordinates to follow at a predefined distance. Y. Zhaolin, L. Feng, and B.M. Chen [57]

state that due to limited computational resources, high-level vision algorithms are impossible to execute.

The DJI autopilot is found in the range of commercial drones manufactured by DJI. With the exception of DJI’s ActiveTrack, they offer the same autopilot features as Pixhawk, but their implementation and system details are unavailable.

NAVIO2 uses a Raspberry Pi 3 model with the quadcore ARM Cortex-

(35)

A53 processor, which is a more powerful processor than described above for the Pixhawk. The increased resources enables the use of high-level visual algorithms. Navio2 uses the open-source ArduPilot [59] software that allows access to low-level routines and high-level missions. Among the modes available in ArduPilot, the most autonomous mode is SmartRTL [60] where theUAVperforms a smoothed retrace of its path to return home. The capacity of this mode is directly dependent on the buffer size containing the saved navigation points.

Snapdragon [61], OcPoC [62], and Trinity [63] offer further advanced hardware implementations that extend the redundancy, parallelism, and other logical resources. OcPoc uses the same PX4 autopilot software as the Pixhawk. However, Quantum Systems’ Trinity uses their proprietary QBase3D allowing mission and route planning. None of these functionalities fall into the category of Smart Flight Mode.

While no autopilot software today offers Smart Flight Mode services that involves local path planning, the software solutions solve many important subproblems involving stability, wind calibration, and redundancy management that are integral parts of autonomous flight. The review by Y. Zhaolin, L. Feng, and B.M. Chen also provides the insightful conclusion that increasingUAV performance can occur both due to the increase in computational power and by reducing the power consumption [57].

2.4 Summary

Based on the existing literature, the prevalent issues in local autonomousUAV target tracking are the lower endurance of a quadcopter, object detection and tracking, and the adaption to real-time stimuli that change the course of a planned path. There are novel approaches that solve many of these issues, but they rely on a ground-based computation to help perform the computation.

This literature review finds that there is a need for an evaluation of novel approaches in the context of localUAVcomputation.

(36)

Research Methodology | 15

Chapter 3 Research Methodology

This chapter describes the experimental research applied to address the research questions. Starting with Section 3.1, a formal description of the research process is outlined. Section 3.2 describes the strategy used to implement a simulation environment that is suitable for answering the research questions. Section 3.3 gives a brief overview of the simulation architecture to explain and give context to the technologies used. Section 3.4 details the theoretical background of the underlying algorithms to explain how they work together to accomplish the target tracking task. Then, Section 3.5 describes the simulation setup used to model the target tracking scenario and the implementation evaluation metrics. Section 3.6 explains the setup of the hardware used to apply a real-world scenario for onboard drone computation.

Finally, Section3.7describes theGISimplementation used to connect external world knowledge with the path-planning implementations.

3.1 Research process

The project began with a literature study to analyse existing research results and approaches that motivate the research questions and provide the author with sufficient background to carry out the rest of the project. Because the research questions concern practical implementation and evaluation experimental research was applied to develop a simulation environment.

Relevant system data from the methods applied in the simulation guided the further development of the implementation. Evaluation metrics consist of algorithmic performance and system load to quantify the metric for success.

Finally, with the support of an analysis of the experimental data

(37)

final conclusions are drawn and put into context with the research questions.

3.2 Strategy

The literature study was conducted on background technology, hardware, and software related toUAV target tracking. The results of that study lead to the PX4 flight stack and autopilot being selected to constitute the framework of the simulation environment with Gazebo as the physics engine. Primarily, these technologies were chosen together for their cooperative support for simulating drones in software. To control the PX4 autopilot, a companion computer running theRobotic Operating System (ROS) framework was set up to allow the PX4 flight stack to run in an Offboard mode, sending sensor information and receiving control instructions back. The reason for choosingROS is its widespread use in the open-source community and relevance to the field of robotics. Within the ROS framework, the PX4 Avoidance framework [3]

provides two standalone waypoint generation algorithms, A* and gls3DVFH*, for obstacle avoidance that were adapted in this project to follow the moving target. These algorithms represent two levels of algorithmic complexity according to their approach to storing perception data. The moving target was designed as a standalone Gazebo plugin that would command an actor to follow a scripted path. The position of this actor was then advertised through ROS and picked up by the UAV. The simulation world itself was modelled using Gazebo. By monitoring the performance of the ROS nodes and their underlying implementation, the algorithmic performance, distance to the target, and memory consumption were observed and recorded. More information about PX4,ROS, Gazebo, A*, and3D Vector Field Histogram*

(3DVFH*), and their usage in this simulation environment are given in their respective sections 3.3.1, 3.3.4, 3.4.1, and 3.4.2. The simulation setup was then extended to replace the target’s scripted path with a random walker, and the modelled world with a procedurally generated world. This was done to evaluate the target tracking implementations in many different environments.

This setup sought to match the intent of the first research question and give an answer to what local computational capabilities are required for a UAV to autonomously pursue a target. To address the second research question concerning whatGISdata could be stored locally, aROSnode was developed to wrap around a Carmenta Engine application and bring it into the ROS control framework. The application using the Carmenta Engine in turn, was

(38)

developed to access static GISdata and return geospatial insights relevant to the target tracking scenario. More information on the architectural setup and requirements for this is described in section3.7.

3.3 Architecture and technology

There are three independent environments making up the simulation experiments. As shown in Figure 3.1, the PX4Software in the Loop (SITL) environment controls the flight stack whose sensors and actuators are simulated in a Gazebo physics simulation environment to provide streams of sensor outputs that replicate those required during a real flight. The third environment is the companion computer running ROSwho provides the flight stack with the flight control instructions. This environment is duplicated with different network connections in the figure to reflect the difference between running the companion computer on the laptop and on the real-world hardware Raspberry Pi 4. The flight control is forwarded to the companion computer by using the PX4 Offboard mode, which allows the sensor stream and controls to be forwarded toROSnodes using theMAVLink extendable communication node for ROS (MAVROS)[64,65]. The technologies for each environment will be further described in the following sections.

3.3.1 PX4

The PX4 autopilot by DroneCode is an operating system designed for multiple types of drones and aircrafts that make PX4 suitable for a broad range of UAV research applications. With a vibrant open-source community, the PX4 autopilot is one of the most popular autopilot platforms today. Internally, a PX4 flightstack consists of a flight control system, drivers for sensors, and embedded hardware and communication modules. The implementation of this flightstack is highly modular and different logical components communicate via message passing [66]. In Figure3.1, a simplified view of these components can be seen in the PX4 SITL node. As explained in Section 2.3, the PX4 flight stack supports various modes that allows the drone to perform actions such as hover, take-off, and waypoint flight. To realize the mission of autonomously tracking and following a moving target, the flight control has to be outsourced to a companion computer. This is part of the flight mode called Offboard, which forwards the sensor input to the companion computer,

(39)

Figure 3.1: Architectural overview of the complete simulation setup. These three environments run independently of each other and communicate through message passing. While this diagram reflects the desired setup, subsequent tests show that the nodes with asterisk currently can only run in a laptop.

expecting to receive back a constant stream of navigational instructions. While the flight control is forwarded to the companion computer, the flight stack itself remains in control of low-level routines such as converting flight instructions to actuator output, calibrating its navigational sensors, and keeping the drone’s position constant in the sky despite external influences like wind. This project leaves the internal implementation of the PX4 flight stack unchanged. The flight control abstractions expressed through the MAVROS communication framework allow higher-level control routines to interface with the actuators.

The navigational instructions expected by the PX4 drone can therefore be expressed in terms of the desired position and attitude, and these will be internally translated to actuator instructions [67]. In Figure 3.1, this can be seen in the PX4 SITL node’s connection between the flight control and

(40)

MAVLink node. MAVLink is a communication driver that handles the communication with external resources, such as connected hardware and network interfaces. More information about MAVLink can be found in Section 3.3.2.

The PX4 SITL solution allows developers to simulate UAVs to test algorithms and routines while collecting simulated system values. In this thesis project, a simulated Iris quadcopter [68] equipped with a front-facing stereo camera is used. The specific dimensions and capabilities assumed are summarized in Table3.1.

Table 3.1: Iris drone specifications

Property Value

Height 10 cm

Width 50 cm

Weight 1282 g

Payload capacity 400 g

Battery 5100 mA h 3S^†

Flight time 15 min to 20 min

Flight speed 11 m/s

Camera Intel Realsense^R ^TMCamera R200

The Offboard mode allows a companion computer to send flight instructions in the form of position, velocity, and attitude to control the drone’s state. Collectively denoted as setpoints, the Offboard mode requires the connected companion computer to stream setpoint messages at a rate exceeding 2 Hz to enable and remain in the Offboard mode. If the message stream falls below that rate, the flight control will invoke a failsafe action to switch its flight mode to the previously enabled mode. To ensure connectivity with the companion computer over MAVLink, the Offboard mode also requires that the companion computer send heartbeat acknowledgements at regular intervals of less than 2 s. Exceeding that timeout will also result in the flight control invoking its failsafe action.

To start a PX4 drone in Offboard mode, explicit state changes need to occur before it takes off. The same requirements are also required in software

† This is three cells in series for 11.1 V DC.

(41)

simulations. First, the drone has to be armed. Arming the drone sends power to the actuators which in turn allow the propellers to spin. In an armed state, the drone can switch to appropriate modes like Takeoff, Loiter, and Offboard.

3.3.2 MAVLink

Micro Air Vehicle Link (MAVLink) [65] is a messaging protocol designed for communication betweenUAVsand internal drone components. Following a publish-subscribe and peer-to-peer design pattern, MAVLink enables data streams to be published as topics and configurations such as parameters, commands, and flight plans to be transmitted point-to-point with retransmission. MAVLink is designed to be lightweight and consists of a library suitable for platforms with limited RAM and communication bandwidth.

This is achieved with prebuilt header-only libraries at each end of the communication network. Messages are defined in XML schemas called dialects where common and vendor-specific message structures are predefined.

Custom messages are implemented by defining the message structure and compiling the library header with MAVLink links. To integrate MAVLink with the companion computer, an extended version of MAVLink called MAVROSis required. MAVROSacts as a bridge between the message types defined inROSand PX4.

3.3.3 Robotic Operating System (ROS)

TheRobotic Operating System (ROS)[69] is a framework that is used to build robot applications. The architecture of ROSstrives to serve as an operating system with features such as service abstraction, message passing, and package registration. The packages written inROSare called nodes. Each node is able to communicate with other nodes using asynchronous message passing over topics, synchronous remote procedure calls, or use a shared memory called the Parameter Server. At runtime, theROSenvironment maintains a master node that tracks publishers and subscribers, services, and the Parameter Server.

Nodes that want to communicate must first query the master node about the location of the other node before they can start peer-to-peer communication.

The communication over topics is a publish-subscribe design pattern where messages are data structures defined in message files.

(42)

TheROSframework is built as a distributed computing platform that also features cross-network communication. Using cross-network communication, nodes on different (physical) machines can communicate. Nodes on different machines communicate with each other across machines as long as they are registered with the master node. Section3.6 further details the multimachine setup used in this project to enable hardware-based simulation experiments.

In this project, ROS is the backbone of the implementation of autonomous target tracking. Various services, packages, and tools are connected to allow theUAVto autonomously follow the moving target. More information about the nodes and implementation’s structure can be found in Sections4.1.1and 4.1.2.

3.3.4 Gazebo

Gazebo [70] is a simulation environment with a physics engine specifically designed for robotic systems. Due to its ROS package integration, Gazebo allows robotics developers to replicate real-world scenarios to perform system evaluation and testing without running the robot on the actual equipment. For drones, this is an especially attractive approach to ensure the systems work as intended before real-world tests. PX4SITLintegrates with a Gazebo simulator plugin to allow sensors to behave in the same way as they would in the real world, by providing an endpoint for message-passing and topic dissemination.

Therefore, subsequent real-world tests are easily done by replacing the Gazebo endpoint. In Figure 3.1, the Gazebo node contains an Iris drone node and a moving target node, representing the two actors populating its Gazebo environment.

A Gazebo plugin can be attached to the simulation to programmatically control aspects of the simulation, such as where sensors publish their data stream and how models receive commands to move around. Such a plugin was developed for this project to allow an object to move around so that the drone had a moving target to follow. To integrate the moving actor with the target tracking scenarios, the actor advertises its positional information on the ROStopic called /target_position with the P oseStamped type.

(43)

3.3.5 RVIZ

Rviz [71] is a 3D visualization tool provided by the Open Source Robotics Foundation that is built to present complex data structures and algorithms visually. This project used rviz in the development of target tracking implementations to show the data being produced and provided to the drone.

This visual information in turn is helpful when debugging issues and to conretize algorithmic concepts. Examples of visualization can be found in Section 4.1.1 to visualize the Pointcloud datastructure in 3D space, and in Section3.4.2to visualize the Octree data discretization.

3.3.6 PCG_Gazebo

PCG_Gazebo [72] is a python package developed by Bosch Research [73] to provide a procedural generator of Gazebo environments. The package was developed to generate and combine models, worlds, and materials to be used in Gazebo simulations. This project uses the pcg_gazebo package to set up a Gazebo world where random obstacles are placed at random coordinates.

A target tracking simulation can then use this world to let each waypoint algorithm implementation track a moving target. Using configuration files, the package can parse model specifications to populate an empty world with shapes and models. Furthermore, a Gazebo plugin can be referenced and attached to the model so that custom ROS behaviour is realized. More information about the configuration used in this project can be found in Section 3.5.3.

3.4 Target tracking implementation

This section explains the two waypoint algorithms used to plan paths and gives a theoretical background of their internal logic and decision-making.

First, gls3DVFH* is explained in Section3.4.1, then A* in Section3.4.2. The section ends with a specification of the numerical parameters used and an explanation of the environmental knowledge technologies used by the UAV to position itself.

(44)

3.4.1 3DVFH*

The first waypoint generator in PX4 Avoidance is the 3D Vector Field Histogram* (3DVFH*) algorithm [3]. 3DVFH* is an amalgamation of the reactiveVector Field Histogram (VFH)motion planner and an A* search. Given the point cloud from a stereo camera, the algorithm starts by building a histogram where each index represents a 3D point. While a regular VFH implementation would select the histogram index that is free of obstacles and leading towards the goal, VFH* incorporates a memory feature that takes the histogram from the previous timestep and merges with the current histogram. This merge is selective and aged-based so that the storage and processing impact is kept low. The benefit of the memory is that the algorithm can determine possible flight directions and therefore escape local minima and fly around obstacles. This memory is evaluated with an A*

search and uses the cost heuristics shown in Equation 3.1. In this equation, the parameter λ^depth represents a scaling penalty for cells further away from the current position. The k parameters represent unique weights that scale the respective cost parameters. All weighted costs are summed together. The parameter c_targetdescribes the angular difference between the current cell and the direction towards the goal, c_yaw describes the angular difference between the current state of the drone and the direction towards the goal, cpathdescribes the angular difference between the current node and the parent node, and ctree

describes the similarity of the current search tree and the previously traversed search tree. The 3D aspect of this algorithm enables its application in a 3D environment.

c_n= λ^depth· (k_target· c_target+ k_yaw· c_yaw+ k_path· c_path+ k_tree· c_tree) (3.1) Figure3.2 shows the logic behind3DVFH* as it generates paths. In the logical flow, the A* search is used in the Tree direction node. The search is not used when the tree structure is being constructed or maintained. In those cases, 3DVFH* uses a simpler costmap to determine the appropriate direction. This costmap is maintained during the histogram construction and fusion phase. The cost heuristic used is defined in Equation3.2. The cost of a candidate direction is the sum of the yaw difference (cyaw), weighted cost of velocity change (c_velocity), weighted difference in pitch up (c_{pitch_up}), and weighted difference in pitch down (c_{pitch_down}). The difference is calculated between the goal position and candidate direction. The pitch differences are weighted differently to encourage manoeuvres in the lateral direction as these are considered safer than altitude changes. This assumption is based on the

(45)

drone’s build where the camera is facing forward, thereby leaving the drone’s immediate vertical area unknown. Equations 3.3 and 3.4 combine this cost with previous directions to create smoother flight paths.

c_goal = k_velocity · c_velocity + c_yaw+ k_pitch· c_{pitch_up}+ k_pitch· c_{pitch_down} (3.2)

c_smooth = k_yaw(p_old, p) + k_pitch(p_old, p) (3.3)

c_total = k_goal· c_goal+ k_smooth· c_smooth (3.4)

Figure 3.2: 3DVFH* waypoint generation. Inspired by the explanation given by [3].

With the logic defined in Figure3.2,3DVFH*also depends on a number of parameters to tune and customize its behaviour for different scenarios. These parameters and their usage are defined in tables 3.2 and 3.3. Rows with a symbol show that the parameter is referenced in one of the mathematical equations above.

(46)

Table 3.2: 3DVFH* parameter description (1 of 2)

Symbol Name Description

Max sensor range Maximum range of camera sensor. Data points exceeding this distance will be discarded. A large maximum distance increases the number of points to process and in turn increases the required processing.

Min sensor range Minimum range of camera sensor. Data points less than this distance will be discarded. This threshold is useful to ignore unreliable data points due to noise and lightning. This limit is influenced by the camera hardware used. The RealSense camera assumed in this project defines a minimum distance of around 20 cm while its recommended minimum distance is 50 cm.

k_pitch Pitch cost Weight placed on the cost calculation related to angular difference.

kyaw Yaw cost capacity Weight placed on the cost calculation related to difference in yaw.

kvelocity Velocity cost Weight placed on the costmap calculation cost calculation related to velocity difference.

ktarget Obstacle cost Weight placed on the cost calculation related to angular difference.

ktree Tree heuristic weight Weight placed on the cost calculation related to the similarity of traversed trees.

Goal z Desired flight altitude.

Timeout startup Timeout interval at startup before Offboard mode is relinquished to the previously enabled flight mode.

Timeout termination Timeout interval at runtime before Offboard mode is relinquished to the previously enabled flight mode.

3.4.2 Risk-based pathfinding using A*

The second waypoint generator in PX4 Avoidance is the risk-based A*

algorithm [3]. Instead of a histogram, this algorithm is based on an Octree [74]

data structure to discretize its environment and to be able to generate a path with minimum cost. The cost heuristics used in the A* implementation can be seen in Equation 3.5 where n represents the node currently being evaluated.

To calculate the cost, a risk calculation is required for the parameter c_riskand

(47)

Table 3.3: 3DVFH* parameter description (2 of 2)

Symbol Name Description

Max point age Defined maximum number of iterations a detected point is remembered. The age of points influence the number of points actively being tracked, but allow theUAVto handle increasingly large local minimum.

Min num points per cell Minimum number of points for one cell.

Points who add up to less than this threshold are discarded as noise. .

ksmooth Smoothing speed xy Smoothing effectiveness in the X and Y axes.

Used in combination with smoothing speed z in matrix multiplication.

ksmooth Smoothing speed z Smoothing effectiveness in the Z axis. Used in combination with smoothing speed xy in matrix multiplication.

Smoothing margin degrees Smoothing radius applied to finished costmap.

Children per node When searching through candidate directions, only a limited number of branches are evaluated at each node. The branches searched are chosen best-first according to their calculated cost.

N expanded nodes New nodes are added to the search tree until this limit is reached.

Tree node distance Defined distance between two nodes.

is defined in Equation 3.6 where p describes the cost of the altitude, while prior describes the normalized sum of probabilities that the discretized cell contains an obstacle. The number of cells in a node depends on the resolution of the Octree data structure and the probability that it contains an obstacle.

The parameter cexplore describes the multiplied weight of nodes believed to be free space. Then, as seen in Equation 3.7, a check is done to see if the neighbour exceeds a k_{max_risk} parameter and decides if the search should be aborted early. Adding the risk of the previous node, the cost between the node and its neighbour is defined as the sum of the difference between a node and its parent regarding distance, risk, and smoothness, with the latter two

UAV Navigation using Local Computational Resources

UAV Navigation using Local Computational Resources

Keeping a target in sight MAGNUS CARDELL

UAV Navigation using Local Computational Resources

Keeping a target in sight

MAGNUS CARDELL

Abstract

Keywords

Sammanfattning

Nyckelord

Acknowledgments

Contents

List of Figures

List of Tables

Listings

List of acronyms and abbreviations

Chapter 1 Introduction

1.1 Background

1.2 Problem

1.3 Scope of the thesis

1.4 Delimitations

1.5 Structure of the thesis

Chapter 2 Background

2.1 UAV technologies

2.1.1 Types of UAVs

2.2 UAV guidance

2.2.1 UAV information availability

2.2.2 UAV navigation

2.2.3 UAV target localization

2.2.4 UAV path planning algorithms

2.3 Related works

2.4 Summary

Chapter 3

Research Methodology

3.1 Research process

3.2 Strategy

3.3 Architecture and technology

3.3.1 PX4

3.3.2 MAVLink

3.3.3 Robotic Operating System (ROS)

3.3.4 Gazebo

3.3.5 RVIZ

3.3.6 PCG_Gazebo

3.4 Target tracking implementation

3.4.1 3DVFH*

3.4.2 Risk-based pathfinding using A*