unmanned aerial vehicle real-time guidance system via state

Transcription

UNMANNED AERIAL VEHICLE REAL-TIME GUIDANCE
SYSTEM VIA STATE-SPACE
HEURISTIC SEARCH
MANUEL SOTO
Department of Electrical & Computer Engineering
APPROVED:
Patricia A. Nava, Ph.D., Chair
Benjamin C. Flores, Ph.D.
Jack F. Chessa, Ph.D.
Thompson Sarkodie-Gyan, Ph.D.
Pablo Arenaz, Ph.D.
Dean of the Graduate School
Copyright
by
Manuel Soto
2007
Dedication
I dedicate this Master’s Thesis to those who supported me in this effort. First and foremost:
Thank you God. Second, my eternal gratitude goes to all my family: to all of my friends, cousins,
aunts, uncles, sisters, mother, and father. To all of you; I love you and I thank you for your
encouragement, for your patience, for your advice, and most of all for your prayers.
To Veronica—my beautiful lady; thanks for caring and for loving me. To my numerous cousins:
your guidance and your being there for me are always greatly appreciated. To my numerous
aunts and uncles: thank you for sharing your wisdom and experience, and thank you for giving
me your advice. To all my friends and family; thank you for all your help, support,
encouragement, and prayers.
Dad; had you not taught me to work hard, to use my brain, and to do quality work, I don’t know
if I would be an engineer today; I don’t know if I would have completed this advanced degree;
and I don’t know if I would enjoy working in my profession as much as I do. Thanks again Dad.
Lastly, to my God in Heaven, who sits next to His Son, Jesus, and who blesses us with His Holy
Spirit: Thank You.
UNMANNED AERIAL VEHICLE REAL-TIME GUIDANCE
SYSTEM VIA STATE SPACE
HEURISTIC SEARCH
by
MANUEL SOTO, B.S.E.E.
THESIS
Presented to the Faculty of the Graduate School of
The University of Texas at El Paso
in Partial Fulfillment
of the Requirements
for the Degree of
MASTER OF SCIENCE
Department of Electrical & Computer Engineering
THE UNIVERSITY OF TEXAS AT EL PASO
December 2007
Acknowledgements
I would like to thank both Dr. Patricia A. Nava and Mr. Luis E. Alvarado for their effort
and support in this project which began as a research study and has evolved to a real-world
system. Their guidance, collaboration, and mentoring support has yielded a publication in the
American Institute of Aeronautics and Astronautics, a presentation at the National Defense and
Industrial Association conference, and a real-time guidance system that is currently undergoing
empirical testing on DFCS. To Mr. Luis E. Alvarado, I would like to express my sincere thanks
and gratitude for entrusting me to this project, and to Dr. Patricia A. Nava, I would also like to
express my sincere thanks and gratitude to her for her acceptance, guidance and feedback on this
project. I feel blessed that I was provided with such excellent mentors.
My DFCS team, consisting both of Government contractors and of Government
personnel, has my appreciation for the help they provided in defining, designing and developing
the components for making this system realizable. The Government contractors, UNITECH and
Proteus, and the RO-CR-C Government personnel greatly assisted in providing the much
required projects needs, which were used to develop the product specifications and its design.
Arron Hardesty: thanks for writing the UDP class that links the RTPP to DFCS. Dr. John D.
Medrano: thank you for helping create the dynamic array class. Lupita Soliz: thank you for the
explanations about an algorithm’s running time. Gary Montana: thanks for allowing me to bench
test the console computer prototype; it was very useful for both running and developing the TMC
and the RTPP. Dan Cullen: thanks for helping me get this project started. Pat Kearny: thank you
for explaining terrain masking. Paul Berger: thank you for the discussions about the different
coordinate systems for representing the surface of WSMR. Gary Hakenson: thanks for providing
the equipment for linking the RTPP to the DFCS real-time computer network. Myron C. Moore:
thanks for proofreading the AIAA manuscript. Eugene Lawson: thanks for your assistance in
helping me design the RTPP graphics.
v
I would also like to thank the NewTech engineering team for their assistance; Perry
Hutchinson and Jeff Brickley: thank you for helping me to understand OpenGL and DTED.
To my Thesis Committee: Dr. Benjamin C. Flores, Dr. Jack F. Chessa, Dr. Patricia A.
Nava, and Dr. Thompson Sarkodie-Gyan—thank you for reviewing my work.
To my employer, UNITECH, whose tuition reimbursement support helped to make
graduate school less costly for me, I am grateful. I am also eternally grateful to two individuals
whose support and encouragement, both personal and professional, carried me through this
project and through the toughest times of graduate school: Herbert Saxman and Guadalupe
Arellano. Finally, to my father, Modesto Soto, I would like to express my love and gratitude for
his advice, help, and support in this Thesis, my previous educational endeavors, and in life.
vi
Abstract
This Thesis focuses on the research, implementation, and empirical testing of a real-time
(RT) Unmanned Aerial Vehicle (UAV) guidance system—the Real-Time Path Planner (RTPP).
The RTPP was created for the following reasons: (1) proof-of-concept, i.e., to verify the realworld feasibility of developing a real-time guidance system by using AI techniques; (2) benchmarking, i.e., to create a platform for using the most promising Artificial Intelligence (AI)
theories; (3) to show that a real-time guidance system is beneficial to existing Department of
Defense (DoD) Target Command and Control Systems (TCCS). In this study, the RTPP
undergoes empirical testing on an operational DoD TCCS called the Drone Formation Control
System (DFCS). This testing is conducted by linking the RTPP to the DFCS real-time computer
network. The RTPP provides flight-patterns to be used in 6-Degree Of Freedom (DOF) flight
simulations by the DFCS Guidance, Navigation, and Control (GNC) systems.
At present, guidance systems used by the DoD targets community in missions (i.e. the
remote operation of aerial vehicles) require specially trained personnel to develop flight-patterns
(i.e. precisely defined flight trajectories) prior to conducting missions. This process is
constrictive and static because it forces missions to be performed as specified by these prelaunch generated flight-patterns. These limitations make missions extremely inflexible. This
study proposes a solution that alleviates this problem. The solution is a real-time guidance
system that allows DoD TCCS personnel (e.g. the project engineer) to make changes to flight
profiles in real-time.
The RTPP is a prototype of this solution. It provides a user-friendly computer interface
for mission operators to safely guide and control target presentation locations in real-time. This
easy-to-use interface is operated by using a mouse and keyboard to interact with its Graphical
User Interface (GUI). The mouse can be used to select the flight trajectory’s start and destination
locations on the terrain map that is displayed within the GUI. The keyboard can be used for the
vii
same purpose but it is required for entering the other flight trajectory parameters (e.g., those
associated with turn radius constraints).
The user-entered UAV parameters are passed to the main module of the RTPP—the A*
algorithm. Then the RTPP provides either flyable flight trajectories or no guidance at all (which
occurs only when no solution exists). The returned flight-patterns have the attributes being
flyable (i.e. minimal distance, and safe).
The RTPP can be used in obstacle rich environments, provided the obstacles are static
(e.g. mountains and other natural high elevation terrain). If the obstacles are man-made, their
locations and MSL elevations must be entered into the RTPP.
The RTPP uses files generated by the Terrain Map Creator (TMC), which is another
product of this work. The TMC is a program that queries a high resolution environmental
database for recording to a file the locations and elevations of the terrain over which the mission
will be performed.
In conclusion, the RTPP is used as the platform for testing the A* algorithm, which is the
AI theory that is the recommended as the core technological solution. Its recommendation is
verified by research, technical feasibility, analysis, empirical testing, and simulations. Hence,
this Thesis demonstrates that DoD TCCS can benefit from innovations provided by AI theory.
viii
Table of Contents
Acknowledgements..................................................................................................v
Abstract ................................................................................................................. vii
Table of Contents................................................................................................... ix
List of Tables ....................................................................................................... xiii
List of Figures ...................................................................................................... xiv
List of Illustrations............................................................................................... xvi
Chapter 1: Introduction ............................................................................................1
1.1
Background ............................................................................................1
1.1.1 Target Command and Control Systems ........................................1
1.1.2 Drone Formation Control System.................................................2
1.2
Problem Statement .................................................................................3
1.3
Methodology ..........................................................................................5
1.4
Evaluation Criteria .................................................................................7
1.5
Document Overview ..............................................................................8
Chapter 2: Theory: Path Finding............................................................................10
2.1
Overview..............................................................................................10
2.1.1 Implications of Assumption 1.....................................................10
2.1.2 Traveling Salesperson Problem ..................................................11
2.1.3 Mapping WSMR Terrain to TSP Graph .....................................12
2.1.4 Convergence of Assumptions 1 & 2 ...........................................13
2.2
State Space Search ...............................................................................14
2.2.1 Graphs: Theory & Terminology .................................................14
2.2.2 Classic Test Problems .................................................................19
2.2.3 Search-Graph Generation from an Implicit State-Space ............23
2.2.4 Algorithm Analysis.....................................................................29
2.2.5 Intelligence in Search: Human vs. Artificial...............................37
2.2.6 A* Algorithm ..............................................................................40
ix
Chapter 3: Design, Implementation, & Integration ...............................................48
3.1
Methodology ........................................................................................49
3.1.1 Planning ......................................................................................49
3.1.2 Development Overview ..............................................................50
3.1.3 Target Platform ...........................................................................51
3.2
RTPP Alpha Prototype.........................................................................52
3.2.1 GUI Object..................................................................................54
3.2.2 Graphics Display Object .............................................................57
3.2.3 Terrain Map File Processing Object ...........................................65
3.2.4 A* Algorithm Object ..................................................................70
3.2.5 Dynamic Array Object................................................................74
3.3
Terrain Map Creator ............................................................................75
3.3.1 TMC Modules.............................................................................77
3.3.2 GUI Object..................................................................................79
3.3.3 Terrain Map File Processing Object ...........................................80
3.3.4 Geographic Conversions Object .................................................82
3.3.5 NED Query Module....................................................................86
3.3.6 Quantized Terrain Maps .............................................................87
3.4
RTPP-DFCS Integration Issues ...........................................................88
3.4.1 Flight Profiles..............................................................................89
3.4.2 Waypoints ...................................................................................92
3.4.3 Processing the A* Path to Waypoints.........................................92
3.4.4 Bounding the RTPP Input to Guarantee Real-time Response ....93
3.4.5 Problems Associated with Waypoints ........................................96
3.4.6 RTPP-DFCS Interface ................................................................99
3.4.7 RTPP-DFCS Integration ...........................................................102
3.4.8 Guidance Position Errors ..........................................................104
3.5
RTPP Beta Prototype .........................................................................105
3.5.1 Flight-Pattern Generation and Validation (FPGV) Module......107
3.5.2 Diagnostic System Module .......................................................122
3.5.3 Real-Time Timer (RTT) Module ..............................................123
3.5.4 Network Link ............................................................................124
x
Chapter 4: Flight-Pattern Analysis and RTPP Empirical Testing Results...........125
4.1
Performance Criteria..........................................................................125
4.2
Setup for Analysis of Pre-Launch Flight-patterns .............................125
4.2.1 Pre-launch Flight-pattern Parameters .......................................125
4.2.2 RTPP Output.............................................................................127
4.2.3 Milestone 1................................................................................132
4.3
Flight-pattern Distance Analysis........................................................132
4.3.1 Impact of Obstacles on Flight-pattern Distance........................133
4.3.2 Milestone 2................................................................................136
4.4
Flight-pattern Safety Analysis ...........................................................136
4.4.1 Safety Analysis for Flight-pattern at 7,000 ft MSL ..................138
4.4.2 Pre-launch Flight-pattern at 6,750 ft MSL................................140
4.4.3 Safety Analysis for Flight-pattern at 6,500 ft MSL ..................142
4.4.4 Milestone 3................................................................................144
4.5
Setup for Real-Time Performance Analysis ......................................145
4.5.1 Real-time Flight-pattern Conditions for Airborne UAV ..........145
4.5.2 Real-time RTPP Output ............................................................147
4.5.3 Milestone 4................................................................................151
4.6
Setup and Analysis Criteria for 6-DOF Flight-Simulations ..............152
4.6.1 DFCS Simulation Setup............................................................153
4.6.2 Guidance Errors Analysis .........................................................153
4.7
Data Analysis for Flight Simulation at 7,000 ft MSL........................154
4.7.1 Pre-launch Flight-pattern Maneuverability Analysis................154
4.7.2 Milestone 5................................................................................159
4.8
Data Analysis for Flight Simulation at 6,500 and 6,750 ft MSL.......159
4.8.1 Real-time Flight-pattern Maneuverability Analysis .................161
4.8.3 Milestone 6................................................................................171
4.9
Data Analysis for Flight Simulation at 6,500 ft MSL........................172
4.9.1 Real-time Flight-pattern Maneuverability Analysis .................174
4.9.3 Milestone 7................................................................................185
xi
Chapter 5: Conclusion..........................................................................................187
5.1
Discussion ..........................................................................................187
5.2
Future Work .......................................................................................188
5.2.1 System Integration Issue ...........................................................188
5.2.2 Artificial Intelligence ................................................................188
5.3
Conclusion .........................................................................................189
References............................................................................................................191
Glossary ...............................................................................................................194
Appendix 1: Mathematics of Generating a Flight-Pattern from an A* Route.....198
A1.1 Flight-Patterns: Elements, Indexing and Format ...............................198
A1.1.1
DFCS Flight-Pattern Indexing Scheme ...........................198
A1.1.2
Orientation of Circular Arc-segments..............................200
A1.1.3
RTPP Flight-Pattern Format ............................................201
A1.2 A* Routes: Points, Line Segments, and Vectors ...............................202
A1.2.1
Representing A* Routes as Vectors.................................202
A1.2.2
Representing A* Routes as Point-Vectors.......................203
A1.3 Flight-pattern Generation...................................................................204
A1.3.1
Generating a Waypoints List with Point-Vectors ............205
A1.3.2
Angle Changes on a 3x3 Grid..........................................206
A1.3.3
Angle Changes on A* Routes ..........................................208
A1.3.4
Describing Direction Angles with True Headings...........209
A1.3.5
Number of Records vs. Number of Segment ...................210
A1.3.6
Creating Flight-pattern Segments ....................................212
Curriculum Vita ...................................................................................................220
xii
List of Tables
Table 2.1: Format of OPEN (and CLOSED) lists......................................................................... 44
Table 3.1: Product Specifications. ................................................................................................ 48
Table 3.2: Development Methods................................................................................................. 50
Table 3.3: Tools and Technologies............................................................................................... 51
Table 3.4: RTPP Computer Core Architecture Specifications. .................................................... 52
Table 3.5: RTPP Alpha Prototype Modules. ................................................................................ 52
Table 3.6: GUI Object Tasks. ....................................................................................................... 56
Table 3.7: Graphics Display Object Tasks. .................................................................................. 57
Table 3.8: Contour Map View Legend. ........................................................................................ 60
Table 3.9: Screen World (GD Object) Coordinate System........................................................... 64
Table 3.10: Terrain Map File Processing Object Tasks................................................................ 66
Table 3.11: Terrain Elevation Map File Format. .......................................................................... 66
Table 3.12: Boundaries File Format. ............................................................................................ 67
Table 3.13: A* Path Format.......................................................................................................... 67
Table 3.14: Topographic Terrain Map Properties......................................................................... 69
Table 3.15: DFCS ENU Coordinate System................................................................................. 75
Table 3.16: TMC Modules............................................................................................................ 78
Table 3.17: Terrain Map Baseline. ............................................................................................... 94
Table 3.18: Specify RTPP IP Address. ......................................................................................... 99
Table 3.19: Enable Network Communication. ............................................................................. 99
Table 3.20: Request Flight-pattern Between two locations. ....................................................... 100
Table 3.21: Request Flight-pattern for Airborne UAV............................................................... 101
Table 3.22: Request Flight-pattern for Airborne UAV and Existing Flight-pattern. ................. 102
Table 3.23: Inhibit Network Communication............................................................................. 102
Table 3.24: RTPP Beta Prototype Modules. ............................................................................... 107
Table 3.25: Route Buffers........................................................................................................... 107
Table 3.26: Modules within the FPGV Module.......................................................................... 107
Table 3.27: A* Algorithm Inputs for the Desired Flight-Pattern. .............................................. 110
Table 4.1: Pre-launch Parameters for a 7,000 ft MSL Flight-pattern. ........................................ 126
Table 4.4: Pre-determined Flight-pattern Parameters for a Southern Bound Airborne UAV. ... 145
Table 4.5: Pre-determined Flight-pattern Parameters for a Northern Bound Airborne UAV. ... 146
Table 4.6: Real-time Flight-pattern Parameters for a Southern Bound Airborne UAV. ............ 146
Table 4.7: Real-time Flight-pattern Parameters for a Northern Bound Airborne UAV. ............ 147
Table A1.1: Flight-pattern Format.............................................................................................. 201
Table A1.2: Waypoint Format. ................................................................................................... 205
Table A1.3: Waypoint List for A* route from Illustration A1.1. ............................................... 214
Table A1.4: Waypoint List for A* route from Illustration A1.2. ............................................... 215
Table A1.5: Flight-pattern List for A* route from Illustration A1.3. ......................................... 217
Table A1.6: Flight-pattern List for A* route from Illustration A1.3. ......................................... 218
xiii
List of Figures
Figure 1.1: DoD Target Command and Control Systems............................................................... 2
Figure 2.1: The 8-puzzle with tiles arranged in increasing order. ................................................ 20
Figure 2.2: The 8-queens problem arranged so that none of queens attack each other. ............... 22
Figure 2.3: The 8-queens problem where all queens attacking and being attacked. .................... 23
Figure 2.4: The 8-puzzle with tiles arranged in random order. .................................................... 24
Figure 2.5: Algorithms represented as black boxes. ..................................................................... 29
Figure 2.6: (a) O( g(n) ); (b) Ω( g(n) ); (c) Θ( g(n) ). ................................................................... 34
Figure 3.1: Operator using RTPP alpha prototype GUI. .............................................................. 55
Figure 3.2: RTPP alpha prototype GUI object.............................................................................. 56
Figure 3.3: RTPP alpha prototype display modes—natural and contour. .................................... 60
Figure 3.4: GD object zoom-in view of a terrain map.................................................................. 62
Figure 3.5: Terrain map ASCII file in (i, x, y, h) format. ............................................................. 66
Figure 3.6: TMC GUI and dialog boxes. ...................................................................................... 80
Figure 3.7: Complicated A* path.................................................................................................. 95
Figure 3.8: Generating Waypoints from an A* path..................................................................... 97
Figure 3.9: Guidance Position Errors.......................................................................................... 105
Figure 3.10: A* route.................................................................................................................. 112
Figure 3.11: A* route with a 90° heading constraint at the start location. ................................. 114
Figure 3.12: A* route with a 90° heading constraint on the destination location....................... 115
Figure 3.13: A* route with heading constraints of 90° at the start and 270° at the destination. 116
Figure 3.14: A* avoiding high-terrain. ....................................................................................... 117
Figure 3.15: Waypoints............................................................................................................... 119
Figure 3.16: Waypoints on top of A* route. ............................................................................... 120
Figure 3.17: Flight-pattern on top of waypoints list. .................................................................. 121
Figure 3.18: Flight-pattern on top of waypoints list on top of A* route..................................... 122
Figure 4.1: RTPP GUI displaying A* route specified on Table 4.1. .......................................... 128
Figure 4.4: Flight-pattern from Table 4.2 on DFCS Console Subsystem................................... 131
Figure 4.5: Flight-pattern from Table 4.3 on DFCS Console Subsystem................................... 132
Figure 4.6: Side view of flight-patterns from Tables 4.1 to 4.3 over elevation data. ................. 133
Figure 4.7: Bird’s-eye view of flight-patterns from Tables 4.1 to 4.3 over elevation data. ....... 134
Figure 4.8: Flight-patterns from Tables 4.1 to 4.3 plotted on an ENU x-y plane....................... 135
Figure 4.9: Flight-pattern from Table 4.1 near and over high elevation terrain. ........................ 139
Figure 4.10: Flight-pattern from Table 4.1 proximity to high elevation terrain. ........................ 140
Figure 4.11: Flight-pattern from Table 4.2 near and over high elevation terrain. ...................... 141
Figure 4.13: Flight-pattern from Table 4.3 near and over high elevation terrain. ...................... 143
Figure 4.15: RTPP GUI displaying A* route specified by Tables 4.4 and 4.6........................... 149
Figure 4.16: RTPP GUI displaying A* route specified by Tables 4.5 and 4.7........................... 150
Figure 4.17: Flight-pattern from Tables 4.4 and 4.6 on DFCS Console Subsystem. ................. 151
Figure 4.18: Actual flight trajectory on flight-pattern from Table 4.1. ...................................... 155
Figure 4.19: (a) Flight altitudes and terrain elevations; (b) Actual and desired AGL. ............... 156
Figure 4.20: (a) ENU x; (b) ENU y; (c) True heading; (d) Roll angle. ...................................... 157
xiv
Figure 4.21: (a) Ground speed; (b) Normal acceleration; (c) CTE; (d) ATE. ............................ 158
Figure 4.22: Real-time flight-pattern links to pre-launch flight-pattern. .................................... 160
Figure 4.23: Real-time flight-pattern linking to pre-launch flight-pattern over terrain. ............. 161
Figure 4.24: Actual flight trajectory on flight-patterns from Table 4.4 and 4.6. ........................ 163
Figure 4.29: Flight-pattern from Tables 4.4 and 4.6 on DFCS Console Subsystem. ................. 168
Figure 4.33: Real-time flight-pattern links to pre-launch flight-pattern. .................................... 173
Figure 4.34: Real-time flight-pattern linking to pre-launch flight-pattern over terrain. ............. 174
Figure 4.35: Actual flight trajectory on flight-patterns from Table 4.5 and 4.7. ........................ 176
Figure 4.40: Flight-pattern from Table 4.3 on DFCS Console Subsystem................................. 182
Figure 4.41: (a) Flight altitudes and terrain elevations; (b) Actual and desired AGL.. .............. 183
Figure A1.1: Two flight-patterns on the DFCS console subsystem. .......................................... 199
Figure A1.2: An A* route with ∆θ = 135˚ at the center square of a 3x3 grid. ........................... 207
xv
List of Illustrations
Illustration 2.1: Traveling Salesperson Problem Graph................................................................ 12
Illustration 2.2: A subset from the 8-puzzle state-space. .............................................................. 26
Illustration 3.1: RTPP alpha prototype architectural diagram. ..................................................... 54
Illustration 3.2: Screen world (GD object) coordinate system. .................................................... 64
Illustration 3.3: DFCS ENU coordinate system............................................................................ 77
Illustration 3.4: TMC Architecture diagram. ................................................................................ 78
Illustration 3.5: WGS84 ellipsoid on ECEF coordinate system. .................................................. 84
Illustration 3.6: Geodetic longitudinal lines relative to ECEF X-Y axes. .................................... 85
Illustration 3.7: Geodetic latitudinal lines relative to ECEF Y-Z axes. ........................................ 86
Illustration 3.8: RTPP-DFCS integration.................................................................................... 103
Illustration 3.9: RTPP beta prototype architectural diagram. ..................................................... 106
Illustration A1.1: An A* route with an angle change of ∆θ = 90˚. ............................................ 214
Illustration A1.2: An A* route with an angle change of ∆θ = 135˚. .......................................... 215
Illustration A1.3: Using sector χ90˚ to smooth an angle change of ∆θ = 90˚.............................. 217
Illustration A1.4: Using sector χ135˚ to smooth an angle change of ∆θ = 135˚. ......................... 218
[IMPORTANT: Never delete the section break below. It is needed to initiate page numbering
from the next page onwards. In case, you do not need a List of Illustrations page and you are
deleting this page, make sure the section break is retained and goes to the end of the previous
page. This text is for information only. Delete this text after reading.]
xvi
Chapter 1: Introduction
Department of Defense (DoD) Target Command and Control Systems (TCCS) can
benefit from AI technology. To provide evidence for this claim, theories in Artificial Intelligence
(AI) were researched and used in a practical approach for creating a real-time flight guidance
system. The research favored State Space Heuristic Search [Nil80] as superior to other AI
theories (such as Artificial Neural Networks (ANN) [Fau94], Dynamic Programming (DP)
[Dre65], and Branch-and-Bound (B&B) [Kum88]) for flight trajectory generation. Therefore, the
A* algorithm was used as the AI component in a flight-guidance system. This flight-guidance
system was named the Real Time Path Planner (RTPP); it was implemented for bench testing the
A* algorithm. The RTPP bench testing includes empirical testing and simulation on the Drone
Formation Control System (DFCS), which is a functional DoD TCCS located on White Sands
Missile Range (WSMR), New Mexico. This Thesis discusses the following: (1) the RTPP
implementation; (2) the analysis of the RTPP output, which are flight-patterns; (3) the RTPP
real-time DFCS empirical testing results; (4) the flight simulation results of simulated UAV
using RTPP flight-patterns.
1.1
BACKGROUND
1.1.1
Target Command and Control Systems
The Army, Navy and Air-Force use DoD TCCS for personnel training and for testing and
evaluating weapon systems [Sec88]. Figure 1.1 below depicts eight different military bases that
use DoD TCCS for remotely controlling and operating targets; the types of targets controlled are
either or a combination of the following: ground, seaborne, and aerial. DoD TCCS can remotely
operate single or multiple manned or unmanned sub-scale or full-scale vehicles. The remote
control operations are referred to as missions. Missions are conducted from a Ground Control
Station (GCS) by teams consisting of trained vehicle operators, engineers, and technicians. The
types of vehicles used in mission are categorized as either sub-scale or full-scale. Sub-scale
1
aircraft are missile-like vehicles that were designed for remote operation which is evident from
the lack of cockpit. Full-scale vehicles were designed with a compartment for human operation;
the full-scale vehicles that get equipped with hardware that allows them to be remotely operated
are referred to as drones. The targets community also refers to these sub-scale and full-scale
vehicles as targets or Remotely Piloted Vehicles (RPV) [Lee75], [Ran76].
Figure 1.1: DoD Target Command and Control Systems.
1.1.2
Drone Formation Control System
The Drone Formation Control System (DFCS) is a mature DoD TCCS. It can
automatically control the following aerial vehicles: the QF-4 full-scale drone and the BQM-34A,
MQM-107D and MQM-107E sub-scale RPV. It can also control the following ground vehicles:
the M60 and T-72 tanks, and the M-812 five-ton truck. DFCS can automatically takeoff and land
the QF-4 drone at Holloman Air Force Base (located in Alamogordo, New Mexico). Targets are
controlled by via Radio Frequency (RF) data-links. These RF data links are used to transmit
target data, telemetry and commands between the targets and the GCS. The target has an
2
airborne subsystem which communicates, or is interrogated, at 10 Hz. There are two types of
interrogations: uplinks and downlinks. The uplinks are data that are passed to the target; they
contain approximately 10 proportional channels and 80 discrete channels. The downlink
telemetry are data that is returned by the target to DFCS; they contain approximately 30
proportional channels and 80 discrete channels.
DFCS contains a Ground Control Station (GCS) that contains the following: (1) eight
console subsystems from which missions are performed: six are Drone Control Consoles (DCC)
and two are Master Control Consoles (MCC); (2) two central RISC type Computer Control
Subsystems (CCS) to perform the Guidance, Navigation, and Control (GNC) of the targets; (3)
two Data Link Processors to transmit data via Radio Frequency (RF) between airborne targets
and the GCS; (4) two co-located Interrogator Subsystems (ISc). Additionally, to perform
navigation and to transmit and receive data to and from remotely located targets, DFCS uses 10
Distance Measuring Equipment (DME) Interrogator Stations (IS) and four UHF Radio
Frequency Module (RFM) units that are located at strategic mountain peaks to cover most of the
WSMR airspace.
1.2
PROBLEM STATEMENT
This study was conducted to determine the feasibility of updating the DFCS aerial-
vehicle guidance system with advanced technologies from the field of AI in order to assist DoD
TCCS personnel in performing live testing of modern weapon systems. This study was to
determine if recent technologies could lessen the intrinsic inflexibilities within the DFCS aerialvehicle guidance system in the following areas: flight trajectory geometry, obstacle avoidance,
real-time capabilities, and operator work load. This study also sought a technology that would
extend real-time capabilities while lessening error prone and labor intensive tasks.
First, one problem in the legacy aerial-vehicle guidance system arises from real-time
inflexibilities. The inflexibilities limit the modifications that can be performed to the pre-planned
test setting for weapon-system evaluation (e.g. the real-time creation of a flight-pattern over
3
mountainous terrain using a low AGL). Second, another problem that is inherent in this situation
is that the project decision makers must request modifications for target flight profiles from
DFCS. Third, at present, DFCS is limited in the number of actions it can do in real-time. For
example, if a change in the pre-planned flight trajectory is requested, the only actions that can be
performed to accommodate this request are that of rotating, shifting, and translating the existing
flight-pattern. Changes to the flight-pattern’s geometry, that is, its overall shape, are not allowed
in real-time.
The preplanned flight trajectory real-time modifications just described become less
available as the UAV flight altitude decreases. For example, when the UAV is flying over
WSMR at an altitude less than 9,000 ft, a danger arises when using the flight-pattern translations
described above. This is because the mountain elevations vary from approximately 4,000 ft MSL
to approximately 9,000 ft MSL. For instance, consider the dangerous situation that occurs if a
flight-pattern is rotated or moved in such a way that it traverses high elevation terrain. At
present, DFCS is equipped with a nap-of-the-earth (i.e. terrain-following) system which can
avoid obstacles by having the UAV perform climbs; however, DFCS does not have modules that
avoid obstacles by flying laterally around them.
The combination of the problems described above makes real-time modifications, and
hence mission operations, very inflexible. The project decision makers must be in constant
communication with DFCS personnel and they must notify DFCS when the original plan
requires changing so that actions from the set of real-time changes can be implemented. In
summary, the goal of this research is to eliminate these problems by coming up with a real-time
solution that allows DoD target control system operators, personnel, and project decision makers
to create (or modify) pre-planned flight profiles. The desired solution is such that operators,
personnel, and decision makers can have the flexibility to command that a specified number of
UAV be guided, navigated, and controlled to the desired location(s) with precision timing (L.E.
Alvarado, personal communication, January 2006).
4
1.3
METHODOLOGY
A solution to the problem described above would be a system that performs the following
four real-time operations: (i) flight trajectory creation, (ii) obstacle-avoidance, (iii)
synchronization of multiple UAV, and (iv) allows flight profile modifications to be performed by
project decision-makers with minimal DFCS interaction. (i) and (ii) can be grouped since they
both deal with the geometry and real-time generation of flight trajectories. They also have
similar constraints: flight trajectories must be maneuverable by aircraft, and the resulting flight
trajectories must maintain a constant MSL flight altitude so as to create a solution that is
independent of the nap-of-the-earth obstacle avoidance algorithms. (iii) differs from (i) and from
(ii) in that it deals with the flight trajectories distance and timing, e.g. finding flight trajectories
that can reach point B from the respective locations of a couple of UAV, each moving at its
respective ground speed. The output of (iii) is to have multiple UAV rendezvous at userspecified locations. (iv) differs from (i), (ii), and (iii) in that it deals with interfaces and
integration issues: e.g., what Graphical User Interface (GUI) minimizes user input errors, etc.
The relationship between (i), (ii), (iii) and (iv) is that only (i) and (ii) can be grouped as similar,
and that the implementation of (iii) and (iv) depends on how the system performs (i) and (ii).
This system’s methodology—its planning, development, testing, etc.—was implemented
using Boehm’s spiral model [Boe88]. This industry-proven model was used for dividing this
project into phases and for allocating a set of prioritized tasks to each phase. This software
planning method produced a solid architectural foundation that prepared the system for future
enhancements, which is useful and necessary when the product’s lifespan and scope are
considered. This project has been divided into three phases, where Phase I implements (i) and (ii)
and Phases II and III are set aside for implementing (iii) and (iv), respectively (as future work).
This thesis focuses on the implementation of Phase I. However, the theories were selected with
the constraint that they must be updatable, swappable, or replaceable in such a way that the core
architecture developed in this study allows for modules to be added or replaced during Phases II
and III.
5
The methodology to perform this document’s study—that is, the implementation of Phase
I—consists of the following six different tasks: (1) research, (2) design, (3) development, (4)
empirical testing, (5) simulation, and (6) analysis. First, Task 1 was to research the guidance
systems used by autonomous UAV in order to determine what trajectory generation and obstacle
avoidance theories and algorithms they employ. This task led to further in-depth research for
flight trajectory generation in the fields of Artificial Intelligence, Operations Research, and
Optimal Control Theory. This research eventually led to the selection of the A* algorithm
[Har68]. Second, Task 2 was to design; that is, to create an architecture for the program that
would implement the A* algorithm. This task yielded two software architectures: one for the
Terrain Map Creator (TMC) and the other for the RTPP. This design makes these programs
independent from each other. The TMC produces elevation data files for the RTPP, and the
RTPP, in turn, produces flight trajectories for the DFCS guidance system. The design anticipates
the availability of more accurate terrain elevation data in the future from different sources. Under
such circumstances, new digital terrain elevation data programs could be created that extract data
from new data sources into RTPP compatible elevation files.
Third, Task 3 was implementation. Microsoft® Windows XP™ was selected as the
development and product platform. C++ and Object Oriented Programming (OOP) [Dei01]
technologies were used to create all the source code. The source code was compiled with
Microsoft Visual C++.NET™. The National Elevation Dataset (NED) [USG07] was used as the
elevation data source. It is the input to the TMC. OpenGL™ (Open Graphics Library) [Woo97]
was selected as the computer graphics Application Programming Interface (API) tool to display
both the NED based terrain maps and the flight trajectories on the RTPP GUI. The DFCS
console subsystem terrain displays were also assigned to display these data. These technologies
were chosen from a technology matrix that was created for identifying the most capable,
efficient, as well as practical, developmental tools.
Fourth, Task 4 was to perform empirical testing. This required the resulting product (i.e.
the RTPP) to be integrated into DFCS so that it can receive guidance commands requests and
6
provide guidance solutions in response to these requests. Therefore, the RTPP computer was
linked to the DFCS real-time computer network via TCP/IP protocol. This allowed flight-pattern
and their specifications to be passed as UDP network packets between the DFCS real-time
computer network and the RTPP. Fifth, Task 5 was to perform flight simulations. Three
simulations were performed using one simulated MQM-107D sub-scale aircraft per simulation.
The RTPP generated five flight-patterns to be used by the DFCS Guidance, Navigation, and
Control (GNC) system; three flight-patterns were created prior to the MQM-107D launch; two
were created when the MQM-107D was airborne. In the simulations, the GNC system
maneuvered the simulated UAV on all five flight-patterns. Sixth, Task 6 was to analysis. Three
properties of RTPP flight-patterns were analyzed to determine if they are flyable; these
properties are distance, safety, and maneuverability. Flight-pattern distance is one criterion that
establishes if the flight-pattern is flyable. Flight-pattern safety examines the flight-pattern’s
proximity to high elevation terrain. Flight-pattern maneuverability is determined by establishing
that a UAV turn radius constraints are implemented.
1.4
EVALUATION CRITERIA
Since this work is based on an AI algorithm, the evaluation criteria for this study were
obtained from the AI field. Russell and Norvig [Rus03] define a performance measure, an agent,
an environment, and a task environment, and how they relate to each other: “The performance
measure evaluates the behavior of an agent in an environment”. This description of performance
measure and the rational agent [Rus03] description are used to explicitly define the criteria for
evaluating the RTPP output. In this setting, the UAV is the agent, and the RTPP is the agent
program. The environment for this study has two components: real-time flight trajectory
requests, and the WSMR terrain. The real-time flight trajectory requests are transmitted to the
RTPP from the DFCS real-time computer network, and the WSMR terrain is provided to the
RTPP as elevation data files that are created offline by the TMC. The task environment is stated
as follows: to provide real-time flight guidance to a UAV as specified by a human operators at
the DFCS console subsystem.
7
The five specifications that follow define the RTPP expected behavior. The first set of
specifications is the flight-patterns initial and final location; the RTPP must generate a minimaldistance flight-pattern between these two locations. The second specification is the UAV flight
altitude; the flight altitude must remain constant for the entire flight. The third specification is
minimum Above Ground Level (AGL) distance; the RTPP must generate a flight-pattern that
maintains a minimum AGL distance between the UAV and the terrain beneath it for the entire
flight-pattern. The fourth set of specifications is the initial and final true heading for the UAV on
the flight-pattern; that is, the flight-pattern must use the specified true headings for exiting the
starting location, and use the specified true headings for entering the destination location. The
fifth specification is the ground speed; curves on RTPP flight-patterns must have a minimum
radius equal the UAV turn radius which depends of the maximum ground speed used for the
flight-pattern to be generated. [Sot07]
1.5
DOCUMENT OVERVIEW
The document discusses the process of attaining real-time guidance for a DoD TCCS.
The desired solution to this problem was a real-time guidance system that runs on a high-end
computer—preferably a Personal Computer (PC). This system must be compatible with the
DFCS real-time environment. The concept was that guidance algorithms generate flighttrajectories in real-time1; then pass them to the DFCS real-time computer network where there,
the DFCS Guidance, Navigation, and Control (GNC) system would use them to automatically
navigate and control UAV. The phases that led to the implementation of this system’s prototype
are discussed in Chapters 2, 3, and 4: first, the research that went into selecting technology for
implementing this system; second, the work that went into implementing a prototype of this realtime guidance system; last, the empirical testing and simulation results of the prototype system.
Chapter 2 begins with an overview of this study’s research; then, State-Space Search
(SSS) is explained. Also described are related SSS algorithms that can also be implemented as
1
The real-time definition for this system is defined as follows: UAV guidance that is generated and ready for use by
an airborne UAV in less than three seconds from when the flight trajectory request was sent.
8
software to run on a personal computer. Chapter 3 describes the two MS Windows XP
compatible software products that resulted from this study: the RTPP and the TMC. Their
design, development and how they were integrated into DFCS are explained. Additionally,
Chapter 3 discusses the RTPP inputs and the DFCS modules and components that comprise the
RTPP virtual and physical environments. Chapter 4 analyzes the validity of the RTPP flightpatterns. It also presents the real-time performance capabilities which were obtained from
empirical testing on the DFCS real-time environment. Lastly, it provides the 6-DOF flight
simulation results where five RTPP flight-patterns were used to guide three simulated MQM107D sub-scale UAV in three separate flight simulations.
9
Chapter 2: Theory: Path Finding
2.1
OVERVIEW
This research seeks theories that are useful in a system that can provide the following
solution: a UAV route-generating system for a UAV flying over known terrain where all
obstacles are static and known a-priori. For solving this problem and for determining the
direction of the research, two concepts were used for establishing assumptions that justify the
direction of this research: one, the Traveling Salesperson Problem (TSP) [Fau94], [Rus03] and
two, the A* algorithm [Cap02], [Yao05]. Assumption 1 is based on the TSP problem where a
salesperson takes a tour of n cities and returns to the city where the tour began. The constraint to
this problem is that all the n cities must be visited and that the cities must be visited in such an
order that the total distance traveled is the minimum distance attainable. This means that the
distance traveled is minimal because the shortest distance tour was selected from the set of all
tours that begin and end in the city where the salesperson begins the tour. Assumption 2 is based
on the A* algorithm, which is ubiquitous in the autonomous vehicle literature; it showed to have
several uses. For example, Capozzi et al [Cap02] suggest it as a path planning method.
Additionally, Yao-hong et al [Yao05] use it in simulation. Yet still, Barto et al [Bar93] use it as a
paradigm for comparing their dynamic programming solutions.
Assumptions 1 and 2 are succinctly stated as follows:
Assumption 1: The TSP problem is a superset of the route finding problem, which is to
find a route between two different locations in this study.
Assumption 2: The A* algorithm has been implemented successfully as a route finding
module for use in autonomous aerial vehicles.
2.1.1
Implications of Assumption 1
Assumption 1 implies that the solution space of the TSP problem contains a solution for
finding a route between two distinct locations. This means that the solution space must contain a
solution that can be applied to solving the route finding problem for guiding a UAV that is flying
10
over the WSMR terrain. For this implication to be true and correct, the UAV route finding
problem on the WSMR environment must have a representation that is very similar to that of the
TSP problem. Several documented approaches are available that efficiently solve the TSP
problem. But first, it must be established that this study’s problem can be solved by some of the
TSP solutions. Hence, Assumption 1 and the resulting implications are not used for performing
analysis on any of the solutions. Instead, they are used in this phase of the research to establish
that the WSMR environment can be formulated as done for the cities of the TSP. If this can be
done, the implications resulting from Assumption 1 can be established as correct, which means
that one of the solutions for the TSP problem can be used as a module within the system that will
be created for solving the problem presented in this Thesis.
2.1.2
Traveling Salesperson Problem
The TSP problem is often illustrated with a graph consisting of vertices and arcs2. The
vertices represent the set of cities and the arcs represent the set of roads that connect the cities. In
TSP graphs, it is common to assign a weight to each arc. The arc’s weight represents the distance
between the cities it connects. This concept is illustrated in Illustration 2.1 below.
2The
technical term here is edge: edges are bidirectional links whereas arcs are unidirectional links. However, the
less esoteric term arc will be used interchangeably with edge until graph terminology is formally presented.
11
Illustration 2.1: Traveling Salesperson Problem Graph.
Notice that the graph is not precisely defined. This is a common abstraction when discussing the
TSP problem. For example, the graph shows that cities C1 and C2 are separated by 20 length
units but it does not indicate from where in each city this distance was measured. Additionally, it
does not indicate if the cities are contiguous or if they are separated by areas. One ambiguity
caused by the imprecision is that these cities could be contiguous if the connecting arc represents
the road from the center of city C1 to the center of city C2. Similarly, the cities could be
separated from each other by space if the connecting arc represents the road from the right border
of city C1 to the left border of city C2. These ambiguities in the TSP graph imply an abstraction
that hides the implementation details and allows for a wider variety of theories that solve this
problem to be applied for solving similar problems.
2.1.3
Mapping WSMR Terrain to TSP Graph
The graph on Illustration 2.1 can be modified and precisely defined to represent an area
of the WSMR terrain. For example, let an area of the WSMR terrain be divided into three
contiguous squares of equal size such that the squares take up the vertices that represent the cities
12
C1, C2, and C3 of the top row. If the length and width of the top row are 100x300 length units,
respectively, the dimensions of each square are 100x100 length units. Furthermore, the two arcs
can be made to represent the distances from the center of one square to the center of the next
square. This means that the labeled arc value from WSMR location C1 changes from 20 to 100
length units as does the labeled arc connecting WSMR locations C2 and C3. Applying this
division to the middle and bottom rows produces a representation of the WSMR terrain as a TSP
graph. This assignment demonstrates that the WSMR terrain can be represented as the cities, or
more generally the locations, in the TSP graph. Therefore, if Assumption 1 is true, some of
theories and solutions that solve the TSP problem can also be applied to the problem of
generating a route between two locations for a UAV flying within the WSMR terrain.
2.1.4
Convergence of Assumptions 1 & 2
Assumption 2 states that the A* algorithm has been used for autonomous UAV path-
planning and Assumption 1 implies that if a solution can solve the TSP problem, it can also solve
this study’s route finding problem. Since the A* algorithm has been used to solve the TSP
problem (Russell and Norvig illustrate this as an example [Rus03]) and because recent
publications (e.g. [Cap02], [Rus03], and [Yao05]) suggest the use of the A* algorithm for pathplanning, Assumption 1 and Assumption 2 converge and they can be unified. This convergence,
or unification, provides three important results: (1) that the WSMR terrain can be represented as
a TSP graph; (2) that the A* algorithm can solve the TSP problem; (3) that the A* algorithm has
been used to generate flight trajectories for UAV. From these results, the following
generalization can be made: the A* algorithm can be used to find a route for a UAV on the
WSMR terrain. This generalization is as much an abstraction, since it does not consider real
world issues such as reliability, real-time responses, computer hardware constraints, and UAV
turn radius constraints. However, this generalization does imply that other solutions to the UAV
route finding problem may exist in a solution set that branches out from the A* algorithm and
that this solution set contains other route finding algorithms applicable to the problem of UAV
13
route-generation. Hence, further research is done on the A* algorithm and its parent discipline
AI.
2.2
STATE SPACE SEARCH
State-Space Search (SSS) [Nil71], [Rus03] is an AI3 theory that uses the vertices of a
graph to represent the different conditions of a problem. For example, the initial condition, all the
intermediate conditions, and the final condition are all represented by a vertex on the graph.
Additionally all the transitions between previous and next conditions are all represented as arcs
on the graph. The set of all conditions is called the state-space, and each individual condition is
called a state. The attempt to perform the exact transitions from a specific initial state to a
specific goal state is called a state-space search. A path is a solution that results from a SSS.
Precisely, it is a sequence that begins with the initial state, then contains all the intermediate
states in order, and ends with the goal state. Hence, the purpose of SSS is to find a path within a
graph. Research for SSS (i.e. theories that employ graph-searching techniques) is conducted.
This is to verify that the most practical solution for real-time path-planning is selected for the
UAV route-generation module.
Several fields offer solutions that can be used to solve SSS problems. The field of
Optimal Control theory has one solution called Dynamic programming (DP) [Bro74], [Bar93].
The Operations Research field contains two solutions for finding the shortest path within a
graph: (1) the Dijkstra algorithm [Win94], [Mit88] and (2) the Branch and Bound technique
[Win94]. The field of Artificial Intelligence provides several methods for finding a shortest path
within a graph: blind search (e.g. breadth-first, depth-first), greedy search (e.g. best-first,
iterative-deepening), and heuristic search (e.g. A*) [Nil71], [Rus03].
2.2.1
Graphs: Theory & Terminology
This section provides a formal description of graph-theory. An informal introduction to
graph-theory was provided above as an example of how to represent the WSMR terrain as a
3AI
as used in this study is the modeling of human thought for problem-solving; this is a different application than
AI as used for modeling the neurons in the brain.
14
graph. Furthermore, as implied above, the A* algorithm is a graph-searching technique; so are
all the other methods that were researched for solving this Thesis’ problem. Hence, graphs are
used by all the route-finding theories in this work. Several literary works provide detailed
overviews of graph-theory [Cor90], [Ste95], [Car07], [Har68]. In this section, graph theory and
its concepts and terminology are described as they apply to some to the problems in the fields of
operations research, optimal control theory, and artificial intelligence. Although, it is not the goal
of this research to treat these different fields as if they are the same as done by Kumar et al [cite
the CDC paper], the abstraction provided by unifying these theories is used to describe graphtheory since the literature documenting these theories follows conventions when dealing with
graphs.
2.2.1.1 Introduction to Graphs
The TSP problem was introduced as the problem of finding the shortest distance tour of n
cities from the set of all tours that begin and end in the same city. The reason the TSP problem
was explained in terms of graphs and sets is that graphs are composed of sets. In this subsection
the TSP graph from Illustration 2.1 is referred to as G and it is described mathematically using
set theory.
The graph G is made up of two sets: the set V of vertices and the set E of edges4; this is
described mathematically in Equation 2.1 below.
G = {V , E}
(2.1)
where
4Edges
G
is a graph
V
is the set of vertices, or nodes, in the graph; and
E
is the set of edges, or arcs, in the graph
are bidirectional links and not all graphs are bidirectional; in the latter case, graphs use arcs instead of edges.
15
In graphs, vertices connect to other vertices with edges or arcs. Regarding graph terminology,
many authors use the term nodes in place of vertices (or node for vertex in the singular case).
Furthermore, the terms edges and arcs are used to identify the linking element of graphs; these
terms are not interchangeable. Edges are bidirectional and arcs are unidirectional. Graphs that
use arcs exclusively to connect the vertices or nodes are unidirectional and graphs that have
some edges connecting the vertices are bidirectional. An example of a bidirectional graph is that
of Illustration 2.1. Notice that the edges contain two arrow heads; had the linking elements been
arcs, they would only contain one arrow head.
The TSP graph G is also an example of a labeled and explicit graph. In labeled graphs,
the vertices, or nodes, have values written inside or next to them; this is also true for arcs and
edges. The arc or edge value is often referred to as the cost or the weight for transitioning
between vertices or nodes. By definition, these labeled graphs are always explicit. This means
that all the vertices and edges are clearly defined and can be easily drawn out as was the case for
the graph G on Illustration 2.1. Explicit graphs fall under the category of finite graphs since their
sets can be made explicit by drawing them out. This is not true for infinite graphs. Infinite graphs
are always implicit since their sets of vertices and edges cannot be represented explicitly.
Nevertheless, sub-graphs from the infinite graph can be made explicit if the relationships
between the vertices and the edges are known (the A* algorithm is a perfect tool for making subgraphs, such as paths, from infinite graphs explicit).
2.2.1.2 Introduction to Paths
Paths are subsets, or sub-graphs, of a parent graph. They are comprised of subsets
belonging to the sets of vertices and edges of the parent graph. Paths can be made explicit by the
A* algorithm. However, when dealing with large or infinite graphs, it is best to leave the set of
paths implicit since precisely generating the entire set of paths, besides being time-consuming,
can be impractical, inefficient, and even impossible—especially if only one particular path is
sought. The reason for this is that finite graphs contain a combinatorial set of paths and infinite
graphs can have an infinite set of paths. This method is used in this work; that is, the paths of a
16
graph are left as implicit sub-graphs until a particular path is desired, at which point, the search
for this path commences and, if it is found, it is made explicit by the A* algorithm.
The graph G on Illustration 2.1 contains a set of paths T. The set T contains the different
sequences that represent each distinct path Ti. Each of the paths is made up of a combination of
the vertices Ci that represent the cities. All the vertices of G are in each path Ti since each valid
tour visits each of the n cities. Furthermore, the paths of T are sub-graphs of G, and thus T ∈ G.
These relationships—the set of vertices Ci are in G, the set of paths T is a subset of G, the path Ti
is a sequence composed of the vertices Ci—are summarized by Equations 2.2 below.
Ci ∈ G
T ⊂G
Ti = {Cs ,..., Cs }
(2.2)
where
G
is the graph; and
T
is the set of paths in G; and
i
is the index associated with the ith vertex; and
Cs
is the vertex representing the start and end vertex of the path; and
…
are all the different combinations of the vertices in G excluding Cs; and
Ti
is the set of all paths in G that begin and end with vertex Cs
The solution to the TSP problem is an example of a path. This path Tmin represents the
tour having the minimum travel distance dmin and it is selected from this set of paths, or tours, T,
which begin and end in the same city Cs. This solution has several names: (i) the shortest (or
shortest-cost) path, (ii) the minimum (or lowest) cost path, (iii) the optimum (or optimal) path.
These identifiers specify that a path Tmin has the lowest cost cmin from the set of all paths T. It is
not uncommon for a graph to contain more than one path Tmin with the lowest cost value cmin
(e.g., this is the case for graph G on Illustration 2.1; notice that the edge costs are symmetric).
17
The total cost cp of each path Ti is computed by summing all the edge costs cjk on the path; cjk is
the cost between cities Cj and Ck. The minimal distance tour Tmin for the graph G on Illustration
2.1 can be identified by comparing the travel distances of the tours in T. That is, the shortest path
Tmin in G is the path from the set T whose total cost cp is dmin.
cp =
∑c
j , k∈v
jk
,
c jk ≥ 0
(2.3)
where
cp
v
is the total cost of the ith path Ti; and
is the set of vertices in the ith path Ti; and
j,k
are the indexes associated with a pair of vertices vj and vk; and
cjk
is the edge cost between the vertices vj and vk
2.2.1.3 Cycles
A cycle is a special path that begins and ends at the same vertex. An example of a cycle is
the solution to the TSP—this path begins and ends at the same vertex. Actually, the TSP graph G
of Illustration 2.1 is itself an example of a cycle. For instance, one cycle resulting from this graph
is the tour that starts at vertex C1 where the first element of the cycle is this vertex C1. The next
eight elements of the cycle are the other vertices of the graph, and the last element of the cycle is
again the vertex C1. One of the cycles composed of the vertices from the graph G is the path T1 =
{C1, C2, C3, C4, C5, C6, C7, C8, C9, C1}. Another example of a cycle from the graph G is the path
T1 = {C1, C2, C1}. Observe that the graph G contains a combinatorial set of cycles.
Graphs that contain cycles are referred to as cyclic graphs and those that do not, as
acyclic graphs. Even though not all graphs contain cycles, cycles do appear in both
unidirectional and bidirectional graphs.
18
2.2.1.4 Negative Edge Costs
Equation 2.3 above cannot be used for finding a shortest path in cyclic graphs that use
negative edge costs. The reason is that a shortest path cannot be found in this type of graph
because the search for it is infinite. For example, consider the cycle T1 = {C1, C2, C1}, where the
cost cp is zero before the search enters the cycle and the edge cost between C1 and C2 is -1. When
the search exits the loop T1, the cost cp is -1. If the search proceeds to vertex C2 next, which is
necessary since the search must be done on all adjacent vertices, the cost is -2. Hence, a path
with a smaller cost was found. This process continues because a path with a smaller cost is found
after each successive iteration on the loop T1. The reason for this is that the search is in the
process of computing the cost and also of creating this shortest path that it has found. However,
this negative accumulation continues until the cost cp is -∞. This means that a shortest path does
not exist because there will always be a path with a lower cost than the previous one.
2.2.1.5 Connected Graphs
The topic of connected graphs applies also to paths—after all, paths are graphs. A graph
is connected if each of its individual vertices can be reached from each other. This linkage
between these two vertices can be done with an arc, an edge, or a path. This means that each pair
of connected vertices in the graph need not be adjacent to each other (adjacent vertices share an
edge or an arc). The TSP graph on Illustration 2.1 is an example of a connected graph. Notice on
Illustration 2.1 that all the vertices are not adjacent but that they are all connected. That is, any
two vertices can be reached from any other vertex in the graph.
2.2.2
Classic Test Problems
Many of the modern studies on algorithms from the Journal of Artificial Intelligence
publish the algorithm’s running-times and benchmarking results. These results are mostly
obtained from experiments or empirical tests performed on algorithms that use a game or puzzle
as the test bench. Such puzzles include but are not limited to TSP, chess, 8-queens, Othello, 8puzzle, Rubik’s cube, and towers of Hanoi. The authors of these studies assume that their
19
audience knows how to set up problems for SSS. Therefore, the setups of these puzzles and
games are rarely explained. However, this assumption is not used in this document.
Nilsson refers to the process of setting up a problem for SSS as an art [Nil80]. I concur
with Nilsson in that setting up problems for SSS is not a trivial task. Therefore, an explanation of
the setups for the 8-puzzle and the 8-queens games is provided. These two problems were chosen
because they are ubiquitous in AI literature. Additionally, they are analogous examples of how
the problem for this Thesis was setup and solved.
2.2.2.1 The 8-Puzzle
The 8-puzzle is a sliding-block puzzle. It contains a grid of nine square slots in a board
that is divided into three rows and three columns. It also contains eight tiles that are numbered 1
thru 8. This board and tile arrangement is shown in Figure 2.1 below. The tiles are housed within
the slots of the board’s grid and they are restricted to occupying only one slot at a time (they
cannot partially occupy a slot). Because the grid has nine slots and eight tiles, there will always
be one empty slot. The empty slot is referred to as the space.
Figure 2.1: The 8-puzzle with tiles arranged in increasing order.
20
The space is allowed to change slots. This means that the space can move within the
board. However, the space can never move directly to a diagonal slot and its movements are
always discrete. The space must stay on the board and it cannot skip over slots to get to a
location. The space displaces the tiles that are housed in the slot that it moves to. The evacuated
tiles are relocated to the space’s prior location.
2.2.2.2 The 8-Queens
The components of the 8-queens problem are eight identical pieces called queens and one
board. The board is divided into eight rows and eight columns. Each of these rows and columns
is further subdivided into equally sized squares or tiles. Since each row and column contains
eight tiles, the entire board is made up of 64 tiles. The tiles are colored and arranged in a
checkered pattern that makes it easy to distinguish and identify adjacent tiles. Tiles that are
horizontally and vertically adjacent to each other alternate color and tiles that are diagonally
adjacent to each other have the same color. This checkered board and the eight queens on it are
depicted on Figure 2.2 below.
21
Figure 2.2: The 8-queens problem arranged so that none of queens attack each other.
These tiles are used as slots for the queens to occupy. Each queen is limited to occupying
one slot at a time. Furthermore, any of the queens can be placed on any of the empty slots on the
board. Any queen that occupies a slot on the checker board is attacking. The attacks can be on
other pieces or on slots on the board. Queens automatically attack pieces that are on any of the
slots that they are attacking. By default, a queen attacks all the slots in the row, column, and
diagonals that it is on. A piece can impede a queen’s attack. In this case, the queen’s range of
attack is limited to the slots that are between it and the piece that is impeding the attack; the
impeding piece is also being attacked. In the 8-queens problem, all the pieces are queens, and all
attacks are reciprocated. This means that a queen that is attacking is simultaneously being
attacked. Notice in Figure 2.2 that none of the queens are under attack and that none of them are
attacking each other. Notice also that each queen is attacking one row, one column, and two
diagonals. The solutions to the 8-queens problem are configurations such as the one on Figure
22
2.2, where none of the queens are attacking each other. That is, any configuration that has all 8queens on the board with out them attacking each other is a solution to the 8-queens problem.
Any configuration that has less that 8-queens on the board, or that has queens exchanging attacks
is not a solution. An example of a configuration of that is not a solution is on Figure 2.3 below.
Figure 2.3: The 8-queens problem where all queens attacking and being attacked.
2.2.3
Search-Graph Generation from an Implicit State-Space
Both finite and infinite state-spaces can be implemented as implicit graphs. This means
that state-spaces are also implicit. This concept makes SSS a real-world computer solution
because it can be used to solve problems that have infinitely large state-spaces (as is the case for
this Thesis’ problem). Implicit graphs, as opposed to explicit graphs, use limited computer
resources more efficiently. One example is in the use of computer memory; in an implicit graph,
the states are not present in the computer’s memory—yet the states can be accessed as if they
23
were. Another example is in the computer’s processor; in an explicit graph, a search must not
only be done for the goal state, one must also be done to locate the initial state. This is not true
for an implicit graph because the states are generated (i.e. computed) as opposed to being sought.
2.2.3.1 States and State-Spaces
The type of problem that is solved in this study is made up of discrete configurations.
These configurations are referred to as the states of the problem. The whole set of these
configurations are referred to as the state-space of the problem.
The 8-puzzle is an example of a problem that contains a discrete set of configurations.
Figure 2.1 above shows that the tiles are arranged according to the number on the tile. This order
is one configuration of the 8-puzzle. The tiles can be rearranged to a different configuration by
successively moving the space. An example of a different configuration that could result from
moving the space is shown on Figure 2.4 below.
Figure 2.4: The 8-puzzle with tiles arranged in random order.
The two configurations on Figures 2.1 and 2.4 are example of states from the problem’s
state-space. The set that contains all the different configurations of the 8-puzzle is the state-space
24
of the problem. The initial configuration is referred to as the initial state or as the start state and
the goal configuration is referred to as the goal state. Any of the configurations from the
problem’s state-space can be the initial state or the goal state of the problem. For example, the 8puzzle problem can use the tile order on Figure 2.1 as the start state and the configuration on
Figure 2.4 as the goal state, or vice-versa.
2.2.3.2 Trees and the Successor Operator
When dealing with implicit graphs, graph-searching-algorithms use a successor
operator5, Γ, to generate the search-graph. The search-graph explicitly represents a subset of the
implicit state-space. The successor operator, which is created from the problem-description, is
used to perform this action. The first step to creating the search-graph is to provide the graphsearching-algorithm with a state from the state-space. The graph-searching-algorithm uses this
state to generate the first node of the search-graph. Next, the graph-searching-algorithm feeds
this node, or state, to the successor operator, and the successor operator expands this node. This
results in newly added nodes to the search-graph. These nodes are connected to the root node by
an arc that originates at the root.
These search-graphs generated by graph-searching-algorithms are categorized as a
special type of graph called a tree. A tree that is a subset of the implicit state-space for the 8puzzle is shown on Illustration 2.2. Trees originate from a single node on the top row called the
root. In this study, the root always represents the initial state of the problem to be solved. If the
state from Figure 2.4 is the initial state, then Illustration 2.2 is an example of a tree using this
initial state as the root. Notice that the label on the root node is the state from Figure 2.4. Some
graph-searching-algorithms (such as reverse or bi-directional search6 [Rus03]) generate trees
with the goal state as the root. However, these algorithms are not used in this study.
5The idea and terminology of successive operator was adopted from Hart et al [Har68]. They use successor operator
to describe the node expansions of their heuristic search algorithm.
6In a bi-directional search, the start state and the goal states generate search-graphs; the solution is obtained when
the first node belonging to both search-graphs is generated.
25
Illustration 2.2 is an example of a tree that was generated by applying a graph-searchingalgorithm to an initial state from the 8-puzzle problem. First, the graph-searching-algorithm
generates the root of the search-graph. Second, it applies the successor operator to the root. This
results in a node-expansion which generates the successors of the root. In Illustration 2.2, the
successors of the root are the nodes on the middle row. Third, the successor operator is applied to
the nodes on the middle row which results in the production of the nodes on the bottom row.
Nodes that are generated by other nodes in a tree are referred to as offspring,
descendants, or successors. These nodes represent the states that their parent nodes, or parent
state, can transition to. Parent nodes or source nodes are nodes that can be expanded by the
successor operator to generate offspring nodes.
Illustration 2.2: A subset from the 8-puzzle state-space.
Drawing out the tree, as is done for Illustration 2.2, is common and conventional in AI
(and in computer science). Because trees have levels to which its nodes are assigned, it is
conventional to draw the lowest level of the tree at the top and successive levels underneath,
according to level order. The nodes from each level are drawn in the row assigned to the level.
26
(The convention for drawing the columns depends on the type of tree, but, generally, offspring
nodes are drawn underneath their parent nodes). The root corresponds to the lowest level node
and is therefore drawn at the top of the tree. The other levels of the tree are defined relative to the
root and to the node that was expanded to produce them. The level of the root is 0. When the root
is expanded, the level of the successor nodes is 1. When these successors are expanded, the level
of their offspring is 2, and so on.
2.2.3.3 Breadth of a Search-Graphs
In computer science, AI, and graph theory literature, if the number of successors for all
the nodes of a tree is the same, the number of successors is assigned as a property of the tree.
This property is referred to as the breadth of the tree. That is, a tree with breadth b means that all
its nodes have b successors. However, this definition for breadth will be relaxed to include trees
that have both of the following properties: (1) the parent nodes have a known maximum number
of successors, b, but not necessarily that number of successors; (2) the number of nodes that have
exactly b successors is much larger than the number of nodes with less than b successors. This
means that a tree with at most b successors per node, even though not always exactly b
successors per node, but that mostly has nodes with b successors, will be said to have breadth b.
The approximation implied by relaxing the definition of breadth can be justified by considering
infinite state-spaces—an infinite state-space limited to a maximum of b successors per node can
have an infinite number of nodes with exactly b successors. (This justification is used for a
worst-case analysis.)
For the graphs in this study, the exact number of successors spawned by each parent node
varies depending of the location of the node on the implicit graph. However, the maximum
number of successors for each state is known and fixed. An example that is analogous to this
study’s problem can be observed on the tree depicted on Illustration 2.2. This tree has breadth b
= 4, a root with only 2 successors, and the root’s successors with only 3 successors each. This
tree has breadth b = 4 because any state that has the space in the center of the 8-puzzle board can
transition to a maximum of four different states. Referring to the problem description on Section
27
2.2.2.1, the space cannot move diagonally but it can move vertically and horizontally. This
means that when the space is at the center of the 8-puzzle board, it can move up, down, left, or
right. Each of these space movements relocates the associated tile to the center of the 8-puzzle
board and results in a state-transition. For states that have the space in a corner, as is the case for
the root, only two state-transitions are available and hence, the root has only two successors as
shown on Illustration 2.2. States that have the space in the center of a row or column that is at the
edge of the 8-puzzle board have a maximum of three state-transitions. This means that the nodes
that represent these states have at most 3 successors. This is the relationship between the nodes
on the second row and those of the third row. See Illustration 2.2.
2.2.3.4 Depth of a Search-Graphs
In computer science, AI, and graph theory literature, trees are assigned another property
called the depth, d. It is an incremental property that is updated for a tree after each successive
application of the successor operator to all the nodes of a level (defined below) of a tree. This
identifier is also assigned to a set of newly generated nodes from the level. The depth of the tree
can change but the depth assigned to a node remains constant for the life of the tree. The root is
the first node that is assigned a depth and it is d = 0. The depth of the tree is also d = 0 when the
root has no successors. When the successor operator is applied to the root, and offspring are
generated, the depth of the tree is d = 1 and the depth of the root’s offspring is the same.
Applying the successor operator to all the root’s offspring generates the successors whose depth
is at d = 2, and the depth of the tree changes to d = 2. The depths of a tree can be visualized
using Illustration 2.2. First, the depth of the root node at the top row is d = 0; second, the depth
of the two nodes in the middle row is d = 1; third, the depth of the six nodes on the bottom row
is d = 2; last, the depth of the tree is d = 2.
28
2.2.4
Algorithm Analysis
Algorithms are a technology for processing data [Cor90]. An algorithm can be seen as a
black box7 that has an input and an output. The input is unprocessed data; the black box
represents the computer instructions, or source code, for processing the data; the output is the
processed data. Figure 2.5 below shows an example of algorithms that are represented as black
boxes. In this figure, Algorithm A is an example of a computer program’s source code being
referred to as an algorithm.
The term algorithm is mostly applied to well-defined routines within a computer
program’s source code. Examples of these routines are Algorithms B, C, D, E and F, which are
housed by Algorithm A.
Figure 2.5: Algorithms represented as black boxes.
2.2.4.1 Algorithm Measures
Algorithms are measurable. They are tested against the following criteria: (1) correctness,
(2) admissibility or optimality, (3) time-complexity, (4) space-complexity, and (5)
benchmarking. Correctness is a term assigned to an algorithm. It identifies whether an algorithm
yields the correct output when it processes the input data. Admissibility and optimality are terms
that are used interchangeably when concerning algorithms. This property indicates if a particular
7A
black box is an abstract model of a system. It emphasizes the inputs and the outputs, but it hides the inner
workings of the system.
29
algorithm always finds the best solution to the problem. If it does, the computational procedure is
called an admissible (or optimal) algorithm. Time-complexity is a measure that bounds the
running time of an algorithm. Time-complexity is completely independent of the computer
platform. Nonetheless, it does depend on the size of the input data. Space-complexity is also a
bound that is independent of the computer hardware and that also depends on the size of the
input data. However, where time-complexity bounds the number of computer instructions, spacecomplexity bounds the amount of memory required to store the data being processed.
Benchmarking is a measurement taken on a particular computer. It depends on the size of the
input data and on the computer platform, i.e. Operating System (OS), programming language,
compiler, Central Processing Unit (CPU) and Random Access Memory (RAM). Benchmarking
is used for measuring how an algorithm runs on particular computer.
2.2.4.2 Scalability
Scalable problems, with known optimal solutions, are often used as test benches for
measuring, testing, and analyzing algorithms against all the criteria described above. The
scalability of these problems is in their size. Scalable problems are used to answer questions such
as the following: “If an algorithm takes n seconds to solve a problem whose representation size is
m bytes, can it also solve a problem with representation size q bytes? If it can solve a problem of
input size q, how long will it take?”
Board games and puzzles such as TSP, n-puzzle, and n-queens are examples of scalable
problems that are used in Artificial Intelligence as test benches for analyzing algorithms. These
games are well-defined, have known solutions, and possess a variable that can be varied to
increase (or decrease) the size of the problem. With these problems completeness and
admissibility can be tested by observing if an algorithm returns the known optimal solution.
Time-complexity, space-complexity, and benchmarking can be performed by scaling the size of
all these problems. For instance, the number of cities n in the TSP, the number of tiles in the npuzzle, and the number of queens in the n-queens can be scaled by increasing or decreasing the
numerical value of. For example, the TSP problem with n = 9 cities, the n-puzzle with n = 8
30
tiles, and the n-queens with n = 8 queens were introduced. To scale these problems up, n can be
increased, e.g. to n = 1000. The scalability property of games and puzzles makes them useful for
estimating via empirical testing how graph-searching-algorithms perform with different sized
input data.
2.2.4.3 Complete Algorithms
An algorithm is complete if it produces the correct solution. Concerning graph-searchingalgorithms, completeness is the ability that an algorithm possesses for generating and reaching
the goal state in a graph. In search-graphs that do not have infinite-breadth or infinite-depth,
complete algorithms always find a path even if it is not the path with the smallest cost. This
means that when the goal node is reachable from several different paths, one of these paths is
guaranteed to be returned as the solution but that there is no guarantee that the minimum-costpath will be returned.
2.2.4.4 Admissible Algorithms
An admissible graph-searching-algorithm always returns the minimum-cost-path, even
when dealing with graphs that have many paths that link the initial state to the goal state.
Admissible graph-searching-algorithms only exist for graphs whose arc and edge costs are
greater than 0. There are no admissible graph-searching-algorithms for graphs that have cycles
and arcs values that are less than or equal to 0. The reason is that successive summing of the arcvalues by the graph-searching-algorithm always leads to the generation of a path with a smaller
path-cost until eventually, the path-cost ends up being -∞. Hence admissible algorithms only
exist for graphs whose arc costs are greater than 0.
2.2.4.5 Optimal Solutions
In the AI community, the terms minimum-cost-path and shortest-path are often used
interchangeably. However, it is important to recognize when these expressions have different
meanings. The shortest-path is the sequence with the least number of nodes that links the initial
state to the goal state. The minimum-cost-path is the sequence with the smallest path-cost value
31
which results from summing all the arc values in the path that links the initial state to the goal
state.
The optimal solution is not the shortest-path when it is not the minimum-cost-path. This
type of shortest-path occurs in graphs that have arc-cost values that vary and that are greater than
0. In this situation a path with 5 nodes can have a path cost of 1,000, e.g. one instance is when
the four edges that connect the five nodes have the following arc-costs: {1, 2, 497, 500}.
Additionally, a path with 1,000 nodes can have a path cost of 5, e.g. a path with 999 arcs with
arc-costs such as {0.005, 0.09, 0.15, … , 0.05}. In the latter case, some of the arcs have cost
values much greater than the latter case.
The shortest-path is always the minimum-cost-path when all the arcs of the graph have
the same cost value and it is greater than 0. This can be explained with an example of a graph
whose arcs all have the same cost. For simplicity, let the arc costs be equal to 1. In this graph, all
paths with 5 nodes have path cost equal to 4, which is the number of arc steps that were taken to
get from the initial node to the goal node. Hence, the shortest-paths of graphs that have uniform
arc-costs that are greater than 0 are always minimum-cost-paths and therefore, optimal solutions.
2.2.4.3 Asymptotic Analysis
Order-of-growth [Cor90] functions g(n) are used to specify the time or space that is used
by algorithms for any value of n. This means that the analysis begins with very small n, e.g. n =
1, and continues all the way to very large n, e.g. n = ∞. If the order-of-growth function g(n) of an
algorithm is not known, asymptotic analysis must be performed to obtain it. No computer
platform knowledge is required to perform asymptotic analysis since asymptotic analysis is
independent of any computer platform. However, the number of instructions (or lines of code)
that the algorithm uses to process input data of size n for all values of n must be known and this
value must be expressed as a function f(n) where n is the size of the algorithm’s input. This
function f(n) is used to obtain the growth-function g(n). This is accomplished by dropping all
terms on f(n) that are made negligible as n gets very large. Only the terms that are not made
negligible as n gets very large are used to create the growth-function g(n). For example, if the
32
polynomial f(n) = n3 + n2 is the number of instruction used by the algorithm to process an input
of size n, the algorithm’s growth function is g(n) = n3 because the n2 term is dropped since it
becomes orders of magnitude smaller as n gets very large; hence n2 becomes negligible.
Order-of-growth functions g(n) are used in asymptotic notation [Cor90] as the arguments
to the O, Ω, and Θ operators. These operators are used in asymptotic analysis to communicate
how the time and space used by the algorithm are affected as the size of the input data n
increases. The use of these operators is referred to as O-notation, Ω-notation, and Θ-notation,
and their respective purpose is as follows: (1) O( g(n) ) describes the maximum (time or space)
in terms of the grown-function g(n) that an algorithm can use for any value of the input size n; it
is useful for specifying the worst-case scenario conditions; (2) Ω( g(n) ) specifies the minimum
(time or space) in terms of the growth-function g(n) that an algorithm must use to process an
input of size n; Ω( g(n) ) is useful for identifying the minimum resources required to successfully
run the algorithm; (3) Θ( g(n) ) is useful for specifying both the minimum and the maximum
(time or space) in terms of the growth function g(n) required to process the input of size n.
Figure 2.6 below provides some general examples of how O-notation, Ω-notation, and Θnotation are used to create upper bounds, lower bounds, and both upper and lower bounds,
respectively for the growth function g(n) = log(n).
33
Figure 2.6: (a) O( g(n) ); (b) Ω( g(n) ); (c) Θ( g(n) ).
2.2.4.4 Time-Complexity
Running-time is the number of primitive steps used on a particular computer to run an
algorithm. In the case of graph searching algorithms; the running time depend on the input and
output of the successor operator and on the number of nodes that the successor operator
generates while creating a solution [Rus03]. Running times are computed by using the following
properties of graph-searching-algorithms: (1) the maximum number of successors from a node;
(2) the maximum length of a path; (3) the maximum depth of the search-tree. Running times are
expressed in terms of growth-functions. Each of these functions represents the number of
successors that were generated to obtain a solution in terms of the input size n, which can vary.
34
This value allows different algorithms to be compared to each other independently of the
platform in which they will be used.
2.2.4.5 Space-Complexity
Computer memory is a space-complexity issue. Search methods that deal with implicit
state-spaces have the tendency to exhaust memory before finding the solution. The reason is that
the nodes that are generated during the search are stored in the system’s memory. Some graphsearching-algorithms keep all these nodes for the duration of the search; other graph-searchingalgorithms are more efficient, they remove from memory the nodes that are no longer required.
These algorithms have less of a tendency to exhaust memory, which can be seen by analyzing
their space complexity, which does not depend on all the successors that were generated during
the search.
As with the time-complexity, the space-complexity depends on the input and output of
the successor operator and on the number of nodes that are generated to obtain a solution
[Rus03]. Graph-searching-algorithms generally depend on two properties of the search tree: (1)
the breadth b, which is the maximum number of successors from any node in the search-tree, and
(2) the depth d, which is maximum number of ancestors that any node can have within the
search-tree. Therefore, larger state-spaces tend to generate more nodes than smaller state-spaces
to obtain a solution. So the size of the state-space must be minimized as much as possible
without affecting the quality of the solution, in order to prevent nodes that can be considered
redundant from being generated.
2.2.4.6 Benchmarking
If scalable, complete, and optimal algorithms are being compared for selection in a realtime system, two other properties of the algorithms must be examined: they are the time and
space used by the algorithm to generate a solution. Concerning time, if a solution is not produced
within the provided time slot, the solution might be useless when it arrives to module in which it
is to be used. Concerning space, if the algorithm uses up all the memory in the computer,
35
chances are that the computer will begin paging or that it will malfunction, which means that the
solution will take longer to be obtained; in the case or memory paging, the algorithm will run
much slower during all the processing; in the case of hardware malfunction, the system could
experience down time,. In both cases, the result is that a solution is not obtained in real-time.
Introducing these undesirable characteristics into a real-time system that is undergoing
development can be avoided by selecting the algorithm that best balances the use of space and
time—while solving the problem for which the system is being developed of course. For
example, the candidate algorithms must first be scalable, complete, and optimal to an extent
determined by the problem’s domain. Next, the growth functions of these algorithms are
compared against each other to eliminate the algorithms that are least likely to provide a solution.
Finally, the time and space growth functions of the remaining algorithm are compared and the
algorithm that has the best chances or returning a real-time solution is selected. The algorithm
that gets selected algorithm must have a time and space growth functions that indicate that this
algorithm outperforms the others when they are run on the same platform to solve the problem
for which the system is being developed. Although the algorithms can be selected by comparing
the growth functions of the time and space complexities, the platform in which the selected
algorithm will provide a real-time solution is not known.
Benchmarking is a tool that is used to estimate the performance of an algorithm on a
particular computer. This analysis tool is generally used to test how much or what percent of
time and memory are used on a particular computer platform for an algorithm to find a solution.
Benchmarking gauges how a particular algorithm balances the computer’s physical resources
such as memory and processing capabilities that are used to generate a solution.
After a candidate algorithm is selected, the next task in developing the real-time system is
to estimate the optimal computer for the algorithm to run on. Estimating the optimal computer
means to identify the platform that provides only the required memory and processing power that
is necessary to obtain a solution. These hardware estimates can be obtained by performing timing
and memory tests by using the algorithm on the desired hardware to solve problems that have the
36
expected size of the input. This can be done using the process of elimination on computer
platforms. For instance, assume a situation where the goal is to minimize monetary cost, and the
desired response time is one second, and the following four computer platforms are available: (1)
personal computer, (2) high-end computer, (3) super-computer, and (4) cluster of m computers.
Benchmarking can begin with the personal computer and if it solves the problem in less
than one second, a cost effective solution has been obtained. However, if it takes the personal
computer more than a second to obtain a solution, or if it exhausts the memory during the
process, one of the three following actions should be performed: (1) select a different algorithm
to benchmark on the personal computer, (2) benchmark the existing algorithm on a different
computer platform, or (3) use a benchmarking tool to estimate the required resources necessary
to run the algorithm.
Having done time and space complexity analysis eliminates option (1). Nonetheless,
options (2) and (3) both point to the same problem: it is that the algorithm requires more
resources than those of the personal computer. Hence Option (2) would require further
benchmarking to be performed by using the other platforms to solve the problem. Option (3) is
used if a computer platform baseline is not identified; in this case, a commercially-off-the-shelf
benchmarking tool can be used to estimate or identify the minimum time and memory required
by each computer platform to obtain a solution from the algorithm.
2.2.5
Intelligence in Search: Human vs. Artificial
Illustration 2.2 above depicts a partial search-graph that was generated by a graph-
searching-algorithm for solving the 8-puzzle. The search uses the problem-description on Section
2.2.2.1, the configuration on Figure 2.4 as the initial state, and the configuration on Figure 2.1 as
the goal state. Also, as evident from the absence of the goal state on the search-graph, no solution
or path was found. However, no mention is given to the type of graph-searching-algorithm that
performed this search-graph. Before discussing such algorithms, an important question needs to
be considered. That question is: “Why are graph-searching-algorithms from AI beneficial for
solving the 8-puzzle, the 8-queens, and other problems like them?”
37
First of all, consider the 8-puzzle problem just described. The first movement for
transforming the tile arrangement on Figure 2.4 to the tile arrangement on Figure 2.1 is not
evident or intuitive in human intelligence or for artificial intelligence algorithms. Nonetheless,
from Figure 2.4, and from the 8-puzzle problem description, it is evident that from the state on
Figure 2.4, only two state transitions can result. The same choice of state transitions is available
to the human and to a well-defined AI algorithm. Hence, both humans and AI theories can and
do solve this problem in the same manner—by trial-and-error. This approach is necessary for
both human and artificial intelligence when the set of successive state transformations that link
the initial state to the goal state are not known.
Another method that is widely used by human and artificial intelligence is the use of
heuristics. The 8-puzzle is one example that demonstrates that human intelligence uses heuristics
(i.e. prior knowledge) to solve problems. For instance, consider the 8-puzzle that uses the
random configurations of the tiles as the initial state and the configuration on Figure 2.1 as the
desired state. The tile order on Figure 2.1 provides a heuristic that is easily recognized by
humans. It is that the order of the tiles for the solution are arranged in ascending order from left
to right and from top to bottom. To solve this problem a human would use hybrid of this
heuristic combined with the use of trial-and-error to form a method that obtains a solution8.
In human and in artificial intelligence, the use of heuristics is done to speed up the time to
obtain a solution. For example, one benefit to human intelligence that arises from the heuristic
implied by the tile configuration on Figure 2.1 is that a reference that contains the desired state is
not needed since it can easily be thought up. This heuristic speeds up the time for a human to
obtain a solution, since the overhead associated with referencing the desired state is not there. On
the other hand, if the desired state is the one on Figure 2.4, the tile configuration does not have a
pattern known to most humans. Also, a human that cannot memorize this tile order will not have
a heuristic and will need a reference of the desired state. AI has algorithms that use heuristics to
perform the search for a solution. As is the case for human intelligence, AI algorithms also use
8The
A* algorithm, which is main element in this study, implements this approach formally.
38
heuristics to shorten the time to obtain a solution for a problem. (An example of an AI algorithm
using a heuristic is the A* algorithm using the Euclidean distance to expand only the nodes
between, and in the proximity of, the start state and the destination state.)
Human intelligence and AI algorithms both solve problems using a hybrid system
composed of trial-error guided by heuristics. However, since AI methods are implemented with a
computer, they are faster and less prone to error when the problem is large albeit the problem
must be well defined. However, when AI algorithms are not provided with all the required
information, human intelligence is faster and more likely to yield a solution. Nevertheless, the
efficiency of AI algorithms for SSS problems, such as problems like the 8-puzzle, supersedes
that of human intelligence in that AI algorithms can quickly obtain solutions for all possible
configurations with any configuration acting as either the initial of the goal state. For example,
AI algorithms are much more efficient for solving the 8-puzzle with any configuration acting as
the start or as the goal state.
AI algorithms are applicable to a large range of problems that can be represented as
states. They are particularly useful for problems that have very large state-spaces. This can be
illustrated by considering the 8-puzzle configuration on Figure 2.4 and using it as the initial state.
From here, only two state-transitions are available. Very little thought and time is required to
commence the trial-and-error search for a human or a computer. Now, consider solving the 8queens problem using the configuration on Figure 2.3 as the initial state and the problem
description that is provided on Section 2.2.2.2. For a human who is unfamiliar with the solution,
the first action is not evident. Neither is it for AI algorithms, however, the computer can go
through the trial-and-error faster than a human. And different from the 8-puzzle configuration
that only has two state-transitions initially, the number of state-transitions available from the 8queens problem is combinatorial from the start. Hence, because AI algorithms use a computer to
perform SSS, the throughput is larger when using AI for solving problems that can be
represented as states. Therefore, the effort associated in implementing AI algorithm for solving
such problems is justified.
39
2.2.6
A* Algorithm
The A* algorithm commences a SSS by converting the initial state to a node. This task is
referred to as node-generation. The algorithm continues the SSS by applying the successor
operator Γ to this newly generated node. If this procedure results in newly generated child nodes,
the parent node is called the root of the search tree, and the procedure itself is referred to as
node-expansion. All nodes that are generated but that do not produce other nodes, whether an
attempt to expand them is made or not, are called the leaves of the search-tree. The nodes that are
generated and expanded to produce other nodes become ancestor or parent nodes on the searchtree. SSS is a procedure that performs node-expansions until a path is found. If no path can be
found and no further node-expansions can be performed, the search is terminated without having
found a solution.
Two things are used to classify graph-searching-algorithms: (1) the node expansion
order; (2) the use or nonuse of heuristic information. Algorithms that expand nodes in a fixed
order and that do not use heuristic information are classified as blind search or as uninformed
search strategies. The Depth-First-Search (DFS) and the Breadth-First-Search (BFS) algorithms
are two examples of blind search algorithms. These algorithms have the drawback of expanding
nodes that are not in the solution path. Algorithms that use heuristic information tend to expand
only the nodes that are in the solution path. These algorithms are referred to as heuristic search
or informed search strategies. They are also categorized as Best First Search (BFS) strategies
[Rus03]. BFS algorithms are distinguished from each other by their evaluation function. The A*
algorithm is categorized as a BFS algorithm. Because uninformed search algorithms have the
tendency to generate and expand nodes that are nowhere near a solution path, informed search
algorithms are generally superior to uninformed algorithms.
2.2.6.1 Evaluation Function
The A* algorithm uses an evaluation function f(ni) that is the sum of two other functions:
cost g(ni) and heuristic h(ni). These three functions are all a functions of the node ni that is
40
currently being generated. Equation 2.4 below is the evaluation function used by the A*
algorithm.
f ( ni ) = g ( ni ) + h ( ni )
(2.4)
where
f(ni)
is the evaluation function; and
g(ni)
is the cost function; and
h(ni)
is the heuristic function; and
ni
is the ith node that is generated
The values fi returned by the evaluation function f(ni) are used for assigning nodes a
priority value for upcoming node expansions. Equation 2.5 below describes the evaluation
function value fi and its relationship to the evaluation function f(ni) and the associated node ni at
which it was computed.
f i = f ( ni )
(2.5)
where
fi
f(ni)
ni
is evaluation function value for the ith node; and
is the evaluation function; and
is the ith node
The A* algorithm uses the cost function g(ni) to compute the cost g(ns, ni) for getting
from the start node ns to the current node ni. The cost g(ns, ni) is one of the criteria that is
required for generating paths that are optimal solutions. Additionally, since the optimal solutions
are minimal cost paths, the arc-cost carc must be greater than zero (i.e. carc > 0). Equation 2.6
41
below shows the relationships between the cost function g(ni), the cost g(ns, ni), the arc-cost carc,
the start node ns, and the current node ni.
j =i
g ( ni ) = g1 ( ns , ni ) = ∑ carc
j =1
(2.6)
where
ni
is the ith node that is generated and also the current node; and
ns
is the first node that is generated and also the start node; and
g(ni)
is the cost function; and
g(ns, ni) is the total cost for getting from the start node to the current node; and
carc
is the arc-cost incurred by transitioning from one node to another node.
Heuristic data is information from the problem domain. The A* algorithm uses heuristic
data mathematically in the form of a heuristic function h(ni). It is used to obtain an estimate of
the effort to get from current node ni to the goal node ng. This speeds up the search by
influencing the node-expansion order and by limiting expansions to only the nodes that seem to
be in the solution path. Equation 2.7 below is the heuristic function h(ni) that is used by the A*
algorithm.
h ( ni ) = h1 ( ni , ng )
(2.7)
where
ni
is the ith node that is generated and also the current node; and
ng
is the one of the last nodes that are generated and also the goal node; and
h(ni)
is the heuristic function; and
h1(ni, ns)
is an estimate for getting from the current node to the goal node
42
2.2.6.2 The Heuristic Function’s Admissibility
The A* algorithm does not guarantee optimal solutions when using heuristic functions
that are not admissible. On the other hand, if the heuristic function h(ni) is admissible, it becomes
the second criteria that is used to generate an optimal solution (the values assigned as arc-costs is
the first criteria).
The estimate h1(ni, ng) returned by a heuristic function is the property that determines a
heuristic function’s admissibility. Admissible heuristic functions return an estimate h1(ni, ng) that
is equal to or less than the effort required to get from the current node ni to the goal node ng.
Since heuristic functions are rarely exact, they mostly return measures that under-estimate the
effort. This means that admissible heuristic functions tend to be optimistic. Furthermore,
admissible heuristic functions never return an estimate that is greater than the required effort for
getting from the current node ni to the goal node ng. That is, they never over-estimate the effort.
This means that admissible heuristic functions are never pessimistic [Rus03].
An admissible heuristic functions that is commonly used in SSS distance and routing
problems is the two-dimensional Euclidean distance. Two facts about the two-dimensional
Euclidean distance establish why it is admissible. First, computing the two dimensional
Euclidean distance between two points returns the straight-line distance between those points.
Second, the shortest distance between two points is a straight-line. Therefore, the Euclidean
distance never over-estimates the travel distance for getting to a goal location from a current
location because it returns the exact distance. Hence it is an admissible heuristic function.
Equation 2.8 below is the two-dimensional Euclidean distance in terms of an initial and a goal
node where both nodes represent distinct locations on an x-y plane.
d Euc ( ni , ng ) =
(x
− xi ) + ( yg − yi ) ,
2
g
ni = n ( x, y )i ,
2
(2.8)
ng = n ( x , y ) g
43
where
dEuc(ni, ng)
is the Euclidean distance as a function of the current and the goal
node; and
ni
is the current node; and
n(x,y)i
ni
is the current node, which represents the (x,y)i coordinate; and
is the goal node; and
n(x,y)g
is the goal node, which represents the (x,y)g coordinate
2.2.6.3 The OPEN and CLOSED lists
The A* algorithm uses two lists to account for all the nodes that get generated and
expanded during the search. These lists are named OPEN and CLOSED. The OPEN list is a
prioritized list of nodes that are arranged according to the evaluation function values fi that each
node is assigned. These two lists also enforce for the entire duration of the search that only one
node is generated to represent each distinct state from the state-space. Consequently, each node
that is generated is always on either the OPEN list or the CLOSED list. In these lists, each node
is assigned a record and each record contains two fields: (1) the evaluation function value fi =
f(ni) at which node expansions are to occur or have occurred, and (2) the associated node ni (See
Table 2.1 below).
Table 2.1: Format of OPEN (and CLOSED) lists.
Name
Symbol
Evaluation function value
fi
Description
The smallest evaluation function fi value for the node
ni .
Node that is to undergo (or
A node associated with a state on the problem
ni
has undergone) expansion
domain.
44
All nodes that are generated get placed on the OPEN list in ascending order of their
corresponding evaluation function value fi. That is, they are arranged so that the nodes with the
smaller evaluation function values fi are at the top of the OPEN list. The A* algorithm always
expands the node at the top of the OPEN list, which always has the smallest evaluation function
values fi-min. The nodes on the OPEN list are the only nodes that are allowed to undergo node
expansions. After a node undergoes expansion, it gets placed on the CLOSED list; nodes on the
CLOSED list are restricted from undergoing further node expansions. To undergo further node
expansions, these nodes must be moved back to the OPEN list.
In general, node expansions generate several other nodes. To determine their place on the
OPEN list, the evaluation function value fi is always computed for each of the newly generated
nodes. If one of these newly generated nodes is on the CLOSED list, the node gets discarded
unless the newly computed evaluation function value fi is smaller than the existing value. When
the newly computed evaluation function value fi is smaller than the existing value, the node is
returned to the OPEN list and the evaluation function value fi gets updated with the most recently
computed value. In addition, the node’s previous path gets replaced with the most recently
generated path. That is, the path that led to that node’s generation and expansion, which resulted
in the node being placed on the CLOSED list, gets discarded and the path which generates the
node with the smaller evaluation function value fi is used in its place.
2.2.6.4 Time and Space Complexity of the A* Algorithms
The A* algorithm is complete; it is guaranteed to find a solution if one exists. It is
optimal when an admissible heuristic function is used; it returns the path with minimum cost if
the heuristic function never overestimates the goal node while expanding the fewest nodes than
any other search algorithm while generating the solution [Rus03]. However, the A* algorithm’s
time and space complexities are exponential when the error in the heuristic function is greater
than the logarithm of the actual cost. Russell and Norvig [Rus03] use the following equation to
describe this bound:
45
(
h ( n ) − h* ( n ) ≤ O log ( h* ( n ) )
)
(2.9)
where
n
is the current node; and
h(n) is the heuristic function; and
h*(n) is the actual cost for getting from the current node to the goal node.
The use of a non-admissible heuristic function might yield a more accurate solution at the
risk of getting exponential growth from the algorithm. On the other hand, sub-optimal solutions
can be obtained by the A* algorithm if an admissible heuristic function is used. Therefore, the
time and space can be bounded if an admissible heuristic function is used. Since the A*
algorithm is complete, optimal, and can be bounded in both time and space, its implementation
seems computationally feasible. For these reasons, it is to be implemented as the route finding
and obstacle avoidance module of real-time UAV guidance system that is to be developed as part
of this study.
The resulting guidance system is to undergo benchmarking to estimate the required
computational platform. To prevent exponential growth of the algorithm, which would result in
exhausting the computer’s memory, the Euclidean distance is used as the heuristic function since
it is known to be an admissible heuristic function. This should eliminate the possibility of adding
memory problems by prematurely using an experimental heuristic function. Moreover, the
benchmarking on the guidance system should provide statistics of how, when, and under what
conditions the A* algorithm exhausts the computer’s memory. Removing the variables added by
using a non-admissible heuristic function, does not guarantee real-time performance.
The goal of this study is not to find the limitations of the A* algorithm, but to use the
theory and technology in a real-world application. Hence, if the A* algorithm cannot perform in
real-time or if it exhaust the allotted memory of the target computational platform, an analysis
46
will need to be performed to determine if it is more efficient to follow the project through by
performing one of the following tasks:
•
If the targets platform suffers from insufficient memory, modify or replaced the
A* algorithm with one of its variants (e.g. memory-bounded A* (MA*),
Simplified MA* (SMA*), Iterative-deepening A* (IDA*) )
•
If the guidance system cannot perform in real-time, use a precision benchmarking
tool to determine the required resources to run the guidance system
•
benchmark the system using different computer platforms
47
Chapter 3: Design, Implementation, & Integration
A needs analysis was conducted prior to beginning any technological work on the project.
From this needs analysis, it was determined that this project’s mission would be to implement a
computer program that uses terrain elevation data to intelligently generate safe UAV flight
trajectories. Also, from this needs analysis, the key goals of this project were to reduce
dependence on UAV controllers during missions, to allow real-time generation of flight-patterns,
and to update the current flight-pattern altering and generation process. This needs analysis
resulted in a computer program that runs on a high end computer that is linked to the DFCS realtime computer network.
This guidance system was conceptualized after the needs analysis and the research phases
had been completed, but prior to the commencement of the design and development phases.
Between these phases was an intermediate phase—the product specifications phase. This phase
yielded the conceptual product whose specifications are listed in Table 3.1 below.
Table 3.1: Product Specifications.
Specification
Description
No.
The computer program will be compatible with the personal computer
1
platform.
2
The operating system will be Windows XP™.
3
The graph search algorithm will be A* or one of its variations.
The A* heuristic function will be the two-dimensional Euclidean distance
4
formula.
The WSMR terrain will be obtained from the available elevation database
5
(DTED level-2 with 30 meter resolution).
6
The computer program will be provided will the elevation data of the WSMR
48
terrain.
The computer program will be capable of autonomously finding and
7
producing flight-patterns over variable elevation terrain.
8
The computer program will output fully compatible DFCS flight-patterns.
This computer program’s capabilities will be completely useable for airborne
9
UAV in real-time, that is, during DFCS missions.
The computer program will have a GUI that allows an operator to specify the
10
desired flight-pattern’s start and destination locations.
The computer program, and its GUI, will be capable of accepting flight
11
profile parameters.
The computer program’s GUI will be able to display the digital terrain
12
elevation data.
The computer program’s GUI will be able to display the DFCS flight13
patterns that are generated by this computer program.
The computer program that resulted from these specifications is the RTPP; its
architecture is divided into two parts that are named alpha prototype and beta prototype. The
alpha prototype is the last software version (i.e. last computer program) that used the A* path as
the UAV guidance solution. The beta prototype is the latest software version of the RTPP used
in this study; it outputs flight-patterns as the flight guidance solution. The alpha prototype
architecture is a subset of the beta prototype architecture. These software architectures are treated
as if they were distinct to make their explanations clearer.
3.1
METHODOLOGY
3.1.1
Planning
The developmental planning was done using the spiral process [Boe88]; this software
production model did produce the benefits it claims such as improved developmental efficiency
49
and software quality as well as user-needs accuracy. It kept the software tasks on track by
scheduling user requirements and product specifications reviews throughout the development
process.
All the programming tasks that were scheduled in the spiral were implemented using only
Object Oriented Programming (OOP) [Dei01] techniques. Table 3.2 summarizes this software
development methodology.
Table 3.2: Development Methods.
Methods
Spiral model
Object oriented programming
3.1.2
Development Overview
Microsoft products, tools and technologies were used to develop most of the project (e.g.
Windows XP, MFC, Visual C++.NET). Silicon Graphics OpenGL™ [Woo97] was used to
render the graphics to the GD object in place of the Microsoft graphics library (Microsoft
Graphics Device Interface (GDI)). The source code was written with Win32™ Applications
Programming Interface (API) functions (i.e. Windows XP-specific C programming language
commands); OpenGL functions, and standard C++. The RTPP was programmed in standard C++
as classes [Dei01]. Not all objects were created with these classes. The Microsoft Foundation
Classes (MFC™) [Kru98] library, which comes with the Microsoft Visual C++.NET™ [Vis03]
compiler, was used to setup the graphics display and create the RTPP Graphical User Interface
(GUI) and its components. The MFC-OpenGL rendering setup was implemented by overwriting
the MFC CView base class as recommended by Rogerson [Rog95]. The RTPP View class
renders OpenGL, instead of Windows GDI, and it possesses all the functionality of the MFC
CView base class. Furthermore, the entire GUI was created automatically with the compiler (i.e.
Microsoft Visual C++.NET [Vis03]). The steps that were used to create the GUI with this tool
50
are as follows: (1) use the compiler’s menu to create a New Project, (2) on the dialog box that
appears select the MFC Application option; (3) then specify the properties of the desired GUI
from the options lists on the dialog boxes that follow (A complete description and explanation of
Microsoft Windows MFC programming is provided in Kruglinski’s book [Kru98]). This
procedure yielded the framework setup of the RTPP as a Single Document Interface (SDI) MFC
Application. The development products, tools and technologies (e.g. operating system, compiler,
programming interfaces, etc.) are summarized below in Table 3.3.
Table 3.3: Tools and Technologies.
Tools
Microsoft Windows XP
Microsoft Visual C++ compiler
Microsoft Foundation Classes
Win32 API
Standard C++
OpenGL
3.1.3
Target Platform
Table 3.4 lists the specifications of a high end computer that was created to estimate the
required platform for testing the real-time performance of the RTPP. The main question at the
start of the development effort, which turned out to be a minor issue, was what real-time
operating platform with regard to computer hardware and software was required to run the A*
algorithm. This question was answered during the waypoint implementation phase of the RTPP
alpha prototype development. The outcome obtained from benchmarking the A* algorithm on
the high end computer (whose hardware platform is specified in Table 3.4) is that A* algorithm,
when called from RTPP alpha prototype, can perform real-time. This conclusion was obtained
51
from having observed that A* paths (that contain numerous changes in direction—too many and
too frequent to be realistic flight trajectories—and that span over 100 miles) were returned from
the fledgling RTPP alpha prototype in less than 1 second. This conclusion is supported by further
empirical testing in which similar performance was exhibited when using computers equipped
with as little as half the resources of this computer.
Table 3.4: RTPP Computer Core Architecture Specifications.
Product
Description
Model No.
ASUS P5B LGA 775 Intel P965 Express
Motherboard
P5B
ATX Intel
Intel Pentium D 950 Presler 3.4 GHz LGA
Microprocessor
BX80553950
775 Processor
Corsair XMS2 2GB (2x1GB) 240-Pin
Random Access
TWIN2X2048DDR2 SDRAM DDR2 800 (PC2 6400)
Memory
6400PRO
Dual Channel Kit Desktop Memory
Western Digital Raptor 74 GB 10,000
Hard Drive
WD740ADFD
RPM Serial ATA150 - OEM
3.2
RTPP ALPHA PROTOTYPE
This section discusses the six key modules of the RTPP alpha prototype; they are the
following: (1) the Terrain Map File Processing (TMFP) object, (2) the Dynamic Array (DA)
object, (3) the A* Algorithm (ASA) object, (4) the Graphics Display (GD) object, (5) the Dialog
Box (DB) object, and the (6) the Graphical User Interface (GUI) object. These modules are listed
in Table 3.5 below and their functional details are explained after a brief overview of the
developmental methods and tools.
Table 3.5: RTPP Alpha Prototype Modules.
52
No.
Object/Module
Acronym
1
Terrain Map File Processing
TMFP
2
Dynamic Array
DA
3
A* Algorithm
ASA
4
Graphics Display
GD
5
Dialog Box
DB
6
Graphical User Interface
GUI
The GUI objects activate the other objects from Table 3.5—the internal ones which are
not visible on the GUI (such as the terrain-map file processing object, the dynamic array object,
and the A* algorithm object). The objects from Table 3.5 and their relationships to other
components are shown in Illustration 3.1 below. This illustration depicts these modules9 in block
diagram from, and it displays the components of each module. Arrows indicate the passing of
data between modules.
9The
words object and module are used interchangeably in this section.
53
Illustration 3.1: RTPP alpha prototype architectural diagram.
3.2.1
GUI Object
The interface between the RTPP alpha prototype and an operator is a Windows XP
graphical user interface (GUI). Figure 3.1 below shows an operator using the GUI object which
is running on the high end computer whose specifications are listed in Table 3.4.
54
Figure 3.1: Operator using RTPP alpha prototype GUI.
The GUI object contains a menu, a toolbar and a graphics display from which the
operator can issue commands via the keyboard and/or mouse. For instance, the operator can
bring up dialog box (DB) objects (such as for selecting a terrain elevation map file) with the GUI
menu or toolbar, and for the case of the graphics display, the operator can enter data (such as the
location of the virtual UAV) by clicking on the graphics display with the mouse. The GUI object,
the GD object, and the DB object are depicted on Figure 3.2 below.
55
Figure 3.2: RTPP alpha prototype GUI object.
Table 3.6 below summarizes the tasks that can be executed from the GUI object. Tasks 1
and 2 are used for loading the RTPP with data; they rely on DB objects and on the TMFP object.
Tasks 3, 4, and 5 use the GD object for rendering terrain elevation maps and the A* path. Task 6
counts the number of nodes that are generated by the ASA object. Tasks 7 and 8 use DB objects
to obtain the constraints that will be imposed on the resulting A* path. Task 9 uses either DB
objects or the toolbar on the GUI object to select the initial and final locations of the virtual
UAV. Task 10 uses the toolbar on the GUI object to activate a path search with the ASA object.
Table 3.6: GUI Object Tasks.
56
Task No.
Description
1
Set the type of dialog box object to be called.
2
Bring up a dialog box object.
5
Enable or disable features of the graphics display.
6
Activate or deactivate the generated-nodes counter.
7
Provide a dialog box for the user to input the virtual UAV flight altitude.
Provide a dialog box for the user to input the minimum Above Ground Level
8
(AGL) distance that will be allowed between the virtual UAV and the terrain
directly underneath it.
Provide a dialog box for the user to input the initial or the final location for the
9
desired route.
10
3.2.2
Activate the A* algorithm.
Graphics Display Object
The Graphics Display (GD) object, as can be seen on Figure 3.2, is the area enclosed by
the GUI frame. It is rendering a solid black scene. The GD object has several purposes. One is to
render the virtual terrain. Another is to provide a user-friendly interface to RTPP operators. And
yet another is to provide the display area as a screen-world that represents the real-world; this is
for selecting10 the virtual UAV initial and final positions quickly, easily and without error. The
accuracy of the rendered or selected data on/from the GD object is vital to obtaining a valid
solution from the RTPP. The GD object’s tasks are described on Table 3.7 below as tasks
performed on the GD object.
Table 3.7: Graphics Display Object Tasks.
Task No.
10Mouse
Task
Description
clicks are used for selecting the virtual UAV initial and final positions.
57
1
View Natural Map
Display the terrain map in natural views.
2
View Contour Map
Display the terrain map in contour view.
3
View Grid
Display the grid.
4
Zoom In/Out
Increases/Decreases the display’s level of
detail.
Shift the displayed map left, right, up, or
5
Pan Terrain Map
down.
Display borders assigned to an area of the
6
View Borders
terrain map.
Recognize mouse clicks as inputs that set
7
Select Start/Destination Location
the route’s initial and final locations.
Transform screen environment to
Convert screen coordinates (sx, sy) to
real-world environment
real-world ENU (x, y) coordinates.
8
Use input ENU (x, y) coordinates to
Snaps input ENU (x, y)
obtain the quantized value of the map
9
coordinates to quantized ENU (x,
partition that was clicked, whose value is
y) coordinates
recorded on the terrain map file.
10
View Path
Displays the A* path.
11
Toggle Contour Map View
Alternate between terrain map views.
Toggles rendering of selected objects:
Inhibit/Enable Rendering of
12
applicable to terrain map, borders, A*
Selected Graphics Objects
paths, and grid.
Tasks (1) and (2) from Table 3.7 are to render the terrain map in natural view and in
contour view, respectively. Task (11) is to toggle the GD object between the two views. Figure
3.3 below contains snapshots of these two map views. The natural terrain view is on the left side
58
and the high contrast color contour view is on the right side. The natural view allows a user to
identify higher elevation terrain without the use of a legend. Higher terrain elevations are
rendered as a darker shade of brown, and lower terrain elevations are rendered as a bright shade
of yellow. The high contrast color map renders the elevations by value. This allows an operator
to easily identify the contours that separate terrain elevations. A legend is required for
identifying which color corresponds to a particular range of terrain elevation. Table 3.8 is the
legend for the RTPP contour map.
59
Figure 3.3: RTPP alpha prototype display modes—natural and contour.
Table 3.8: Contour Map View Legend.
Level
Terrain Elevation (ft MSL)
Color
0
Larger than 10,000
Orange
1
Between 9,500 and 10,0000
Red
60
2
Light red
3
Light pink
4
Dark pink
5
Light purple
6
Dark purple
7
Light blue
8
Dark blue
9
Light cyan
10
Dark cyan
11
Light green
12
Dark green
13
Yellow
14
Yellow
15
White
16
White
17
Less than 2,000
White
The map on the left side of Figure 3.3 is an example of the default view for a newly
loaded terrain map. By default, the RTPP renders the entire terrain map to the GD object. Tasks
(3), (4), and (5) can be used to eliminate the ambiguities resulting from not knowing where the
terrain-map-partitions begin and end or the exact elevation value assigned to a map partition.
Task (3) displays a grid that identifies where terrain-map-partitions begin and end; Task (4) is
the zoom-in feature which varies the level of detail of terrain maps on the GD object. Task (5) is
the pan feature; it shifts the terrain map up, down, left, or right. Tasks (3), (4), and (5) simplify
the procedure of selecting the route’s start and destination locations. Figure 3.4 below shows
61
how Tasks (3), (4), and (5) from Table 3.7 were be used to vary the level of detail of the terrain
maps on the left side of Figure 3.3.
Figure 3.4: GD object zoom-in view of a terrain map.
Task (6) is to display the borders of the available airspace to the GD object. These
borders are provided as ordered locations within a file.
Task (7) allows an operator to select one of the pixels on the screen-world by clicking the
mouse on it. This pixel represents either the start or the destination location of the desired route.
The value that goes into the RTPP is a screen-coordinate and it gets converted to the DFCS ENU
real-world coordinates system by using Equations 3.1 and 3.2 below [Hil01].
sw = sxmax − sxmin + 1
where
62
(3.1)
sw
is the screen (or GD) width in pixels; and
sxmax
is the maximum x value on the screen (or GD) in pixels; and
sxmin
is the minimum x value on the screen (or GD) in pixels
sh = symax − symin + 1
(3.2)
where
sh
is the screen (or GD) width in pixels; and
symax
is the maximum y value on the screen (or GD) in pixels; and
symin
is the minimum y value on the screen (or GD) in pixels
Task (8) is to encapsulate and hide all the mathematical details associated with the
transformations between the screen-world and the ENU world since terrain maps are presented to
human operators in screen-world coordinates (which have units of pixels). The screen-world
coordinate system is a Cartesian coordinate system whose origin has values of zero, and its x and
y axes are perpendicular to each other. The GD object uses only two dimensions of this screenworld to display the x-y plane of the DFCS ENU coordinate system. The origin of the screenworld is at the GD object’s top left corner, as depicted on Illustration 3.2.
63
Illustration 3.2: Screen world (GD object) coordinate system.
Illustration 3.2 displays the locations of sxmin and symin (which make up the origin of the
screen-world). The x-axis flows out from this corner into the right direction, and the y-axis flows
down toward the bottom of the screen. Both of these axes have positive values only, and their
values are discrete with units of pixels; the separation between each value is 1 pixel. As evident,
this coordinate system has its limits at the end of the GD object. That is, using pixels as the units:
the maximum x-value is the GD object’s width less 1 pixel, and the maximum y-value is the GD
object’s height less 1 pixel. Table 3.9 below describes the screen-world’s coordinate system.
Table 3.9: Screen World (GD Object) Coordinate System.
Axis Name
Maximum Value on Axis
Maximum value on axis (Screen width -1, pixels) is the number of pixels on
+x
any row of the GD object minus 1 since the origin of the axis has a value of 0
64
pixels. The axis runs to the right and its values increment in intervals 1 pixel.
Maximum value on axis (Screen height -1, pixels) is the number of pixels on
any column of the GD object minus 1 since the origin of the axis has a value of
+y
0 pixels. The axis runs to the bottom of the screen and its values increment in
intervals 1 pixel.
Task (7) allows a particular pixel to be selected with the mouse and Task (8) converts the
pixel to ENU coordinates in ft; this value gets passed to Task (9) where it gets snapped to the
quantized value that it is closest to. That is, since terrain maps contain discrete locations, each
start location and destination location is set equal to the value that best approximates the input
value.
Task (10) is to view the A* path. A similarity between both maps is that they both render
the A* path buffer to the graphics display object as red line (which is sometimes straight and
other times jagged). Figure 3.3 shows an A* path on each of the map views as a red jagged line.
Notice that in Figure 3.3 it is easier to spot the mountains and the A* path on the natural view:
but that it is easier to spot the elevation levels and their borders on the corresponding contour
view.
Task (11) is to toggle the GD object between natural view and contour view. Task (12) is
to inhibit all graphics processing (e.g. use all processing toward generating routes).
3.2.3
Terrain Map File Processing Object
In the RTPP alpha prototype, the Terrain Map File Processing (TMFP) object extracts
data from the terrain map files. Metaphorically, this extracted data is the fuel that powers the
RTPP. In addition to performing this task, which is crucial to the successful operation, output
accuracy, and the flexibility of the RTPP, it also populates the other RTPP buffers. Specifically,
the TMFP object performs the following tasks. First, it opens terrain maps files and loads them to
the terrain elevation data buffer. Second, it opens boundaries files and loads the terrain
65
boundaries buffer. Third, it opens A* path files and loads them to the A* path buffer. Fourth, it
extracts data from terrain map files during the loading process. Fifth, upon user request, it saves
generated A* paths to files. The files for the three buffers explained above are in ASCII format;
an example of such a file can be seen on Figure 3.5. Although these files have similar formats,
their index values are processed differently. The tasks of the TMFP object are summarized in
Table 3.10 below, and the formats for the different objects are specified on Tables 3.8, 3.9, and
3.10.
Table 3.10: Terrain Map File Processing Object Tasks.
Task No.
Description
1
Load the terrain elevation data buffer.
2
Load the terrain boundaries buffer.
3
Load the A* path buffer.
Extract terrain map properties from the terrain map as it is loaded into its
4
buffer.
5
Save the A* path buffer.
Figure 3.5: Terrain map ASCII file in (i, x, y, h) format.
Table 3.11: Terrain Elevation Map File Format.
Name
Symbol
Description
66
A unique identifier assigned to each distinct location of the
Index
i
terrain elevation map.
Horizontal
x
The x coordinate in ft using the ENU coordinate system.
y
The y coordinate in ft using the ENU coordinate system.
Coordinate
Vertical Coordinate
Elevation
The MSL elevation coordinate in ft attached to each (x, y)
h
Coordinate
coordinate from the ENU coordinate system.
Table 3.12: Boundaries File Format.
Name
Symbol
Description
The index identifies the order in which the boundaries are to
Index
i
be set.; the boundary points must be arranged in the order
they are to be implemented.
Horizontal
x
y
Coordinate
Vertical
Coordinate
Elevation
h
coordinate from the ENU coordinate system. The RTPP
Coordinate
boundaries are restricted at present to elevation of h=0 ft.
Table 3.13: A* Path Format.
Name
Symbol
Index
i
Description
The unique identifier assigned to each distinct location of
the terrain elevation map. The records are arranged in order
67
that traces from the destination location to the start location.
Horizontal
x
y
Coordinate
Vertical
Coordinate
Elevation
h
Coordinate
coordinate from the ENU coordinate system.
Tasks (2), (3), and (5) on Table 3.10 are standard procedures when imposing constraints
or when acquiring data for analysis. These tasks are performed through the GUI object. The type
of file to be loaded, e.g. Tasks (2) and (3), or saved, e.g. Task (5), can be set on the GUI object’s
toolbar or menu (See Task 1 on Table 3.6). The GUI object activates a DB object when loading
or saving a file; the DB object for the latter case is the File Save As and for the former case is the
File Open, which is depicted in Figure 3.2.
Task (2) has two purposes: first, to make the available terrain that is beneath the provided
air-space visually identifiable to the human operator and second, to impose borders that specify
this air-space’s boundaries to the virtual UAV. Having a GUI that displays boundaries that
separate prohibited terrain from available terrain is useful for an operator who is selecting start
and destination locations. Additionally, if the airspace is constricted to a subset of the terrain
map, the virtual UAV must also be limited to touring only the virtual terrain within the
boundaries. Tasks (3) and (5) are for analyzing the results: for example, “An A* path is needed
for MATLAB™ analysis.” “Are the paths flyable?” “Do the paths have the tendency to put the
UAV in high risk situations?”…etc. Tasks (3) and (5) are interrelated—task (5) which is to save
a newly generated A* path must be performed before task (3) can be performed, which is to load
the RTPP with a previously generated A* paths.
68
Task (1) of Table 3.10 involves loading terrain map files to the RTPP; these files are
loaded in the same as the other files, with the GUI object. Aside from loading terrain maps, the
main purpose of Task (1) is to make the RTPP flexible. The following statement describes the
design that implements this flexibility:
Design 3.1
The RTPP must use terrain maps of different geographical locations. Also,
its terrain map’s properties can vary for different terrain maps. Each map’s area must be
allowed to have different dimensions and values. That is, the lengths and widths and
square footage can be distinct for each map. Hence, the RTPP must use maps with
different terrain map resolutions, m, and quantization values, q.
Notice how the TMFP object handles task (1) and (4) in Illustration 3.1. Observe that after the
terrain map is loaded and processed by the TMFP object, it extracts the terrain map’s properties.
These extracted map data flow from the TMFP object to the following three RTPP objects: GD,
ASA, and DA. The data extracted from the map is described in Table 3.14 below.
Table 3.14: Topographic Terrain Map Properties.
Name
Symbol
Quantization value
q
Description
The horizontal and vertical, but not diagonal,
distance between points of the input terrain map.
The total number of records (i.e. (i, x, y, h)
Resolution
m
coordinates) of the input terrain elevation file.
Minimum x ENU coordinate system value, in ft, of
Horizontal Minimum
xmin
the input terrain map.
Maximum x ENU coordinate system value, in ft, of
Horizontal Maximum
xmax
Minimum y ENU coordinate system value, in ft, of
Vertical Minimum
ymin
Maximum y ENU coordinate system value, in ft, of
Vertical Maximum
ymax
the terrain map.
69
Design 3.1 described above has made it possible to use terrain elevation maps of different
areas with different resolutions, m, and with different quantization values, q. These maps are
created with the TMC, which returns elevations from the NED dataset. This particular terrain
elevation data source has accuracy of 30 meters (approximately 98 ft), which means that nonredundant terrain elevation points are available in increments of 30 meter (or about 98 ft)
vertically and horizontally, but not diagonally. This available dataset is for the geographical area
located at WSMR center: -106.3339˚ longitude and 33.0834˚ latitude in geodetic coordinates.
The RTPP has been using maps that vary in dimension: as small as 1,000 ft by 1,000 ft and as
large as 50,000 ft by 500,000 ft with various quantization values and resolutions. Thus the RTPP
design to allow the use of terrain maps with different properties has been implemented correctly.
The details are provided on subsection 3.4.8, which describes the RTPP alpha prototype results.
The MFC CSerialize class for reading and writing files was overwritten to read in the
different types of files and to extract the terrain map properties. The default CSerialize base class
could not be used to do these tasks, which are described on Table 3.10. The reason is that is in its
default form, the CSerialize base class does not save data when the Save or Save As commands
are activated from the GUI objects menu or toolbar. For the GUI object’s File Open command,
no data is not loaded to the RTPP. Hence, the CSerialize base class was overwritten with the
class whose instances create TMFP objects. This class was created exclusively with standard
C++ using OOP techniques; this same class is used on the TMC—a benefit of using OOP.
3.2.4
A* Algorithm Object
The RTPP virtual environment is the interface between human operators and the A*
Algorithm (ASA) object11. The virtual environment is comprised of a virtual UAV and of a
virtual terrain—to the human operator the virtual environment is presented visually: to the ASA
object, it is presented computationally. The virtual UAV and virtual terrain were used to create
the states within the implicit state-space12 that the ASA object searches for solutions. The virtual
11
12
A* Algorithm Object and AI module are used interchangeably in this document.
All states within the state-space are solutions, thus A* searches for a state within a solution-space.
70
UAV is realized via control parameters13 entered by the RTPP operator on the GUI object. The
virtual terrain map is based on the ENU plane, which is partitioned with a configuration
recommended by Mitchell [Mit88]. Together, the ENU plane divided into squares, as indicated
by this partitioning scheme, create the computational representation of the virtual terrain.
The map partitioning scheme divides the ENU plane into discrete areas that are used to
identify the initial states of the route-finding problem. The initial states have the attribute that
two of the map partitions have been assigned; one as the initial location and the other as the final
location of the virtual UAV. The virtual UAV flight altitude and its minimum AGL restriction
are also part of the initial state description. For this problem’s state-space, initial states are
completely described if these four parameters have been assigned. This is not true for the goal
states. Goal states must also have a route between the virtual UAV initial and final position. In
the RTPP, initial states are generated and entered by human operators, but goal states are
generated by the ASA object.
The ASA object generates goal states by expanding nodes. In the RTPP, nodes can be
regarded as locations corresponding to terrain-map-partitions. In general, for nodes to be
expanded, they must have minimal distance between its corresponding map partition location
and the destination location. Also, the terrain elevation assigned to the associated map partition
must be less than the virtual UAV flight altitude. Additionally, the vertical distance between the
flight altitude and the terrain elevation must exceed the assigned minimum AGL. Moreover,
nodes can also be regarded as a partial or incomplete goal state. The ASA object commences
node expansions at the node assigned to the start location (from the initial state) and continues
expanding the nodes that represent the map partitions between the start location and the
destination location; halting this process before the goal state is generated results in a partial
route (or partial goal state).
The ASA object expands the most promising nodes first and places them at the top of the
OPEN list. This list is a prioritized list of nodes that are arranged according to the values
13
Control parameters are the virtual UAV properties that must be set for each desired route.
71
assigned to them by the evaluation function. The evaluation function does four things: it
computes the distance between the current node and the destination location, it determines if a
node is worth using for the route, it computes the cost from the start node to the current node,
and it assigns nodes a priority value for undergoing expansion. The evaluation function is a sum
of two other functions called heuristic and cost. In general, the heuristic function guides the
direction of the node expansions, and the cost function is used to effectively include or exclude a
node associated with a certain map partition from belonging to the goal state.
The heuristic function speeds up the goal state generation process by assigning lower
values to more promising nodes. The same is true for the cost function. It speeds up the goal
generation process by computing the cost from the start location to the current node (i.e. the node
associated with a current location or map partition within the terrain map). The nodes that are
assigned the lowest value by the evaluation function are expanded first. As each node is
expanded, it is removed from the OPEN list and placed on the CLOSED list. The closed list
identifies the nodes that have been expanded so that they will not be expanded again. This
process iterates until the goal state is created. The OPEN list is a stack (i.e. nodes at the top of
this list are used first); as new nodes are generated, those with the smaller values get placed at
the top of the OPEN list, and those with larger values go to the bottom of this stack.
In the RTPP, the two-dimensional Euclidean distance formula is used exclusively as the
heuristic function from which all heuristic information is obtained. The two-dimensional
Euclidean distances are computed between the destination location and the location associated
with each new node that is to be placed on the OPEN list for expansion. This process begins at
the initial state; the node assigned to the start location is expanded first. Once this node has been
expanded, the heuristic function is computed for each of the successors of this node, and the
successors are placed on the OPEN list. The node corresponding to the start location is placed on
the CLOSED list. At this point a node is selected from the OPEN list, whether it can be
expanded or not depends on its arc cost, which is assigned by the cost function. Assuming it is
expanded, the distances of the offspring are computed and placed on the OPEN list, …, the
72
process repeats iteratively until it is determined that the goal state has been obtained (or that such
a state does not exist).
To create these goal-states, the cost function is used to perform obstacle avoidance and to
increase the horizontal distance between the virtual UAV and certain terrain-map-partitions:
specifically, those that have equal MSL to the flight altitude of the virtual UAV. This safety
measures for the real-world UAV minimize collision risk associated with a real-world UAV
brushing the side or the peak of a mountain. The cost function depends on the four control
parameters of the virtual UAV to perform these tasks. It also depends on the map partition’s
terrain elevation values. The cost function gets the terrain elevation information for each map
partition by querying the Dynamic Array Object. The determination of whether a terrain-mappartition is an obstacle or not is made by comparing the virtual UAV flight altitude relative to the
terrain elevation. The question to answer is if the virtual UAV is above or below the terrain. To
implement obstacle avoidance, the cost function forbids processing of nodes that are regarded as
obstacles. Such nodes will have the following property: the terrain elevation assigned to the
associated map partition of the node is greater than or equal to the assigned virtual UAV flight
altitude. Nodes such as these, which represent obstacles, are shunned away from the OPEN list
by the cost function.
The arc costs within the search tree determine if the presence of virtual UAV is allowed
within map partitions. The method for assigning arc costs was suggested by Mitchell [Mit88] for
obstacle avoidance. In the RTPP, the arc cost returned from a particular node depends on the
virtual UAV flight altitude and on the minimum AGL. If the difference between the flight
altitude and the terrain elevation is less than the minimum AGL, arc cost of infinity is retuned,
otherwise unit arc cost is returned. Arc cost of infinity means that virtual UAV are not allowed in
the map partition, and unit arc cost means that the virtual UAV can use the map partition to
construct a goal state. In the RTPP, nodes with arc cost of infinity are not placed on the OPEN
list at all, even though theoretically they should be placed at the very bottom of the stack.
73
3.2.5
Dynamic Array Object
To force real-time performance, the ASA object references memory directly, which is
more beneficial to real-time performance that using sequential lookup. This speeds up the
generation of goal states. The direct memory reference was implemented by a C++ class. This
class contains a buffer and some features for querying and retrieving datum from it. An instance
of the class, called the Dynamic Array (DA) object is used by the ASA object to access memory
directly and to affirm that the intended memory is being retrieved. Affirming that the intended
memory is being referenced by the ASA object is implemented by comparing values computed
by the ASA object against values obtained from read-only files.
Direct reference is faster than sequential lookup when retrieving a particular datum
because the datum can be retrieved by using its memory address. Performing a sequential lookup
to retrieve a particular datum requires that the buffer be searched in a fixed order. Here, the
datum in each buffer location must then undergo Boolean comparisons until a set condition is
met; at this point, the datum is retrieved.
Because direct reference requires that the memory address of the desired datum be
known, the memory addresses of the DA object’s buffer were made to coincide one-to-one with
the DFCS ENU (x, y) coordinates. The ASA object always has access to the required buffer
address of the DA object. The ASA object computes the location, in DFCS ENU coordinates, of
the node it wishes to explore. It does this during the goal state generation process. Hence, the
ASA object, as was designed, uses these computed ENU (x, y) coordinates as the memory
addresses for directly referencing the terrain elevation buffer of the DA object.
The DA object is set up to fail if it is not indexed correctly by the and the ASA object
because this means that an error has occurred: possibly with the terrain map that was loaded or
with the computations performed by the ASA object of the quantized ENU coordinates.
The ASA object performs error-checking by making Boolean comparisons between
computed data and read-only data. The map index, i, that is assigned to each map partition as a
unique identifier is also computed by the A* algorithm Object so that the values can be
74
compared to ensure that the correct map partition is being used. Before the ASA object uses the
terrain elevation value, h, it compares the computed index, i, against index that was read in when
the file was loaded. This sets up an error diagnostic system that causes the system to fail in the
event of a program error resulting from a corrupted file or a data offset, or some other coding
bug.
3.3
TERRAIN MAP CREATOR
The TMC generates two-dimensional maps that represent a surface of the three-
dimensional earth. These maps are in DFCS Earth-North-Up (ENU) coordinates. This coordinate
system uses a flat plane that is tangent to the surface of the earth at WSMR center. Soto et al.
[Sot07] provide the following definition for this ENU world:
“The East North and Up (ENU) coordinate system is used at DFCS. The coordinates can
be represented as (x, y, z, h). z is defined with respect to an imaginary flat plane that is
tangent to the earth surface at the WSMR center, which is the origin of the DFCS ENU
coordinate system. h is the MSL elevation (or altitude); it takes into account the curvature
of the earth, which makes it very useful for measuring UAV AGL. The (x, y, z, h) = (0 ft,
0 ft, 0 ft, 0 ft) origin in the ENU coordinate system is at 33.0834 degrees North and
106.3339 degrees West. This point is 72.4112 ft MSL above the WGS 84 reference
ellipsoid.”
The DFCS ENU coordinate system is Cartesian; the units of each of its axes are in ft and its
values are evenly spaced. Three axes perpendicular to each other and with positive values flow
out from the origin: the first to the East, the second to the North, and the third Up: hence the
acronym ENU. The corresponding axes with negative values also flow out form the origin, but
they flow West, South, and Down. The z = 0 plane of the ENU world that is created by the TMC,
is neither continuous nor infinite: the (x, y) coordinates are separated by a quantization value q
vertically and horizontally, and by
2 q diagonally, also, the x and y axes have minimum and
maximum x and y values. Table 3.15 below summarizes these properties. Illustration 3.3 depicts
the DFCS ENU plane (z = 0); for clarity it is lifted up and to the left form its geographical
location on earth.
Table 3.15: DFCS ENU Coordinate System.
75
Axis name
Axis alias
Description
Maximum value on axis (xmax ft) depends on the data of the
East
+x
TMC file. The value at the origin is 0 ft and values increment
to the East in intervals of the quantization value.
Minimum value on axis (xmin ft) depends on the data of the
West
-x
TMC file. The value at the origin is 0 ft and values decrement
to the West in intervals of the quantization value.
Maximum value on axis (ymax ft) depends on the data of the
North
+y
TMC file. The value at the origin is 0 ft and values increment
to the North in intervals of the quantization value.
Minimum value on axis (ymin ft) depends on the data of the
South
-y
TMC file. The value at the origin is 0 ft and values decrement
to the South in intervals of the quantization value.
Elevation value in MSL assigned to a DFCS ENU coordinate.
Up
h
The maximum elevation at WSMR is approximately 10,000 ft
MSL and the minimum is approximately 3,500 ft MSL.
Negative MSL values indicate elevations below mean sea
Down
-h
level, e.g. valleys, under-water, and under ground.
Up
z
Value above the horizontal ENU plane.
Down
-z
Value below the horizontal ENU plane.
76
Illustration 3.3: DFCS ENU coordinate system.
3.3.1
TMC Modules
Illustration 3.4 below shows the software architectural diagram of the Terrain Map
Creator; these modules perform the meticulous geographic conversions that yield files containing
the precise transformation of the surface of the earth onto a topographic map in DFCS ENU
coordinates. The blocks represent the modules (or objects) and the arrows indicate the passing of
data between the modules. The modules, some of which are C++ objects, are listed on Table 3.16
below.
77
Illustration 3.4: TMC Architecture diagram.
Table 3.16: TMC Modules.
No.
Object/Module
Acronym
1
GUI
2
Dialog Box
DB
3
Terrain Map File Processing
TMFP
4
Geographic Conversions
GC
5
NED Query
NQ
Terrain map files are the output of the (NQ) module. Its input is the file containing the
ENU z = 0 partitioned plane. This input file, which is the output of the Terrain Map File
78
Processing (TMFP) module, contains the quantized (x, y, z) coordinates and each of these (x, y, z)
ENU coordinate is used as the center of the area where the search for the highest peak is
performed. The NQ module passes each of these coordinates, one at a time, to the Graphics
Conversion (GC) object, so that they can be converted to geodetic latitudes and longitudes. Then
the NQ module uses the resulting latitudes and longitudes to query the NED dataset.
3.3.2
GUI Object
The TMC contains a Windows XP graphical user interface (GUI); it is shown at top of
Figure 3.6. This GUI is very simple and intuitive. It contains a menu that is used to activate its
two Dialog Box (DB) objects: the first is for partitioning the z = 0 plane into equal sized square
partitions, the second is for assigning an elevation value to each of these partitions. The DB
object at the center of Figure 3.6 is for performing the former task; it provides fields so that a
user can enter the quantization value, q, the x and y minimum and maximum values in ENU
coordinates, and the file name. These x and y values represent xmin, ymin, xmax, and ymax which are
defined on Illustration 3.3 and used as the minimums and maximum for the DFCS ENU
coordinate system that is described on Table 3.15. The quantization value q is entered into the
section titled Step Distance, which contains a single field labeled Step14; this value is the
horizontal (and vertical) separation distance between the centers of each map partition. The other
DB object performs the latter task, which is to assign a Mean Sea Level (MSL) elevation to each
of the partitions on the z = 0 plane; these values are saved as (x, y, h) ENU coordinates to a file.
This DB object is displayed at the bottom of Figure 3.6; it provides two fields: one for stipulating
what type of numerical value to use for writing the terrain map file and the other for providing
the file name of the resulting RTPP terrain map.
14“Step”
is simply an alias for the quantization value, q.
79
Figure 3.6: TMC GUI and dialog boxes.
3.3.3
Terrain Map File Processing Object
The values—quantization, q, and the x and y minimums and maximums—entered via the
GUI are initially passed to the Terrain Map File Processing (TMFP) object, whose RTPP tasks
were described on the RTPP alpha prototype section. In the TMC, this object uses a “simple yet
non-trivial” terrain partitioning scheme suggested by Mitchell [Mit88] for generating terrain
80
maps that are searchable by state-space search methods, where in this study is the A* algorithm.
The scheme, which Mitchell calls a “binary-partitioning” divides the geographical area and
assigns the partition as either traversable terrain or obstacle. The TMFP object partitions the z =
0 plane into rectangular areas whose length and width are equal, thus resulting in square
partitions, which are used exclusively for this study.
The TMFP object uses xmin, ymin, xmax, and ymax to determine the initial and final
coordinates and all the intermediate coordinates in between. It creates these values by recording
the bottom left coordinate, which is (xmin, ymin) for the map, and then incrementing the x
coordinate by the quantization value, q, until xmax is reached. At this point, the y coordinate is
incremented by the quantization value, q. This partitioning of the z = 0 plane terminates when the
maximum y coordinate ymax is reached. Hence, the quantization value, q, determines the
horizontal and vertical length of the map partitions.
The minimum and maximum x and y values must be computed such that incrementing q
will eventually lead to an x and y value directly on the x axis and on the y axis, respectively. If
this occurs, this means that one of the ENU coordinates generated must be the origin to the
coordinate system. In the case of DFCS, the origin is (x, y, z) = (0 ft, 0 ft, 0 ft), therefore values
xmin, ymin, xmax, and ymax are rounded down or up such that the incrementing q will eventually
produce a ENU coordinate whose value is (0 ft, 0 ft). By default, the value of z is zero since it is
the z = 0 ft plane that is being partitioned.
Each of these map partitions is assigned an index whose count begins at (xmin, ymin),
which is the first ENU coordinate written to the RTPP terrain map. A value of 1 is assigned as
the index to this terrain-map-partition, which is on the lower left of the terrain map. Then, the
following partitions to the right are assigned indexes whose values increment by 1 until the last
partition on the row is reached. At this point, the indexing continues on the next row up, at the
partition to the left, for all the remaining rows.
81
3.3.4
Geographic Conversions Object
The Geographic Conversions (GC) object uses the World Geodetic System 1984
(WGS84)15 [NIM07] reference ellipsoid to perform the translations between the different
representations of earth’s surface. The results from the first and last TMC translations of the
earth are topocentric; that is, the resulting maps are represented on a two-dimensional flat
surface. The first topocentric translation is from the z = 0 partitioned plane; the last topocentric
translation is to the RTPP terrain map. The latter is the precursor to the former. First, the GC
object processes the z = 0 plane by translating its topographic coordinates to Earth Centered
Earth Fixed (ECEF)—i.e. geocentric16—coordinates [Nav98]. Second, the geocentric coordinates
are converted to geodetic coordinates. Last, the NED Query module uses the geodetic
coordinates to produce the RTPP topographic maps. Hence, the GC object is charged with
accurately performing all intermediary translations to convert the ENU based z-plane at z = 0 to
the geodetic coordinates based on the WGS84 reference ellipsoid.
The GC object begins by transforming the initial topocentric Cartesian coordinates to
geocentric ECEF Cartesian coordinates. Both DFCS ENU and ECEF are Cartesian17 coordinate
systems, but their coordinates are used differently to signify earth’s attributes. The DFCS ENU x
and y coordinates are analogous to longitude and latitude, respectively, and the z = 0 ENU plane
does not account for curvature of the earth. On the DFCS ENU coordinate system, z values
signify the value above of or below the z = 0 plane. Curvature of the earth error increases as the
x-y distance increases from the DFCS ENU coordinate system’s origin. Hence, the only one zvalue that can be used as an accurate MSL elevation is the ENU origin—where the plane is
tangent to the surface of the earth.
The ECEF coordinate system, as used by the TMC, implements the WGS84 ellipsoid in
Cartesian (X, Y, Z) coordinates. In ECEF coordinates, (X, Y) ordered pairs are analogous to a
longitudinal values on earth and Z coordinates, to latitudinal values. X-Y planes at different Z
15WGS84
(World Geodetic Survey 1984) is the U.S. standard model of the earth.
coordinates are also referred to as Earth Centered Earth Fixed Coordinates.
17Cartesian coordinates signify distance from the origin.
16Geocentric
82
values are parallel to the equator. The prime meridian is perpendicular to the Z axis at two points:
the North and South Poles. The WGS84 ellipsoid representation could be conceptualized as
spinning about the Z axis of the ECEF coordinate system. The origin of the ECEF coordinate
system is (X, Y, Z) = (0 ft, 0 ft, 0 ft); it is analogous to the center of the earth (i.e. to the earth’s
core). The WGS84 ECEF coordinate system assumes the earth is a perfect ellipsoid. It does not
account for mountains or craters on earth’s surface.
Reiterating, the conversions from DFCS ENU topocentric coordinates to geocentric
(ECEF) coordinates are based on the WGS84 ellipsoid. The reference point of the ellipsoid is
(longitude, latitude) = (-106.3339˚, 33.0834˚). The WGS84 ellipsoid is 72.4112 ft above the
MSL elevation at this location. These values are used to adjust the offset of the ellipsoid so that it
is in sync with the corresponding location on earth at the reference point. This overlapping of the
WGS84 model with the earth at the specified reference point produces (longitude, latitude)
values with minimal error for the locations of interest on the earth, which are on the WSMR
terrain. Illustration 3.5 below shows the relationship between the WGS84 ellipsoid and the X-YZ axes of the ECEF coordinate system.
83
Illustration 3.5: WGS84 ellipsoid on ECEF coordinate system.
Next, the GC object transforms the geocentric coordinates to geodetic coordinates.
Illustration 3.6 below shows the relationship between the geocentric coordinate system and the
prime meridian; Illustration 3.7 shows the relationship between the geocentric coordinate system
and the equator. The prime meridian is the horizontal reference line of the geodetic coordinate
system; the equator is the vertical reference line. The geodetic coordinate system18 identifies
angles from the prime meridian as longitudinal lines and angles from the equator as latitudinal
lines; these angles use units of degrees. Illustration 3.6 below shows that the angles associated
18
In a flat map longitudinal lines and latitudinal lines can be seen as displacements from the prime meridian and the
equator, respectively.
84
with longitudinal line are with respect to the prime meridian, which is at longitude = 0°. Notice
that the angle between the prime meridian and the ECEF positive Y-axis is longitude = 90° and
that the angle between the prime meridian and the ECEF negative y-axis is longitude = -90°.
Illustration 3.7 below shows that the angles associated with latitudinal lines are with respect to
the equator, which is at latitude = 0°. Observe that the angles above the equator are positive and
those below the equator are negative. Furthermore, the transformation from the geocentric to
geodetic coordinate system is also based on the WGS84 ellipsoid. This final geographic
conversion since it yields the necessary geodetic longitudes and latitudes that are mapped to a
particular location at earth’s surface.
Illustration 3.6: Geodetic longitudinal lines relative to ECEF X-Y axes.
85
Illustration 3.7: Geodetic latitudinal lines relative to ECEF Y-Z axes.
3.3.5
NED Query Module
The National Elevation Dataset (NED) Query module takes two inputs: (1) geodetic
coordinates produced by the GC object; (2) digital terrain elevation data. The terrain elevation is
obtained from the NED dataset which selects the highest elevation point within 30 meters
[USG07] and that has an elevation accuracy of 1 meter. Hence this module returns an MSL
elevation he when queried with geodetic coordinates.
The NQ module was designed to be queried with a minimum value of 98 ft and all values
greater than 98 ft up to values that are several orders of magnitude (for instance, q = 98,000 ft)—
86
the maximum quantization value for querying the NED dataset depends on the terrain image.
The minimum value is based on the NED dataset resolution of 30 meters which is approximately
equal to 98 ft (98 ft ≅ 30 m) 19; querying the NQ module at a smaller value is redundant since the
same elevation value will be returned for locations that lie within the same 98 ft block.
The NQ module searches for the highest peak within each terrain-map-partition by setting
a buffer that is used for storing the first elevation value and the value in the buffer gets updated
each time a higher elevation value is obtained from within the map partition of size q where the
search for the highest peak is being performed. All map partitions of size q are searched in
horizontal increments of 98 ft and when the horizontal limit is reached, the search is incremented
98 ft vertically and the process continues. When this procedure completes, the buffer contains the
highest peak found within the map partition’s area. This value is assigned as the elevation to the
terrain-map-partition that is represented as an ENU coordinate in the file that was read in by the
NQ module. This means that the map partition could be assigned an elevation that is higher than
the one at the geographical location which it represents. However, this is the goal: to trade map
accuracy for safety. If this procedure is not performed for terrain maps, UAV safety is not
guaranteed for the entire map partition of dimensions q ft by q ft; it is only guaranteed at the
center of the map partition. But since the highest peak within the map partition is assigned, the
UAV is guaranteed not to collide with a mountain when entering or exiting the terrain-mappartition. Hence assigning the highest peak to each partition guarantees the safety of the UAV
not only at the center of the map partition but also for the entire map partition of dimensions q ft
by q ft.
3.3.6
Quantized Terrain Maps
The terrain maps produced by the Terrain Map Creator (TMC), as used by the RTPP, are
analogous to United States maps. Both maps are partitioned into contiguous areas and the
partitioned areas are each assigned a symbol in each of the maps that represents them uniquely.
19This
value is repeatedly used in this study because it is in units of ft and it is approximately equal 30 m which is
the actual resolution of the NED dataset.
87
For example, the unique symbol assigned to a state in the U.S. map is the name (e.g., Texas)
while the unique symbol assigned to each RTPP map partition is a positive integer called the
index. Both maps have an outline that borders their areas and the individual partitions within
their areas. However, the geometry of RTPP terrain maps and that of its partitions is simple when
compared to those of the U.S. The outlines of the U.S. area and that of each of its states are
distinct and complex (i.e. they all have different and intricate shapes and sizes) whereas the
outlines of a RTPP terrain map and the partitions within are rectangular and square, respectively.
3.4
RTPP-DFCS INTEGRATION ISSUES
The technical semantics associated with integrating the RTPP into DFCS are as follows:
•
The RTPP must provide DFCS with flight profiles that are maneuverable by
airborne aircrafts. DFCS will provide the characteristics of the desired flight
profile to the RTPP and the RTPP will use these properties to generate safe and
maneuverable flight profiles in real-time.
•
To allow DFCS to query the RTPP, a computer network communication link
between the RTPP and the DFCS real-time computer network will be established.
The purpose is two-fold: (1) to send flight profile request from the DFCS realtime computer network to the RTPP; (2) to have the RTPP acquire the DFCS
flight profile from the DFCS real-time computer network requests and then
respond by sending the requested flight profile into the DFCS real-time computer
network.
•
DFCS must display the RTPP flight profiles on the DFCS Console Subsystems.
•
The RTPP must provide flight profiles that the DFCS Guidance, Navigation, and
Control (GNC) system can utilize to automatically guide, navigate, and control
aerial vehicles. At worst, DFCS must require only minor modifications to be able
to use the RTPP generated flight-profiles.
Once these issues are precisely defined and implemented, the RTPP will be considered as
integrated into the DFCS real-time computer network.
88
3.4.1
Flight Profiles
Flight profiles must possess certain properties if they are to become routes that are
maneuverable by aircrafts. This section describes such properties.
3.4.1.1 Flight Profile Measures
The flight-profiles in this study guide a UAV flying over know terrain with elevations he
at a constant flight altitude ha from a user specified start location (xi, yi) to a user specified
destination location (xf, yf). The flight-profiles maintain a minimum separation between the
flight-profile and the terrain underneath; this reference value is called the minimum AboveGround-Level AGLm distance. A measure of the actual distance between the ground and a flightprofile (or between an airborne UAV and a flight profile) can be obtained by computing the AGL
with Equation 3.3 below.
AGL = ha − he
(3.3)
where
AGL is the above-ground-level distance in ft; and
ha is the flight altitude in ft MSL; and
he is the terrain elevation in feet MSL; and
AGLm is a reference value that specifies minimum above-ground-level distance
in ft.
The dynamic UAV direction is referred to as the heading ψ of the UAV; the heading is
referenced to the earth’s North and South poles. There are two types of headings: magnetic and
true. They are linearly related to each other and they differ only by an offset (i.e. an additive
constant). This offset changes at different geographical locations of earth. Equation 3.4 below
defines the relationship between the magnetic heading ψm, the true heading ψ, and their offset as
it occurs at WSMR, NM.
ψ m = ψ − offset
89
(3.4)
where
ψm is the magnetic heading in degrees; and
ψ
is the true heading in degrees; and
offset = 11.25˚ at WSMR, NM.
The true heading ψ and the magnetic heading ψm describe the direction of the velocity
vector with values that range between 0˚ and 359˚. The reference values assigned to the
directions of the true headings ψ are as follows: North is at 0˚; East is at 90˚; South is at 180˚;
West is at 270˚. All the heading computations in this study were done using the true heading ψ to
identify the velocity vector at a precise location. For instance, a UAV at location x = 0 ft, y = 0 ft
that is flying due East at time t can be described by a point-vector as follows: 〈 (x, y), R ψ 〉 = 〈 (0
ft, 0 ft), R 90˚ 〉. All direction and heading references in this study use true headings ψ with units
of degrees.
The maximum estimated ground speed vg,max for each distinct flight profile is used to
compute the maximum turn radius rt,max that is required by the UAV to make the turns on the
flight profile. The turn radius rt,max defines the amount of space required for the UAV to change
from an initial heading ψi to a terminal heading ψf. All turn radius computations in this study
assume a vertical acceleration of av = 1 G = 32.2 ft/s2; this assumption is valid for UAV that are
flying at a constant flight altitude. The maximum roll angle used in this study is 60˚. The UAV
turn radius rt is proportional to the ground speed vg of the airborne UAV and inversely
proportional to the vertical acceleration av. Equation 3.5 below defines the turn radius.
rt =
vg2
tan(ϕ )av
where
rt
is the turn radius in ft; and
vg is the ground speed in ft/s; and
av
is the vertical acceleration in ft/s2; and
90
(3.5)
φ is the bank angle20 in degrees.
3.4.1.1 Types of Flight Profiles
Two types of flight profiles are considered in this study; they are waypoints and flightpatterns. Waypoints are locations must be met in a specified order during the flight. Waypoints
have the property that they can be over or under shot intentionally (i.e. by design) or as
unintentionally. One example of a UAV guidance systems using waypoints guidance is as
follows: an ordered set of points is provided for the UAV to follow; the UAV guidance system
has the option to skip a waypoint by undershooting it or by overshooting it after it has
approached the waypoint. The decision to undershoot, overshoot, or meet the waypoint depends
on the location of the next waypoint. For instance, if UAV using waypoints guidance is trying to
meet a certain waypoint, it can begin to turn toward the next waypoint prior to arriving at the
current waypoint.
The DFCS guidance system uses preplanned flight trajectories for providing UAV
guidance. These preplanned flight trajectories are referred to as flight-patterns by the DFCS
personnel. Flight-patterns provide very little freedom as to what flight trajectory a UAV can
create since UAV must stay on flight-patterns for the specified duration of the flight. The
perpendicular distance between the flight-pattern and the airborne UAV is referred to as the
Cross-Track Error (CTE); the altitude distance between the flight-pattern and the airborne UAV
is referred to as the Altitude Error (ALE).
Because UAV flight-patterns can be defined and generated a-priori to the flight, they can
provide more accuracy than waypoints; however, this is obtained as the cost of flexibility. The
flight-trajectory of a UAV using waypoints guidance is not known a-priory since the UAV
controller (be it machine or man) can choose to overshoot, undershoot, or meet the waypoint in
real-time. Depending on the situation, this could be good or bad.
20
The bank angle is also known as the roll angle. It is 0˚ when the wings of an aircraft are perpendicular to the
flight velocity vector.
91
3.4.2
Waypoints
The original output of the flight trajectory generation program was to be flight-patterns,
but this specification was changed to waypoints during project development (i.e., Task 8 on
Table 3.1 was modified). This change in output specifications was allowed because waypoints
appeared to have more benefits than did flight-patterns. First, waypoints seemed to allow more
freedom than flight-patterns, and, as a result, it seemed that more combinations of flight
trajectories could be obtained from the given geographical area. Second, waypoints seemed a
more natural output for generating flight trajectories on a geographical area that is partitioned
into squares. Third, the lists that comprise A* paths are very similar, if not identical, to
waypoints lists [Osb05] in that both lists contain an ordered set of locations. These ideas led to
the conclusion that if an obstacle free path was found, only minor post processing of the A* path
would be required since the precursor of the desired flight trajectory had been obtained—it being
the A* path.
3.4.3
Processing the A* Path to Waypoints
The RTPP pre-processed output is a set of ENU coordinates; these coordinates represent
and link the series of grid location that comprise an A* path. Before real-world UAV guidance
can be attained from this output, post-processing is required. The preliminary post-processing
effort began by attempting to convert the A* path to a valid flight guidance solution. The method
uses all the points of the A* path and minimizes the distance between these points to a minimum
value equal to the NED dataset resolution21. Minimal separation distance between the A* path’s
points is sought in order to create a spline22 that approximates continuity.
To implement this post-processing methodology, high resolution terrain maps were used.
The first high resolution terrain map that was used had a quantization value of 98 ft (which is
approximately 30 meters—the maximum resolution provided by the NED dataset). However,
21 The word resolution has two meanings in this report. The NED resolution refers to the physical separation
between distinct data points on the elevation image. It is very similar to the quantization value, q, on terrain maps.
The terrain map resolution refers to the number of (x, y, h) coordinates within the file; its symbol in this report is m.
22 A spline is a continuous curve made up of series of distinct curved segments.
92
this terrain map was not useful because it used too much memory. This side-effect showed that
maps that consume that large amount of memory are impractical because they slow down the
RTPP. The response times for the loading the terrain map files and for generating paths were
affected. Loading the terrain map files took approximately 5 seconds and route generation could
take as much as 3 seconds. Therefore, the attempt at constructing waypoints from a 50 mile by
100 mile terrain map whose points are separated by as little as 98 ft was omitted.
3.4.4
Bounding the RTPP Input to Guarantee Real-time Response
The processing time for generating an obstacle free path in the high resolution terrain
map (with a quantization value of q = 98 ft that covers an area of 50 miles by 100 miles)
exceeded the real-time threshold. Additionally, the computer’s 2GB of RAM memory was used.
To alleviate these anticipated shortcomings, while not sacrificing the real-time response of the
RTPP, the idea of generating a spline from locations that are separated by minimal distance was
abandoned. The new output is waypoints that are separated by the smallest quantization value
that can be in used in a terrain map that spans 50 miles by 100 miles without diminishing realtime performance. To find this quantization value, terrain maps were generated and tested
iteratively until a terrain map file whose size does not take too much memory was obtained. The
smallest terrain map that covers a geographical area of approximately 50 miles by 100 miles but
that dose not diminish real-time response was obtained by sampling the elevation dataset at
approximately 5 times the NED resolution (i.e. 490 ft). This larger quantization value (q = 490
ft) generates a terrain map with a smaller resolutions (m = 577,915) which results in a terrain
map file which uses less memory.
This terrain map with resolution m = 577,915 locations in ENU coordinates was used to
perform empirical testing on the RTPP; the purpose was to gauge the real-time response. With
this terrain map file, the RTPP demonstrated real-time response by returning complicated23 A*
paths in less than 1 second while not exhausting the computer’s memory. This means that the
23
Complicated path means that the corresponding ordered list has at least 1,000 coordinates, and that the general
direction of the path is continually changing.
93
shortcomings associated with the A* algorithms and the computer’s resources while processing
the A* path into waypoints can be alleviated by bounding the terrain map resolution and filesize. The terrain map with resolution m = 577,915 is defined as the baseline for creating terrain
map files since it is the largest file that was used that did not degrade the RTPP real-time
response; its properties are shown on Table 3.17.
Table 3.17: Terrain Map Baseline.
Quantity
Symbol
File Size
Value
42,221 KB
Quantization Value
q
490 ft
Resolution
m
577,915 (x, y, h) coordinates
East Axis maximum value
xmax
127,890 ft
West Axis maximum value
xmin
-127,890 ft
North Axis maximum value
ymax
270,480 ft
South Axis maximum value
ymin
-270,480 ft
Figure 3.7 below shows a complicated A* path that was generated during the RTPP
empirical testing for real-time response. This route was generated by the RTPP in less than 1
second. This A* path is an example of a worst-case-scenario solution in two ways: (1) it uses the
largest allowed terrain map file (described on Table 3.17); (2) it is far more complicated than any
flight-pattern in current use. To generate this A* path, the RTPP used a little less than 25 % of
the computer’s memory (approximately 497 MB, The 25 % is for the computer whose platform
is specified on Table 3.4). This example establishes that the computer’s resources are stable and
that the RTPP responds in real-time.
94
Figure 3.7: Complicated A* path.
95
3.4.5
Problems Associated with Waypoints
Using high-resolution terrain maps (such as the one described on Table 3.17) to generate
waypoints from A* paths that have minimal separation between points proved to be very
problematic. The problem is that only the most trivial routes (i.e. routes with no change in
direction) could be used for valid flight guidance. The problem is that the waypoints that are
generated from these terrain maps do not account for the turn radius of an airborne UAV. Hence
the majority of these A* routes could not be processed into maneuverable UAV flight
trajectories.
3.4.5.1 Turn Radius vs. Terrain Map Quantization Value
The terrain map quantization value q determines the size of the individual line segments
in the A* route that is being used to generate the waypoints: (1) vertically or horizontally, the
minimum line segment distance is q ft; (2) diagonally, the minimum line segment distance is
2 q ft. This means that there will be occasions when waypoints that change the flight direction
of the UAV are separated by q ft. Figure 3.8 shows a zoomed-in view of the path on Figure 3.7
which was generated by using the terrain map described on Table 3.17. In this map, q = 490 ft
and 2 q = 693 ft.
96
Figure 3.8: Generating Waypoints from an A* path.
Figure 3.8 shows an A* path that has several line segments whose distances are 490 ft or
693 ft. This A* path will generate successive waypoints that are scattered in either the x or the y
coordinates. Therefore, the resulting UAV guidance solution will eminently contain successive
waypoints that are separated by either 490 ft or 693 ft and that recommend successive changes to
the UAV true heading ψ. Limiting the UAV properties (e.g. ground speed vg, roll angle φ) to
conform to the limitations imposed by the terrain map quantization value q = 490 ft is not an
engineering solution. Nonetheless, the vertical acceleration av, ground speed vg, and bank angle φ
can be set to minimize the turn radius in order to show that this solution is fallacious; the
minimum attainable turn radius can be computed by using the maximum values allowed in this
97
study for vertical acceleration av and for roll angle φ, and by using an unusually low ground
speed vg that barely keeps the UAV airborne.
The minimum attainable turn radius rt can be computed by considering a UAV that is
limited to using the following flight restrictions: (1) vertical acceleration av = 32.2 ft/s2, (2) bank
angle φ = 60˚, and (3) ground speed vg = 400 ft/s—the turn radius computed from these values is
rt = 2,869 ft! This means that waypoints that can have minimum separation of 490 ft are being
used to guide a UAV that has a minimum turn radius of 2,869 ft. Hence the minimum turn radius
required to change directions is almost six times larger than the minimum separation of the
proposed waypoints. The most likely outcome for a UAV that is flying at these parameters while
being guided by these waypoints is that the UAV will have good guidance when the waypoints
do not force a change in heading ψ. However, when the UAV encounters the first waypoint that
dictates a change in heading ψ, the UAV will meet it but it will surely overshoot the following
waypoints. In the best-case scenario, the number of waypoints that are overshot is six and if the
UAV does not recover to the waypoints list on the seventh waypoint, the flight dynamics will
cause the UAV get lost while trying to recover to the waypoints list—and this is the best-case
scenario.
Therefore, the effort of generating waypoint lists where the minimum separation between
the waypoints is smaller than the UAV turn radius has been terminated and replaced with a new
effort. The new effort uses terrain maps that have a quantization value q that is equal to or
greater than the maximum turn radius rt; this turn radius rt is computed by using the expected
maximum ground speed vg. This effort yielded a valid waypoints guidance solution from the A*
path. The waypoints lists that are generated are a subset of the A* path. The waypoints list does
not use points from the A* path that do not cause a change in heading ψ; it only uses the
following points: the first point, all the intermediate points that cause a change in heading ψ, and
the last point.
Task 8 of Table 3.1 which is the original specification of having flight-patterns as the
output was re-introduced because of the uncertainty and risk associated with waypoints as they
98
would be used in this study. For example, one criterion that establishes if the RTPP performs as
expected is if it can guide a UAV between two mountain peaks whose terrain elevation values he
are larger than the UAV flight altitude ha. Moreover, aside from the risk they add, they restrict
autonomy in that an operator will be required to make the judgment calls when the UAV is
flying at these low flight altitudes where the terrain has obstacles.
3.4.6
RTPP-DFCS Interface
The interface between the RTPP and DFCS is the DFCS Console Subsystem (DCS). The
RTPP is to be linked to the DFCS real-time computer network so that it can provide flightpatterns in response to flight profile requests that are specified and sent to the RTPP from the
DFCS console subsystem. The RTPP commands for requesting flight-patterns are to be entered
via the keyboard at the DFCS console subsystem and the RTPP is to return the requested flight
profile through the network to the CCS computer. Then the flight-patterns are to be loaded to the
DFCS guidance system from the console subsystem. Tables 18 to 23 define the DFCS consoles
subsystem keyboard commands and their parameters which are to be executed from the DFCS
consoles subsystem to query the RTPP for flight-patterns.
The HOST ASTAR command is used for setting up the IP address of the RTPP computer.
It specifies to the DFCS real-time computer network where to send the flight-pattern requests.
Table 3.18: Specify RTPP IP Address.
Keyboard Command
Command Arguments
HOST ASTAR
RTPP Computer IP address
The ENA ASTAR command enables UDP protocol network communication between the
RTPP and DFCS. The flight-pattern is request is sent as a UDP packet to the RTPP and the
RTPP responds with a UDP packet containing a flight-pattern.
Table 3.19: Enable Network Communication.
99
Keyboard Command
Command Arguments
ENA ASTAR
none
The PATH ASTAR command is used for requesting a flight-pattern from the RTPP with
the DFCS console subsystem. This command can be used off-line or in real-time. The operator at
the DFCS console subsystem can specify the following flight-pattern attributes: (1) the drone
index di; (2) the route’s initial location (xi, yi) in DFCS ENU coordinates; (3) the route’s initial
true heading ψi; (4) the flight-pattern’s altitude ha in ft MSL; (5) the route’s destination location
(xf, yf) in DFCS ENU coordinates; (6) the flight-pattern final true heading ψf; (7) the minimum
above-ground-level distance AGLm for the entire flight-pattern; (8) the UAV maximum ground
speed vg.
Table 3.20: Request Flight-pattern Between two locations.
Keyboard Command
Command Arguments
di
xi
yi
ψi
ha
PATH ASTAR
xf
yf
ψf
AGLm
vg
The ADD ASTAR command is entered from the DFCS console subsystem; it requests a
flight-pattern from the current UAV location to a user specified destination location. The routes
100
initial location, the flight-pattern’s MSL altitude, and the route’s initial heading are obtained
from the DFCS GNC system; the values are equal to the position, altitude, and heading of the
UAV at the time the command is entered. The user-specified flight-pattern command arguments
are as follows: (1) the drone index di; (2) the route’s destination location (xf, yf) in DFCS ENU
coordinates; (3) the flight-pattern termination heading ψf; (4) the minimum flight-pattern aboveground-level distance AGLm; (5) the maximum UAV ground speed vg. This is a real-time
command, i.e., the UAV can be airborne when the command is entered.
Table 3.21: Request Flight-pattern for Airborne UAV.
Keyboard Command
Command Arguments
di
xf
yf
ADD ASTAR
ψf
AGLm
vg
The SEG ASTAR command specifies that guidance is required form the current UAV
location to the start of an existing flight pattern’s first segment. The flight-pattern’s MSL
altitude, its start location and heading are equal to the UAV altitude, position, and heading at the
time the command is entered at the DFCS console subsystem. The destination location, which is
the first segment of an existing flight-pattern, is the set of user specified attributes that are passed
as arguments to the command. The attributes are as follows: (1) the drone index di; (2) the
segment index si; (3) the minimum flight-pattern above-ground-level distance AGLm allowed for
the pattern; (4) the maximum UAV ground speed vg. The flight-pattern’s terminal heading is the
heading of the connecting flight-pattern’s start segment. This is a real-time command which
means that the drone can be airborne when the command is entered.
101
Table 3.22: Request Flight-pattern for Airborne UAV and Existing Flight-pattern.
Keyboard Command
Command Arguments
di
si
SEG ASTAR
AGLm
vg
The INH ASTAR command inhibits network communication between the RTPP and
DFCS.
Table 3.23: Inhibit Network Communication.
3.4.7
Keyboard Command
Command Arguments
INH ASTAR
none
RTPP-DFCS Integration
As specified on Task 8 of Table 3.1, the RTPP will only provide flight-patterns24 to
DFCS. DFCS will use these flight-patterns in the GNC algorithms for to provide guidance to the
aerial vehicles. The block diagram of how DFCS uses flight patterns and of how DFCS will use
the RTPP flight-patterns is shown on Illustration 3.8 below.
24The
RTPP waypoint capabilities will not be discarded because they can be useful in a future waypoint guidance
project.
102
Illustration 3.8: RTPP-DFCS integration.
In Illustration 3.8, each distinct entity is represented as a shaded block and the white
blocks within represent the output of the corresponding modules. Starting from the left, the UAV
position data is acquired via DME or GPS and this data is output into the navigation filters. The
navigation filters use position data to compute, estimate, and predict the positions, velocities and
accelerations. These values are output to the guidance system.
The guidance system uses flight-patterns and navigation data to provide guidance to
UAV. With the addition of the RTPP, the guidance system can obtain flight-patterns from a
second source: the first and original source being the flight-pattern database. The navigation data
and the set of flight-patterns of an airborne UAV are used to compute the guidance errors. The
guidance errors measure how well the UAV follows the guidance it is provided with. These
guidance errors are computed with respect to a dynamic reference point called the rabbit, which
the DFCS GNC systems uses as a reference location. The GNC system attempts to have the
UAV locked to the location of the rabbit during the entire duration of automatic control mode
(i.e. when the computer maneuvering the UAV). The control system uses the guidance errors to
103
compute the values that are to be commanded (i.e. up-linked) to the UAV. The UAV transponder
receives the commands from the ground stations. The commands are sent to the UAV autopilot
and it closes the UAV control loops. Then the autopilot down-links telemetry data to the datalink ground stations and the cycle repeats.
3.4.8
Guidance Position Errors
The guidance position errors are displacements that occur as follows: (1) between the
UAV and the flight-pattern and (2) between the UAV and the rabbit on the flight-pattern. These
errors are measured independent of each on a dynamic right-hand local coordinate system that
moves on the flight-pattern. There are three guidance position errors; they are Cross-Track Error
(CTE), Altitude Error (ALE), and Along-Track Error (ATE) and each is assigned to one of the
axes on the dynamic right-hand local coordinate system. These errors are depicted on Figure 3.9
below. The CTE error is the perpendicular distance between the UAV and the flight-pattern. The
ALE error is perpendicular to the CTE error and to the ENU x-y plane; it is the vertical distance
between the UAV and the flight-pattern. The ATE error is the lead or lag distance between the
rabbit and the UAV on the flight-pattern. These three guidance errors measure the how well a
UAV uses a particular flight-pattern, which is the recommended flight guidance, by comparing it
to the actual flight trajectory that was made by the UAV during the flight.
104
Figure 3.9: Guidance Position Errors.
3.5
RTPP BETA PROTOTYPE
During the integration of the RTPP into DFCS, it was discovered that waypoints
guidance would not suffice as a safe flight guidance solution and that flight-pattern guidance
would be used instead. Simultaneously, the methodology depicted on Illustration 3.8 was
conceptualized; this methodology defines how DFCS is to interface with the RTPP. However,
the RTPP lacked the modules to implement this methodology. First, it lacked modules that
convert A* paths to flight-patterns. Second, the RTPP lacked modules that allow it to be linked
to the DFCS real-time computer network. Third, the RTPP lacked modules that allow it to
recover and reset itself after it provides a flight-pattern. Therefore, the following modules were
created and added to the RTPP alpha prototype: (1) Flight-Pattern Generation and Validation
(FPGV), (2) Diagnostic System (DS), (3) Real-Time Timer (RTT), and (4) Network Link. The
architecture that resulted from the addition of these modules is the RTPP beta prototype. The
105
RTPP beta prototype architecture is shown on Illustration 3.9 and its main modules are listed on
Table 3.24 below (the modules from the RTPP alpha prototype are omitted for clarity).
Illustration 3.9: RTPP beta prototype architectural diagram.
106
Table 3.24: RTPP Beta Prototype Modules.
No.
Object/Module
Acronym
1
Flight-pattern Generation and
FPGV
Validation
3.5.1
2
Diagnostic System
DS
3
Real-Time Timer
RTT
4
Network Link
NL
Flight-Pattern Generation and Validation (FPGV) Module
The FPGV module searches for an A* route that can be converted to a maneuverable
waypoints list which can be used to generate a safe flight-pattern. To do this, it uses three route
buffers and three internal modules. The three route buffers, which are listed on Table 3.25 below,
are the following: (1) Path buffer, (2) Waypoints buffer, and (3) Flight-patterns buffer. The three
modules within the FPGV module, which are listed on Table 3.26 below, are the following: (1)
Turn-Radius Validation (TRV), (2) A* Algorithm (ASA), and (3) Flight-Pattern Generator25
(FPG); these three modules, which comprise the FPGV module can be seen on Illustration 3.9.
Table 3.25: Route Buffers.
No.
Buffer Name
1
A* Path
2
Waypoints
3
Flight-pattern
Table 3.26: Modules within the FPGV Module.
25
The Flight-pattern generator object converts waypoints to a flight-pattern and the Flight-pattern Generation and
Validation object checks for discontinuities in the flight-pattern.
107
No.
Object/Module
Acronym
1
Turn-Radius Validation
TRV
2
A* Algorithm
ASA
3
Flight-pattern Generator
FPG
For each set of flight-pattern specifications, the FPGV module iteratively calls the ASA
module to generate an A* route and then passes each A* route to the Flight-Pattern Generator
(FPG) to determine if the A* route can be converted to a safe and maneuverable flight-pattern.
The FPG module obtains each A* routes that gets sent to the A* path buffer. The FPG converts
each of these A* routes to a waypoints list. The FPG searches each waypoints list for locations
that, if used, add discontinuities to the flight-pattern. If it finds such a location, it terminates its
search and penalizes the location. The FPG module assigns penalties to locations so that these
locations are excluded from belonging to A* routes that are generated in upcoming calls to the
ASA module. This process repeats for each discontinuity that is found, and terminates when no
discontinuities are found. When the waypoints list is free of all discontinuities, it gets sent to the
waypoints buffer and it also gets converted to a flight-pattern. The steps performed by the FPGV
module can be summarized as follows:
•
Step 1: Use the TRV module to ensure that the turn-radius being used is for the
specified ground speed.
•
Step 2: Use the ASA module to generate an A* route.
•
Step 3: Use the FPG module to convert the A* route to a waypoints list.
•
Step 4: Use the FPG module to search for the first location on the waypoints list
that would cause a discontinuity26 on the flight-pattern;
•
Step 5: if a location that causes a discontinuity is found, penalize the location and
return to Step 2; otherwise, continue to Step 6.
26
Discontinuities in flight-patters are similar to discontinuities as defines for functions by mathematicians. They are
sharp turns and they are un-maneuverable by airborne UAV.
108
•
Step 6: generate a flight-pattern.
3.5.1.1 Turn-Radius Validation (TRV) Module
The FPGV module begins the flight-pattern generation process by calling the UAV TurnRadius Validation (TRV) module. The TRV module ensures that the minimum distance of each
line segment on the A* path is at least equal to the maximum turn radius rt,max of the flight for the
specified maximum ground speed vg,max. Using terrain maps with quantization value q that is
equal to or greater than the worst-case scenario turn radius rt,max is done to enforce that the turns
(on the A* route) leave enough space for the UAV to maneuver them. The TRV module
computes the worst-case scenario turn-radius rt,max using a vertical acceleration of av = 1 G =
32.2 ft/s2, a bank-angle of φ = 60˚, and the specified maximum ground speed vg,max that is
expected that the UAV will use on the desired flight-pattern. This worst-case-scenario turn radius
is used as a check or to select the minimum value for the quantization value q of the terrain map
that is currently loaded or that is to be loaded. This means that the quantization value q of the
terrain map that is loaded or that is to be selected must be greater than or equal to the worst-case
scenario turn-radius rt,max.
The RTPP beta prototype implements UAV turn radius constraints to only the required
amount. It does this by varying and setting the terrain-map-partition size q equal to the worstcase scenario turn-radius rt,max computed for UAV flying at a particular ground speeds. Adjusting
the RTPP terrain map quantization value q also increases or decreases the RAM usage to only
the required amount. The feature of allowing a UAV to use different ground speeds results in
different values for the worst-case scenario turn radius. To handle this situation, multiple terrain
maps with different quantization value q were created and each map is assigned to be used at a
particular range of the specified ground speed. This method allows the terrain map that has the
quantization value q that is closest to the worst-case scenario turn-radius rt,max and still greater
than it to be loaded for a particular ground speed.
The generation and use of terrain maps with variable quantization value q is a feature that
was designed into the RTPP alpha prototype and into the TMC. Specifically, Design 3.1 forced
109
this flexibility which easily allows these variable quantization terrain maps to be generated by
the TMC and used by the RTPP which are required for generating safe and maneuverable flightpatterns for UAV flying at different ground speeds.
3.5.1.2 A* Algorithm (ASA) Module
The FPGV module continues the flight-pattern generation process by calling A*
Algorithm (ASA) module; it does this after it uses the TRV module to enforce that the correct
terrain map is loaded for the ground speed of the desired flight-pattern. Notice that the terrain
map quantization value q is obtained from the File Processing and Map Feature Extraction
object. This is done as a double check to ensure that the terrain map that is actually loaded has a
quantization value q that is equal to or greater the turn-radius that was computed from the
maximum ground speed that was entered by an operator and used by the TRV module. The ASA
module’s inputs which are the flight-patterns specifications are obtained from the Real-Time
Timer (RTT) module. The block diagram for this process is depicted on Illustration 3.9. The
flight-pattern specifications that are input into the ASA module are listed on Table 3.27 below.
Table 3.27: A* Algorithm Inputs for the Desired Flight-Pattern.
Input
Description
ha
Flight altitude
AGLm
Minimum Above-Ground-Level distance
(xi, yi)
Quantized start location
ψi
Quantized initial true heading
(xf, yf)
Quantized destination location
ψf
Quantized terminal true heading
Quantization value of the terrain map that
q
is loaded
110
The ASA module requires the start location (xi, yi), the destination location (xf, yf), the
flight altitude ha, the minimum Above-Ground-Level AGLm distance, and the quantization value
q of the terrain map that is loaded so that it can generate an A* route. The initial and terminal
true headings ψi and ψf for the desired A* route are not required by the ASA module. However,
if true headings are provided, the flight-patterns initial and terminal segments will have these
specified true headings27. The ASA module uses these values to compute the evaluation function
f(ni) for each node that is to be generated. The heuristic function h(ni) uses the destination
location (xf, yf) to compute the two-dimensional Euclidean distance between it and current
location (xc, yc) on the z = 0 plane. The cost function g(ni) uses the node ns that represents the
start location (xi, yi) to compute the sum of the arc-cost values to get from to the start node ns to
the node that represents the current location ni.
All the arcs on the implicit graph have one of two arc-cost values: 1 or ∞. The ASA
module uses these arc-cost values to avoid including certain locations in the A* route that is
being generated. Excluding these locations is what controls the following properties of the A*
route: (1) the route’s initial and terminal true headings; (2) the minimum AGL distance between
the flight-pattern and the terrain underneath it; (3) the exclusion of locations that interfere with
flight-pattern smoothing. An arc-costs of ∞ is assigned to arcs that connect to vertices that are
penalized. These constraints which implemented by penalizing the locations that do not meet
these criteria are all represented graphically by the RTPP. First, the RTPP depicts penalized
locations associated with true heading constraints as black squares. Second, high-contrast-color
topographic maps are used to identify the locations that do not meet the minimum AGL
constraints. Third, penalized locations associated with flight-pattern discontinuities as also
depicted as black squares.
In Figure 3.10 below, the A* route is depicted as a series of black line segments that
connect from the center of one square to the center of the next square. Some of the A* route’s
line segments appear to be longer than they actually are when no change in heading occurs
27
All true headings ψ are snapped to one of eight possible values: 0°, 45°, 90°, 135°, 180°, 225°, 270°, and 315°.
111
between successive locations. However, the A* route is an ordered set of points that separated by
the space between the centers of successive squares. The effect of these penalties can be
observed by comparing them to the A* route that is generated. Notice that the A* route does not
pass through any of the penalized locations, which are marked with black squares. Notice the
ends of the route. The start and destination locations can be distinguished by observing the color
of the squares at the route’s ends. Green is for the start location and red is for the destinations
location.
Figure 3.10: A* route.
Precise real-time guidance can be provided for an airborne UAV if its initial true heading
is provided. True heading penalties are enforced on the implicit search graph before the search
for a path begins. First, the arc-cost of the vertex that makes the specified true heading with the
112
start location is assigned a value of 1. This means that the virtual UAV can move from the start
location to this next location. Next, arc-costs of ∞ are assigned to the arcs of the seven remaining
vertices that connect to start location. This means that the cost to get from the start location to
any of these seven locations is ∞. When the evaluation function is computed for each of these
nodes, the node whose arc-cost is 1 will be above the ones whose arc-cost is ∞. The end result is
that seven out of the eight locations adjacent to the start location are penalized when the initial
true headings is specified.
Figure 3.11 below shows an A* route that has a true heading constraint of 90° at the start
location. Notice that seven of the locations that surround the start location are penalized and
marked with a black square and that only one location is left un-penalized, and it is marked with
a yellow square. Additionally, notice the true heading made between the start location and the
location made with the yellow square is 90°. By observing the penalties assigned as a result of
true heading constraints (See Figure 3.11), is obvious that no heading constraints were assigned
to the A* route of Figure 3.10.
113
Figure 3.11: A* route with a 90° heading constraint at the start location.
An A* route with the desired true heading for when the UAV is exiting it can be created
if the route’s terminal heading is provided. The penalties for the terminal heading are enforced
similarly to those of the initial heading. Arc-costs of ∞ are assigned to the arcs of seven vertices
that connect to destination location. This means that the virtual UAV will not traverse the
associated nodes because the cost to get to them from another node is ∞.There is only one node
whose arc is not set to Arc-costs of ∞ are assigned to the arcs of seven vertices that connect to
destination location. This means that the virtual UAV will not traverse the associated nodes
because the cost to get to them from another node is ∞; it is the vertex that makes the specified
true heading with the destination location. The arc of this node is assigned a value of 1. This
leaves an opening for the virtual UAV to move from this location to the destination location.
114
The result of providing a terminal true heading is that seven out of the eight locations
adjacent to the destination location are penalized. This can be observed on Figure 3.12 below. In
this figure, an A* route that has a terminal true heading constraint of 90° is shown. The only
location surrounding the destination location that is not penalized is marked with a yellow
square. Notice that the true heading made between this location and the destination location is
90°. On Figure 3.11, the initial true heading was computed between the start location and the
location with the yellow square whereas on Figure 3.12, the terminal true heading is computed
between the location with the yellow square and the destination location. This is so because in
Figure 3.11, the virtual UAV is exiting the start location and in Figure 3.12, the virtual UAV is
entering the destination location.
Figure 3.12: A* route with a 90° heading constraint on the destination location.
115
The true-heading constraints add precision to real-time guidance. For instance, consider
the task of providing guidance to a UAV that has is flying at East at an initial true heading of 90°
and the purpose is to make it fly to a presentation location and then have it return immediately to
the start location. One solution to this situation is to use the RTP with an initial true heading
specification equal to the initial true heading of the airborne UAV. Additionally, since the
destination location is known, provide the terminal heading of the desired route so that at the end
of the presentation, the UAV can begin its return to the start location. Figure 3.13 shows this
solution. This A* route was provided with an initial true heading constraints of 90° and a
terminal true heading constraint of 270°. Notice that the path was created by avoiding the
locations that have the black squares surround the start location and the destination location.
Figure 3.13: A* route with heading constraints of 90° at the start and 270° at the destination.
116
High-contrast-color topographic maps are used to identify the locations that do not meet
the minimum AGL constraints. For instance, if a A* route is being generated for a UAV flying at
. Notice that the route did not use the green squares.
Figure 3.14: A* avoiding high-terrain.
Figure 3.10 above has 17 penalized locations; there are no penalties surrounding the start
location and there is only one penalty surrounding the destination location. Black squares
identify locations that were penalized for one of two reasons: (1) to enforce true heading
constraints; (2) to exclude locations make the guidance un-maneuverable for the UAV at that
location. It was shown above that true heading constraints penalize seven of the locations that are
adjacent to either the start or destination location. Therefore, the single penalty that is next to the
destination location could not have resulted from a true heading constraint.
117
This penalty resulted as a flight-pattern discontinuity penalty. These penalties are
assessed by the Flight-Pattern Generator (FPG) module after the ASA module had generated an
A* route and sent it to the A* path buffer. As shown on Illustration 3.9, when the ASA module
generates an A* route, it sends it to the A* path buffer and then the FPG module obtains the A*
route in this buffer and checks if this route contains locations that caused problems. If the FPG
module finds such a location, it penalizes the location and returns control to the FPGV module.
The FPGV module calls the ASA module to generate another A* route by taking into account all
the previously penalized locations. Since, penalized locations are ignored by the ASA module
during the path generation process, the new A* route will not use them in the new path that is
being generated.
3.5.1.3 Flight-Pattern Generator (FPG) Module
The FPG module converts the A* path to a waypoints list by using the A* path’s first
point as the start point of the waypoints list. Next, the FPG module computes the true heading
between this point and the successive point. The FPG module uses this true heading value to find
the next point on the A* path that changes the true heading of the A* route. When this point is
found, it is recorded to the waypoints list. Next, the true heading between this point and the
successive point is computed and used to find the next point on the A* path that changes the true
heading of the A* route. This procedure continues until the last point on the A* path is reached.
The last point on the A* path gets recorded to the waypoints list as its terminal location. The
results of applying this procedure to the A* path of Figure 3.10 are shown on Figure 3.15 below
as a waypoints lists that is a subset of the A* path on Figure 3.10. The waypoints are shown as
grey squares. Notice that the waypoints list only includes the first point, all the intermediate
points that cause a change in heading ψ, and the last point of the A* path.
118
Figure 3.15: Waypoints.
Figure 3.16 below shows the A* path from Figure 3.10 and the waypoints list from
Figure 3.15 together; notice that the points that do not cause a change in heading ψ on the A*
path are excluded from belonging to the waypoints list. In that figure, the black squares represent
penalized locations that are forbidden from belonging in the flight-patterns that is being
generated. There are a total of 17 black squares which means that 17 locations were penalized;
17 penalized locations means that after performing 17 iterations of the steps performed by the
FPGV module to generate a flight-pattern, the ASA module had not generated an A* path that
could be made into a maneuverable flight-pattern.
119
Figure 3.16: Waypoints on top of A* route.
The FPGV uses the waypoints lists generate flight-patterns (Appendix A1 describes the
details of using an A* route to generate a flight-pattern). Figure 3.17 shows the results of
converting the waypoints list of Figure 3.15 to a flight-pattern. In Figure 3.17, the waypoints are
shown as a reference as to where circular arc-segments were placed.
120
Figure 3.17: Flight-pattern on top of waypoints list.
Figure 3.18 shows the A* and the waypoints list from Figure 3.1l underneath the
corresponding flight-pattern that is shown on Figure 3.17. From this image it can be determined
that the ASA module was called 17 times and that only at the 18th iteration, a maneuverable A*
route was found. This can be determined from the fact that the FPGV module processes the first
maneuverable A* route that it finds into a flight pattern.
This means that FPG module found a total of 17 discontinuities in 17 previously
generated A* routes; One discontinuity penalty is enforced per A* iteration. Penalties resulting
from discontinuities indicate the number of A* iterations that were performed before a
maneuverable A* path was generated.
121
Figure 3.18: Flight-pattern on top of waypoints list on top of A* route.
3.5.2
Diagnostic System Module
The Diagnostic System (DS) is a tool that was built into the RTPP to aid in its debugging
and development in order to obtain diagnostic information on its output and performance. It
consists of a graphics display, a nodes generated counter, a real-time path-requests simulator.
The Graphics Display (GD) module is as an analysis tool used for observing A* routes,
waypoints lists, and flight-patterns. This allows the RTPP output to be analyzed visually.
The nodes generated counter was added to evaluate the A* algorithm’s performance
when experimenting with the arc costs of a search-graphs or when using a heuristic function that
has not been proven to be admissible. The fact that the A* algorithm exhausts computer memory
122
when it uses a heuristic function that is not admissible is known and during several experiments
of this nature, there were instances when the A* algorithm used all of the computer’s memory.
The simulation module was used to estimate the real-world and real-time RTPP
throughput by performing the following tasks:
•
Establishing if flight-pattern are generated in less than 3 seconds, which
establishes if real-time guidance can be attained from the RTPP
•
Iteratively generating different flight-pattern in real-time to estimate the
endurance and stability of the RTPP beta prototype.
•
Determine if speed or stability became as issue when the RTPP beta prototype
repeatedly queried for flight-patterns
The level of stability is gauged by using the simulator to create several flight-patterns in
succession. This allows the developer to look for problems in the overall system (e.g. program
corruption, computer malfunction, real-time performance degradation). The simulator shows that
extremely complicated flight-patterns are generated very fast. The simulator verified that
benchmarking tools are required to obtain the precise flight-pattern generations times. The
simulator also shows that repeatedly querying the RTPP for flight-patterns does not affect
stability or the real-time performance.
3.5.3
Real-Time Timer (RTT) Module
The timer operates at 10 Hz. Its purpose is to provide unlimited flight-patterns to the
DFCS real-time computer network during missions. The timer module is linked to a UDP
network connection module and to the diagnostic system’s simulator. It accepts flight-pattern
specifications from these two modules and passes them to the FPGV module. If the flight-pattern
request is obtained from the network module, the RTT returns a flight-pattern to the network
module.
123
3.5.4
Network Link
Flight-pattern specifications are sent from the CCS as UDP messages via the computer
network to the RTPP. These messages are accepted by the RTPP at the Network Link (NL)
module. This NL module places the flight-pattern specifications into a shared memory buffer,
which is a subprogram that is spawned as a second process upon start up of the RTPP. Last, the
RTT accesses the data from shared memory buffer and passes this data to the ASA module. This
process continues for each set of flight-pattern specifications that are sent from the DFCS realtime computer network. The dataflow is depicted on the block diagram of Illustration 3.9.
124
Chapter 4: Flight-Pattern Analysis and RTPP Empirical Testing Results
The RTPP is a prototype of an innovative product. Summarizing—the RTPP generates
flight-patterns at constant MSL altitude for UAV flying over known geographical locations
where all the obstacles are static. It uses DTED data as input to determine the locations of these
obstacles; it uses user-inputs to determine the desired flight-pattern constrains; it uses AI
technology to process the inputs and then generate minimal-distance and obstacle free routes; it
links to the DFCS computer network to provide it with the output it generates; it provides the
specified flight-patterns in real-time. The output of this prototype is ready to undergo analysis
and the prototype itself it ready to undergo empirical testing on the DFCS real-time computer
network and the RTPP output is ready to be used to guide simulated UAV.
4.1
PERFORMANCE CRITERIA
The real-world reliability of the RTPP depends on how it performs two tasks: (1) its
ability to generate flyable (i.e. minimal-distance, safe, and maneuverable) flight-patterns; (2) its
ability to generate these flight-patterns in real-time. MATLAB analysis is performed to
determine if the flight-patterns are minimal-distance and safe. The RTPP real-time performance
is tested via empirical testing. The maneuverability of these flight-patterns is evaluated by
examining data obtained in three flight-simulations on the 6-DOF DFCS flight simulator. A
simulated MQM-107D is employed as the UAV in each of the three simulations. The data from
each simulated mission is recorded at 10 Hz. This is consistent with real-world missions.
Because these simulated missions have all the properties of live missions except for the risk of
material loss, the UAV data for each flight is indicative of how a real-world UAV will perform.
4.2
SETUP FOR ANALYSIS OF PRE-LAUNCH FLIGHT-PATTERNS
4.2.1
Pre-launch Flight-pattern Parameters
To test if the RTPP generates minimal-distance and safe flight-patterns, three flight-
patterns were generated so that they can be compared to each other. Each of these flight-patterns
125
was generated for a different flight altitude in order to vary the presence of obstacles between the
start and destination locations. The following altitudes were used: 7,000 ft MSL, 6,750 ft MSL,
and 6,500 ft MSL. The obstacles for the UAV are the terrain-elevations that are equal to or
greater than the flight-altitude. Since obstacles increase as flight altitude decreases, the paths at
the lowest flight altitudes are expected to be lengthier since they have to be created to go around
the obstacles. To visually compare and emphasize the effects of obstacles on RTPP flightpatterns, three flight-patterns were created with identical start locations and identical destination
locations. The parameters for these three flight-patterns are listed on Tables 4.1, 4.2, and 4.3
below.
Table 4.1: Pre-launch Parameters for a 7,000 ft MSL Flight-pattern.
Flight-Pattern
Symbol
Reference Values
RTPP Quantized Values
Start Location
(xi, yi)
(-17,685 ft, -150,969 ft)
(-15,680 ft, -148,960 ft)
Start Heading
ψi
0°
Flight Altitude
ha
7,000 ft MSL
Destination Location
(xf, yf)
(-100536 ft, -37056 ft)
Destination Heading
ψf
45°
Minimum AGL
AGLm
150 ft
Ground Speed
vg
600 ft/s
Properties
(-101,920 ft, -39,200 ft)
RTPP Quantized
Flight-Pattern Properties
Symbol
Reference Values
Values
Start Location
(xi, yi)
(-17,685 ft, -150,969 ft)
Start Heading
ψi
0°
126
(-15,680 ft, -148,960 ft)
Flight Altitude
ha
6,750 ft MSL
(xf, yf)
(-100,536 ft, -37056 ft)
Destination Heading
ψf
45°
Minimum AGL
AGLm
150 ft
Ground Speed
vg
600 ft/s
(-101,920 ft, -39,200 ft)
RTPP Quantized
Symbol
Reference Values
Values
4.2.2
Start Location
(xi, yi)
(-17,685 ft, -150,969 ft)
Start Heading
ψi
0°
Flight Altitude
ha
6,500 ft MSL
(xf, yf)
(-100,536 ft, -37,056 ft)
Destination Heading
ψf
45°
Minimum AGL
AGLm
150 ft
Ground Speed
vg
600 ft/s
(-15,680 ft, -148,960 ft)
(-101,920 ft, -39,200 ft)
RTPP Output
The flight-patterns from Tables 4.1, 4.2, and 4.3 above were generated by the RTPP
during the pre-launch phase of each simulated mission. The RTPP output is shown on Figures
4.1 to 4.5 below.
4.2.2.1 A* Routes on RTPP GUI
Figures 4.1 to 4.3 are of the A* route. The green and red squares surrounding the route’s
start and destination location indicate penalized locations that force the A* route to have the true
headings specified on Tables 4.1 to 4.3. The solid white squares next to the routes in Figures 4.2
127
and 4.3 indicate that a penalty was assigned to the location. Each A* iteration that does not
produce a flyable route assigns a penalty at the first problem location which caused the flightpattern to become un-flyable. The number of white squares is equal to the number of A*
iterations that were performed to generate a valid flight route.
Figure 4.1: RTPP GUI displaying A* route specified on Table 4.1.
128
129
4.2.2.2 Flight-patterns sent to DFCS Real-time Network
The data that specifies the routes from Figures 4.1 to 4.3 were sent to the RTPP from the
DFCS console subsystem. That is, the computer commands originated at the DFCS console
subsystem, and the RTPP returned the flight-patterns through the network to the CCS computer.
Then the flight-patterns were loaded to the DFCS console subsystem. Figures 4.4 and 4.5 show
the flight-patterns on the DFCS console subsystem that correspond to Figures 4.2 and 4.3.
130
Figure 4.4: Flight-pattern from Table 4.2 on DFCS Console Subsystem.
131
4.2.3
Milestone 1
The RTPP was conceptualized as part of this Thesis. Since its conceptualization, it has
been implemented. Figures 4.1 to 4.3 are evidence that the RTPP employs the A* algorithm to
use terrain elevation data to generate routes. Figures 4.4.and 4.5 are evidence that the RTPP can
make a flight-pattern from an A* route and that it can pass these flight-patterns to the DFCS realtime computer network and that the RTPP flight-patterns are compatible with the DFCS
guidance system.
4.3
FLIGHT-PATTERN DISTANCE ANALYSIS
Distance is used as one criterion that establishes if a route is flyable. UAV flight time
depends on limited resources (e.g. fuel) and limited resources deplete as flight time increases.
132
Therefore, a UAV that is low on fuel should not be provided with a longer route than necessary
to get it to the destination location.
4.3.1
Impact of Obstacles on Flight-pattern Distance
The distance of RTPP flight-patterns is smallest when no obstacles exist between the start
and the destination location. To verify this claim, terrain elevation data and the three RTPP
flight-patterns from Tables 4.1, 4.2, and 4.3 are plotted together in Figures 4.6 and 4.7 below.
The flight-patterns have identical start locations, identical destination locations, but different
flight altitudes albeit the flight altitude of each flight-pattern is constant. Constant flight altitude
for each flight-pattern allows the terrain elevations to become obstacles that lie between the start
and the destination location of each flight-pattern.
Figure 4.6: Side view of flight-patterns from Tables 4.1 to 4.3 over elevation data.
133
Figure 4.7: Bird’s-eye view of flight-patterns from Tables 4.1 to 4.3 over elevation data.
Figure 4.8 shows that the flight-pattern with the smallest distance is the one at 7,000 ft
MSL and that the flight-pattern at 6,750 ft MSL is shorter than the flight-pattern with the largest
distance, which is at 6,500 ft MSL. This is because the smallest flight-pattern passes in between
the mountains. This means that the A* algorithm found passages between the obstacles and that
it used the corresponding locations to link the start location to the destination location. This is
also true for the medium length flight-pattern at 6,750 ft MSL. As can be seen on Figure 4.6, the
A* algorithm did not use the passages available at 7,000 ft MSL. Instead, it encountered high
elevation terrain at the corresponding (x, y) locations and thus continued to search for other
passages. It ended up encountering other passages north of the those found for the 7,000 ft MSL
flight-pattern. The same is true for the longest flight-pattern, which is at 6,500 ft MSL. The A*
134
algorithm had to search longer (both time and computation wise) to find passages between the
obstacles.
Figure 4.8: Flight-patterns from Tables 4.1 to 4.3 plotted on an ENU x-y plane.
Using terminology from AI and graph theory, a claim in the literature is that A* is
optimal (i.e. admissible)—that it provides the shortest path. I found this to be true only for
connected graphs. An example of a connected graph is the state-space that was provided to
generate the 7,000 ft MSL flight-pattern where the goal node was reachable from almost all other
nodes. The state-space provided for the 6,500 ft MSL flight-pattern shows a graph with a large
disconnect that is represented by the obstacle. Hence, the goal node is not reachable from as
many nodes as was the case for the 7,000 ft MSL flight-pattern.
135
4.3.2
Milestone 2
The plots on Figure 4.8 verify that the RTPP has reliable obstacle avoidance capabilities
and that it returns a minimal distance route—especially in the absence of obstacles.
4.4
FLIGHT-PATTERN SAFETY ANALYSIS
For a flight-pattern to be safe, it must not to have any obstacles in close proximity to it
for a specified distance to account for error when the UAV deviates28 from the flight-pattern.
Hence the terrain beneath the flight-pattern must not be closer than a specified distance.
Additionally, concerning the sides of the flight-pattern, up to a certain distance away, the area
that outlines the flight-pattern should have a minimum separation distance between it and the
terrain underneath it.
To control the distance between the flight-pattern and the terrain underneath it, the user
specified minimum above-ground-level AGLm distance is used. All elevation coordinates ha on
the A* route are at least the minimum above-ground-level AGLm distance above the terrain
elevation he that was assigned to the terrain-map-partition, i.e. ha - he ≥ AGLm for each location
on the A* route. The distance between the area, which outlines the flight-pattern to its sides, and
the terrain underneath this area is controlled with terrain-map files. The highest terrain elevation
value h that is found within a terrain-map-partition is assigned as the elevation he of the entire
partition. This ensures that the values he that are assigned to the centers of terrain-map-partitions
have an above-ground-level distance AGL that is equal to that of the actual location within the
terrain-map-partition with the highest terrain elevation. This forces the remaining area within
each terrain-map-partition (save the location with the highest peak) to contain an above-groundlevel distance AGL that is greater than that at the center of its terrain-map-partition. The location
with the highest peak will contain an above-ground-level distance AGL that is equal to that at the
center of its terrain-map-partition.
28
Deviation from the ideal is imminent in any real-world system.
136
The safest parts of flight-patterns are those that correspond to the centers of the terrainmap-partitions. These locations guarantee that the minimum distance between the map partition
area (which is q2 ft) and the entire terrain underneath it is at least AGLm ft. Therefore, all flightpatterns elevations ha that correspond to the centers of terrain-map-partitions are guaranteed by
the RTPP to have a surrounding area29 of q2 ft which increases from q/2 ft at its sides to 2 q/2 at
its diagonals. This area is at least AGLm ft above the highest peak he (i.e., he + AGLm ≤ ha).
Hence A* routes whose locations join to create one straight line are extremely safe because they
are guaranteed to have an above-ground-level distance AGL that is greater than the specified
minimum AGL AGLm for an area that extends out from the flight pattern with an AGL safety
radius rs-AGL whose distance is
2 q/2 ft to the diagonals at the ends of the flight-pattern and q/2
ft at the verticals and the horizontals of the flight-pattern.
On the contrary, A* route line-segments that link terrain-map-partitions that are diagonal
to each other exit the first terrain-map-partition through one of the partition’s corners. While
exiting the first terrain-map-partition, these line-segments occupy four corners and hence four
partitions simultaneously before they enter the next partition. Two of these partitions belong to
the A* route and the other two do not. The two terrain-map-partitions that do not belong to the
A* route might be penalized locations that did not meet the minimum AGL criteria. The problem
is that the resulting flight-pattern curves will be in the proximity of these two locations. Hence it
becomes apparent that these areas, which occur at the four corners, require further analysis.
Out of the four terrain-map-partition areas, where two of them are used to link a line
segment on the A* route, two of these areas of values q2 ft are safe and the other two, or a
combination of the two, might or might not be safe. Two assumptions are made about the two
terrain map partition areas that might or might not be safe:
•
Mountains increase or decrease gradually.
29 The size q of the terrain map partitions for a UAV with a ground speed of v = 600 ft/s is approximately q ≈ 6,455
g
ft. Hence, for this value of q, the distance to the sides of the partition’s center is greater than 3,000 ft. It is common
for DFCS guidance, navigation, and control systems to maneuver a UAV with cross-track errors of approximately
40 ft.
137
•
It is unlikely that the highest peak on the terrain-map-partition will always occur
at the area that is closest to the safe terrain-map-partitions.
An analysis is performed to prove or disprove if these two assumptions when combined with the
minimum AGL criteria create A* routes that have an area that surrounds them whose aboveground-level distances AGL approximates or exceeds the specified minimum above-ground-level
distance AGLm.
The analysis is carried out on the entire flight-pattern to verify that each of the
procedures, tasks, and assumptions described above when combined yield a flight-pattern with a
surrounding area that is a safe distance above the terrain. The data for this analysis is the NED
elevation data queried at 98 ft and the RTPP flight-patterns from Tables 4.1, 4.2, and 4.3. In the
analysis, each point on the flight-pattern is compared with the highest terrain elevation value that
is found within a circle. The radius of this circle is called the AGL safety radius rs-AGL and it
extends out from the location on the flight-pattern that is being used for the comparison. This
analysis is performed using three different AGL safety radii rs-AGL for each flight-pattern: rs-AGL =
1,000 ft, rs-AGL = 2,000 ft and rs-AGL = 3,000 ft.
4.4.1
Safety Analysis for Flight-pattern at 7,000 ft MSL
Figure 4.9 below shows the flight-pattern from Table 4.1. It is an altitude of 7,000 ft MSL
and the specified minimum above-ground-level distance for this flight-pattern is AGLm = 150 ft.
The end part of the flight-pattern can provide the most information from the analysis (i.e. the part
that begins where the flight-pattern is headed between the two mountain peaks and ends at the
destination location).
138
Figure 4.9: Flight-pattern from Table 4.1 near and over high elevation terrain.
The plots on Figure 4.10 are used for comparing the flight-pattern altitude ha with the
highest terrain elevation value he found within three different circles whose AGL safety radii rsAGL
is as follows: 1,000 ft, 2,000 ft, and 3,000 ft. The dash-dot black trace at ha = 7,000 ft MSL is
the flight-pattern altitude. The solid blue trace is the terrain elevation he that is directly
underneath the flight-pattern. The solid black trace is the maximum terrain elevations found
inside a circle of AGL safety radius rs-AGL = 1,000 ft, which extends out from each location on
the flight-pattern that is being compared. The same is true for the solid pink and solid red traces;
however, they each use AGL safety radii rs-AGL of 2,000 ft and 3,000 ft, respectively. Figure 4.10
shows that there are no mountain peaks that pose a collision threat with the flight-pattern. On the
contrary, the flight-pattern appears to provide a flight-altitude error cushion to the UAV of
139
approximately 250 ft. This error cushion is much larger than what is normally used. Generally,
the ALE has been bounded by 40 ft.
Figure 4.10: Flight-pattern from Table 4.1 proximity to high elevation terrain.
4.4.2
Pre-launch Flight-pattern at 6,750 ft MSL
Figure 4.11 below shows the flight-pattern from Table 4.2. It is an altitude of 6,750 ft
MSL and the specified minimum above-ground-level distance for this flight-pattern is AGLm =
150 ft. Notice the curve at the middle part of the flight-pattern; the terrain elevation at this
location appears to have the highest elevations, which should make the most useful for this
analysis.
140
The line-types and colors of the plots on Figure 4.12 below are used identically and have
the same meaning as those of Figure 4.10 above. In Figure 4.12, the red trace (which is created
by the highest elevation terrain found within a circle whose AGL safety radius is rs-AGL = 3,000
ft) almost touches the dash-dot black trace, which represents the flight-pattern altitude ha at
flight-pattern length of 60,000 ft. However, since the solid black and the solid pink traces have
their highest elevation terrain separated from the flight-pattern altitude ha by a distance of
approximately 250 ft. The black and the red traces show that there is collision threat inside a
radius of 2,000 ft. The high elevation terrain on the red trace only poses an unlikely UAV
collision risk outside a radius of 2,000 ft from the flight-pattern. I call the collision unlikely since
the UAV flying on the flight-pattern would need to simultaneously have a CTE larger than 2,000
ft and an ALE of about 50 ft (where the error is a result of the UAV being under the flight141
pattern); and all this must occur at the flight-pattern length of about 60,000 ft—a highly unlikely
condition for a mature target command and control system.
4.4.3
Safety Analysis for Flight-pattern at 6,500 ft MSL
Figure 4.13 below shows the flight-pattern from Table 4.3. It is an altitude of 6,500 ft
MSL and the specified minimum above-ground-level distance for this flight-pattern is AGLm =
150 ft. Notice that the flight-pattern is always in the proximity of high terrain but that it stays
away from it. This characteristic is a direct result of the minimum AGL criteria. As the mountain
elevations increase, the distance between the mountains and the flight-pattern altitude decreases
142
up to the point that this distance becomes less than the minimum above-ground-level AGLm
distance.
The line-types and colors of the plots on Figure 4.14 below are used identically and have
the same meaning as those of Figures 4.10 and 4.12 above. In Figure 4.14, the red trace that is
created by the highest elevation terrain (found within a circle whose AGL safety radius is rs-AGL
= 3,000 ft) passed through the dash-dot black trace, which represents the flight-pattern altitude ha
at flight-pattern length of 6,000 ft. However, the solid black and solid pink traces have their
highest elevation terrain separated by approximately 150 ft from the flight-pattern altitude ha.
Therefore, the high elevation terrain on the red trace that exceeds the flight-pattern altitude of
6,500 ft MSL does not pose a high collision threat to a UAV flying on the flight-pattern for the
same reasons provided for the plots on Figure 4.12 above (the DFCS GNC system rarely has a
CTE that exceeds 50 ft or a ALE that exceeds 40 ft).
143
4.4.4
Milestone 3
Terrain elevations he are never greater than the flight-pattern altitude ha up to an AGL
safety radius of 2,000 ft from any point on the flight-pattern. Furthermore, the highest terrain
elevations were about 100 ft below the flight-altitude for this safety radius. This means that the
UAV CTE must be bounded to 2,000 ft and the UAV ALE must also be bounded to 100 ft.
CTE of 2,000 ft is a very large cushion for error as is an ALE of 100 ft since DFCS has
very tight control on cross-track and altitude-error. All though there are exceptions (e.g. a realworld UAV can malfunction as a result of wear-and-tear or of a defective component), DFCS
commands controls UAV at CTE and ALE values of less than 40 ft and 50 ft, respectively.
144
4.5
SETUP FOR REAL-TIME PERFORMANCE ANALYSIS
To analyze the real-time performance of the RTPP, flight-patterns were generated for
airborne UAV during the flight-simulations. These flight-patterns were generated after the takeoff phase but before the landing phase in two separate flight simulations.
4.5.1
Real-time Flight-pattern Conditions for Airborne UAV
4.5.1.1 Pre-determined Real-time Flight-pattern Parameters
Two simulations were performed where real-time flight-patterns were generated by the
RTPP in response to requests that originated at the DFCS console subsystem. One real-time
flight-pattern was generated in each of the two flight simulations. For each of these flightpatterns, the destination locations were precisely pre-determined. The reference values for
ground speeds and flight altitudes were also pre-determined as 600 ft/s and 6,500 ft MSL,
respectively; however, the actual ground speed and altitude values to be used for generating the
flight-patterns were obtained in real-time from the airborne UAV by the GCN algorithms. These
measurements were obtained at the time of the flight-pattern request. The pre-determined
parameters for these two flight-patterns are listed on Tables 4.4 and 4.5 below. The flightpatterns can be distinguished by their initial direction and their destination flight-altitude. The
initial directions of the airborne UAV are Southern and Northern and their respective destination
altitudes are 6,750 ft MSL and 6,500 ft MSL.
Table 4.4: Pre-determined Flight-pattern Parameters for a Southern Bound Airborne UAV.
RTPP Quantized
Symbol
Reference Values
Values
Initial Direction
South
Destination Flight Altitude
h
6,750 ft MSL
(xf, yf)
(-17,685 ft, -150,969 ft)
Destination Heading
ψf
0°
145
(-15,680 ft, -148,960 ft)
Minimum AGL
AGLm
150 ft
Ground Speed
vg
600 ft/s
Table 4.5: Pre-determined Flight-pattern Parameters for a Northern Bound Airborne UAV.
RTPP Quantized
Symbol
Reference Values
Values
Initial Direction
North
Destination Flight Altitude
h
6,500 ft MSL
(xf, yf)
(-17,685 ft, -150,969 ft)
Destination Heading
ψf
0°
Minimum AGL
AGLm
150 ft
Ground Speed
vg
600 ft/s
(-15,680 ft, -148,960 ft)
4.5.1.2 Real-Time Flight-pattern Conditions
Conditions were used instead of pre-determined values for the start locations. In each
simulation, the condition for each start location was as follows: first, fly the UAV to
approximately 6,500 ft MSL and lock it at that altitude; second, decrease (or increase) the UAV
ground speed to 600 ft/s and lock it; and third, fly the UAV away from the destination location.
When these conditions were set, the existing location, heading, ground speed and altitude were
used as the start parameters. The start parameters were obtained at the precise moment when the
flight-pattern requests were entered into the DFCS console subsystem. Tables 4.6 and 4.7 below
show the start parameters that the RTPP received which were sent from the DFCS console
subsystem.
Table 4.6: Real-time Flight-pattern Parameters for a Southern Bound Airborne UAV.
146
RTPP Quantized
Symbol
Reference Values
Obtained in Real-Time
Values
Initial Direction
South
Start Location
(xi, yi)
(-17,685 ft, -150,969 ft)
Start Heading
ψi
180°
Ground Speed
vg
600 ft/s
Flight Altitude
h
7,000 ft MSL
(-15,680 ft, -148,960 ft)
Table 4.7: Real-time Flight-pattern Parameters for a Northern Bound Airborne UAV.
RTPP Quantized
Symbol
Reference Values
Values
Initial Direction
4.5.2
North
Start Location
(xi, yi)
(-17,685 ft, -150,969 ft)
Start Heading
ψi
0°
Ground Speed
vg
600 ft/s
Flight Altitude
h
6,500 ft MSL
(-15,680 ft, -148,960 ft)
Real-time RTPP Output
To generate the real-time flight-patterns, the UAV were situated in the worst case
scenario in that they were flying away from the destination location. This was done to
demonstrate that the RTPP uses the current heading of the UAV when generating flight-patterns.
This prevents the situation where an instantaneous and unrealistic change in direction is required
from an airborne UAV. The maximum change in direction required by RTPP flight-patterns is
45˚. This can be examined on Figures 4.15 and 4.16 below.
147
4.5.2.1 A* Routes sent to RTPP GUI
As specified on Table 4.6, this real-time flight-pattern was generated when the UAV was
flying south. To navigate the UAV from its current location, which is dynamic, the RTPP uses
the initial true heading, which in this case is 180˚, to generate the flight-pattern. Notice on Figure
4.15, that the start location is represented by a dark-green square which has seven light-green
squares and a yellow square surrounding it. The light-green squares represent the penalized
locations that are adjacent to the start location. The locations with light-green squares are
penalized with a cost of infinity and they cannot be used as locations in an A* route or a flightpattern. Therefore, only one location is accessible from the start location; it is the location that
has the yellow square. This location is south of the start location and it is directed at a true
heading of 180˚ from the start location.
Observe that the destination location, represented by a maroon square, has seven red
squares and one yellow square surrounding it. The red squares indicate locations that are
adjacent to the destination location and that are penalized with a cost of infinity. This makes the
location with the yellow square the only location that is accessible to the destination location.
Notice that the destination location is directed at a true heading of 0˚ from the yellow square.
Therefore, the destination parameters on Table 4.4 have been enforced.
148
Figure 4.15: RTPP GUI displaying A* route specified by Tables 4.4 and 4.6.
Figure 4.16 shows the flight-pattern that was generated for the condition specified on
Table 4.6. It is for a UAV whose initial true heading is north. Since this UAV is flying opposite
of the destination location, the RTPP penalized the locations whose directions from the start
location to the adjacent locations are not equal to the initial true heading of 0˚. The destination
parameters described in Table 4.5 specify a destination heading of 0˚. Notice that none of the red
squares surrounding the destination location yield a true heading of 0˚ with the destination
location. Hence the destination location has a true heading only from the yellow square, which is
directly beneath it. Therefore, this is the only adjacent location that is accessible to the
destination location and the destination heading parameter is enforced.
149
Figure 4.16: RTPP GUI displaying A* route specified by Tables 4.5 and 4.7.
4.5.2.2 Flight-patterns sent to DFCS Real-time Network
In the worst case scenario, it takes three seconds for the RTPP to generate a flight-pattern
but it generally takes less than three seconds. However, a time delay for making flight-patterns
ready for use occurs at the console subsystem. This is because a human operator has to type and
enter two keyboard commands immediately after issuing a flight-pattern request to the RTPP.
The quicker these commands a entered, the smaller the MQM-107D offset between the start
coordinates sent to the RTPP and the current location of the UAV. The keyboard commands are
necessary because they put the MQM-107D in automatic control mode and they have it acquire
the flight-pattern just generated in real-time by the RTPP. Notice in Figure 4.17 that the UAV
acquired the RTPP real-time flight-pattern from Figure 4.15.
150
Figure 4.17: Flight-pattern from Tables 4.4 and 4.6 on DFCS Console Subsystem.
4.5.3
Milestone 4
Generally, it takes much less than three seconds for the RTPP to generate a flight-pattern.
The amount of time it takes for the DFCS console subsystem to receive the RTPP flight-pattern
after it sent the request depends on issues external to the RTPP (e.g. computer network
communications, operator typing ability). Nonetheless, since the RTPP technology takes less
than three seconds to generate a solution, it is a viable real-time solution.
There is an offset between the airborne UAV and the start location of real-time flightpattern. This offset is a product of the time delay between the flight-pattern request and the time
that the flight-pattern is loaded onto the DFCS console subsystem. The offset is attributed to the
following two items: (1) the constantly changing location of the airborne UAV; (2) the
151
quantization error that results from snapping the current location of the UAV to the center of the
RTPP grid tile.
The RTPP output on Figures 4.15 and 4.16 show that the RTPP uses the UAV start and
destination direction vectors to generate flight-patterns that do not require more than a 45˚
change in true heading. This allows the UAV to adjust its true heading quickly and gradually to
the direction of the flight-pattern’s segments. Hence, no instantaneous change in direction is
required.
These elements together establish that the innovations and technology used in the RTPP
are functional in a real-time environment. In the first instance, a flight-pattern is requested for a
UAV flying south and the RTPP returned a flight-pattern whose initial segment is directed south.
The offset between the UAV and the real-time flight-pattern is small enough such that the UAV
is able to acquire to it. Lastly, the real-time flight-pattern was returned to the DFCS real-time
network in less than three seconds from the time it received the flight-pattern request.
In the second instance, a flight-pattern is requested for a UAV flying north. The RTPP
returned a flight-pattern whose first segment is directed north. Additionally, the UAV was able to
acquire the real-time flight-pattern. This means that the effects of the offset between the UAV
and the flight-pattern were negligible. This is also true for the time it took for the RTPP to
provide the DFCS real-time computer network with a flight-pattern. Therefore, the RTPP and the
technology it employs can function for guiding airborne UAV in a real-time environment.
4.6
SETUP AND ANALYSIS CRITERIA FOR 6-DOF FLIGHT-SIMULATIONS
The DFCS 6-DOF flight simulator is used to obtain flight data that is representative of a
real-world flight. The flight simulator models aircrafts and most of the states that they experience
as a result of the atmosphere. The aircraft model to be used in the flight simulations is the MQM107D subscale UAV. The simulator is to model the MQM-107D as DFCS commands and
controls real-world MQM-107D. Therefore, besides modeling the UAV sensors, engine forces
and moments, servo subsystems, and onboard autopilot, the flight simulator is also to model the
atmosphere, the DME data-link subsystem, and the navigation, guidance, and control systems.
152
4.6.1
DFCS Simulation Setup
The DFCS 6-DOF flight simulator is used in this study to perform three flight simulations
of the DFCS GNC system being utilized to control the simulated MQM-107D subscale UAV that
are being guided in real-time by RTPP flight-patterns (This scenario is depicted on Illustration
3.8). The simulations are used to analyze following flight conditions:
1. The RTPP ability to guide a UAV in real-time
2. The MQM-107D ability to stay on the RTPP generated flight-pattern with
minimal cross-track and altitude error
3. The MQM-107D ability to transition between different RTPP generated flightpatterns.
(1) is concerned with providing a flight-pattern that takes into account the UAV dynamics (in
particular, how does the RTPP provide a flight-pattern for an airborne UAV that is moving at an
awkward heading with respect to the destination location). The main test of (2) is if the UAV is
capable of maneuvering on extremely rigorous RTPP flight-patterns. (3) is used for examining
the how a UAV transitions between different RTPP flight-patterns
4.6.2
Guidance Errors Analysis
The Altitude Error (ALE) and the Cross-Track Error (CTE) from Section 3.8 are used to
measure the extent that the UAV is capable of maneuvering and following the RTPP generated
flight-patterns. Concerning flight-altitude, the ideal condition is to have the UAV flying at an
altitude equal to that of the flight-pattern altitude ha for the duration of the flight-pattern; this
corresponds to ALE = 0 ft on the flight-pattern. Concerning the UAV perpendicular
displacement on the flight-pattern, the ideal condition is to have the UAV locked on the flightpattern such that it follows it exactly (in a similar manner to how a train follows the tracks). If
this occurs, the UAV will recreate the flight-pattern with its trajectory; this corresponds to a CTE
= 0 ft. These two guidance errors are the references that establish if the UAV follows the RTPP
flight-patterns to a safe and realistic tolerance.
153
4.7
DATA ANALYSIS FOR FLIGHT SIMULATION AT 7,000 FT MSL
This simulation is the base case—only one flight-pattern is used and it was not created in
real-time. This simulation proves two things: (1) that RTPP flight-patterns are compatible with
DFCS; (2) that the turn radii on the flight-pattern are maneuverable by a simulated MQM-107D
subscale UAV. This simulation establishes that the RTPP performs flawlessly when it is not used
in real-time, which is a necessary condition before it can function well in real-time.
The simulation began by generating the pre-launch flight-pattern that is specified on
Table 4.1. It proceeded by manually launching a simulated MQM-107D subscale UAV. The
DFCS GNC system was used to maneuver the UAV to the start location of the flight-pattern.
When the UAV reached the start of the 7,000 ft MSL flight-pattern, it was put to automatic
control mode and the DFCS GNC system commanded and controlled it for the entire duration
that the UAV was on the flight-pattern.
4.7.1
Pre-launch Flight-pattern Maneuverability Analysis
In Figure 4.18 below the flight-pattern is the solid blue trace and the actual MQM-107D
flight trajectory is the dash-dot red trace. This plot shows that the UAV followed the RTPP
flight-pattern flawlessly.
154
Figure 4.18: Actual flight trajectory on flight-pattern from Table 4.1.
The plots on Figure 4.19 show that the RTPP created a flight-pattern that meets the
specified above-ground-level distance of 150 ft. Figure 4.19 (a) shows the flight-pattern as a blue
trace, the actual UAV flight trajectory as a dotted red trace, and the terrain elevation he as a black
trace. The RTPP flight-pattern altitude ha = 7,000 ft MSL is well above the specified minimum
AGL of 150 ft. The smallest value of AGL distance is about 500 ft and it occurs at
approximately 250 s. Figure 4.19 (b) shows the actual UAV AGL distance as a solid red trace
and the specified flight-pattern AGL as a solid blue trace. The UAV always exceeded the
specified minimum AGL by at least 200 ft.
155
Figure 4.19: (a) Flight altitudes and terrain elevations; (b) Actual and desired AGL.
Figure 4.20 (a) shows a time plot of the UAV ENU x-coordinate; Figure 4.20 (b) shows a
time plot of the UAV ENU y-coordinate; Figure 4.20 (c) shows a time plot of the UAV true
heading ψ; Figure 4.20 (d) shows a time plot of the UAV roll angle φ.
True heading of 0˚ and 45˚ were specified for this flight-pattern’s start and destination
locations, respectively. The vertical lines at the start of the true heading trace indicate oscillations
from and between 0˚ and 359˚ since 359˚ transitions to 0˚ (as opposed to 360˚) and vice-versa;
nonetheless, the UAV was traveling north at the start of the run. The true heading at the end of
the plot is at 45˚. These values show that the UAV used the true headings that were specified on
Table 4.1. The roll angle plot shows that the UAV made only two turns during the flight: one at
the beginning and one at the end. At the start of each of the rolls, the roll angle φ appears to
exceed 60˚ briefly and then the value stabilizes at about 55˚; this is a result from a roll angle
156
bound of φ = 60˚ imposed on the roll angle; hence DFCS commands a maximum roll angle to the
UAV of φ = 60˚.
Figure 4.20: (a) ENU x; (b) ENU y; (c) True heading; (d) Roll angle.
Figure 4.21 (a) shows a time plot of the UAV ground speed vg; Figure 4.21 (b) shows a
time plot of the UAV normal acceleration an; Figure 4.21 (c) shows a time plot of the UAV ALE.
Figure 4.21 (d) shows a time plot of the UAV CTE. Figure 4.21 (e) shows a time plot of the
UAV Along-Track Error (ATE).
The ground speed of the UAV had minor variations from the specified speed of 600 ft/s
when the UAV was performing its turns. These variations resulted from the ATE. The trace on
Figure 4.21 (e) shows that the ATE was positive which means that the UAV got ahead of the
rabbit. The DFCS GNC system commanded a lower ground-speed to allow the rabbit to catch up
157
with the UAV. However, the rabbit ended up getting ahead of the UAV, and the GNC system
commanded a higher ground-speed so that the UAV could catch up with the rabbit. The ATE
approaches zero after the variations in ground-speed; at zero ATE, the rabbit is locked to the
UAV on the flight-pattern. The CTE and the ALE increased to approximately 50 ft and 20 ft,
respectively, when the UAV exceeded 600 ft/s. However, these errors are normal when the
DFCS is commanding and controlling a UAV. Furthermore, the ALE verifies that the MQM107D stayed at an altitude of approximately 7,000 ft MSL which is what is commanded by the
RTPP flight-pattern. The UAV CTE and ALE are within the AGL safety radius.
Figure 4.21: (a) Ground speed; (b) Normal acceleration; (c) CTE; (d) ATE.
158
4.7.2
Milestone 5
Having a simulated UAV maneuver the proposed trajectory establishes that the
preliminary conditions required for real-time guidance have been met. This simulation
demonstrates that the simulated MQM-107D stayed on the RTPP generated flight-pattern
without difficulty.
4.8
DATA ANALYSIS FOR FLIGHT SIMULATION AT 6,500 AND 6,750 FT MSL
This simulation is used for two purposes: (1) to acquire data on how an MQM-107D
handles transitioning between two RTPP flight-patterns; (2) to perform empirical testing to
estimate the real-time performance of the RTPP.
Table 4.2. The simulation proceeded by manually launching a simulated MQM-107D subscale
UAV. The desired state of the UAV was a ground speed of 600 ft/s at a flight altitude of 6,500 ft
MSL. The ground speed was allowed to exceed 600 ft/s during the take-off phase where the
UAV was climbing to the specified flight altitude. When the MQM-107D reached an altitude of
approximately 6,500 ft MSL, the Barometric Altitude Hold (BAH) control mode was enabled so
that the DFCS GNC algorithms would maintain the MQM-107D at that altitude. At this point,
the UAV ground speed was reduced to approximately 600 ft/s and the Speed Hold on Throttle
(SHOT) control command was enabled to keep the ground speed at this rate.
The UAV was flown until it was at a location to the right and south of the flight-pattern
specified on Table 4.2. At this point the UAV was headed south and away from the Table 4.2
flight-pattern. Then, the SEG ASTAR keyboard command was entered and the RTPP was sent
the UAV current state and parameters which are listed on Tables 4.4 and 4.6 (e.g. specified
destination location, initial and final UAV true headings, minimum AGL, flight altitude, and
UAV ground speed). In response, the RTPP generated the 6,500 ft MSL flight-pattern that
connects to the pre-launch flight-pattern at 6,750 ft MSL. These RTPP flight-patterns are shown
on Figure 4.22 below; the red flight-pattern was created in real-time; the black flight-pattern was
created pre-launch.
159
Figure 4.22: Real-time flight-pattern links to pre-launch flight-pattern.
Figure 4.23 below shows that the connecting flight-patterns are offset in elevation by a
distance of 250 ft.
160
Figure 4.23: Real-time flight-pattern linking to pre-launch flight-pattern over terrain.
4.8.1
Real-time Flight-pattern Maneuverability Analysis
The real-time flight-pattern was generated to guide the airborne UAV from its current
location, at its current true heading, at the approximate pre-planned flight altitude of 6,500 ft
MSL to the start location of the flight-pattern described on Table 4.2, where it is to transition30 to
a flight altitude of 6,750 ft MSL.
The precise time it took for the flight-pattern to be received at the DFCS console subsystem from the time the SEG ASTAR command was issued is not known since a bottleneck31
30 This transition is purposely made more challenging by having the UAV acquire to a flight-pattern that is at
different flight altitudes than the one it is currently on.
31 In this sense, the term bottleneck means that although the flight-pattern was available to be loaded, it’s loading
time was delayed for other reasons than the flight-pattern not being available.
161
was occurred at DFCS console subsystem where the human operator was typing the following
keyboard commands: (1) ENA AUTO 1; (2) SET FPA 1 F 2. These commands are for making
the flight-pattern ready for use by the DFCS GNC system and for putting the MQM-107D in
automatic control mode to acquire to the real-time flight-pattern.
In Figure 4.24 below, the solid blue trace is composed of the RTPP flight-patterns from
Table 4.4 and from Table 4.2, in that order. The two flight-patterns are shown as a single plot to
emphasize the smooth transition between the real-time and the pre-launch flight-patterns. The
dash-dot red trace is the actual MQM-107D flight trajectory. It overlaps most of the real-time
flight pattern and part of the pre-launch flight-pattern. This plot is missing its first part. However,
this missing data only shows that the bottleneck effect is negligible since the part where the data
begins is locked with the real-time flight-pattern; this means that it was also locked up to a
certain point before then, which means that the UAV successfully acquired the flight-pattern
within enough success that it was able to use it as guidance to take it to the destination location.
This can be verified by the plots, which show that the UAV followed the real-time flight-pattern
until it transitioned to the pre-launch flight-pattern.
162
Figure 4.24: Actual flight trajectory on flight-patterns from Table 4.4 and 4.6.
The plots on Figure 4.25 (a) show the flight-pattern as a blue trace, the actual UAV flight
trajectory as a dash-dot red trace, and the terrain elevation he as a black trace. The RTPP flightpattern altitude ha = 6,500 ft MSL is well above the specified minimum AGL of 150 ft for the
entire flight-pattern. The flight-pattern altitude is one order of magnitude larger than the
specified AGL. This means that the minimum AGL error cushion was not required for
preventing the generation of a flight-pattern that is too close to the ground.
Figure 4.25 (b) shows the actual UAV AGL distance as a solid red trace and the specified
flight-pattern AGL as a solid blue trace. The AGL distance of the flight-pattern is approximately
2,500 ft for most of the flight-pattern. The results on Figure 4.25 (a) and (b) show that the MQM107D stayed at the altitude of 6,500 ft MSL and that when it reached the end of this flight-
163
pattern, it performed a smooth transition between flight-patterns by performing a 250 ft climb to
transition the UAV from the 6,500 ft MSL flight-pattern to the 6,750 ft MSL flight-pattern.
The data point on the true heading plot is at 270˚; this value is consistent with the flight
trajectory shown as the dash-dot red trace on Figure 4.24 above. The oscillating true heading that
occurs at the middle of the trace (between 0˚ and 359˚) is when the UAV is transitioning between
flight-patterns. The CTE for the corresponding part of the plot shows that the transition occurred
very smoothly between the flight-patterns. However, the ATE for the corresponding plot shows a
164
transient; this is due to the climb from one flight-pattern to the other. The roll angle plot shows
that the UAV rolled three times during the flight: once at the beginning, once at the middle, and
once at the end. The CTE of the first roll is at 200 ft, the ALE is about 10 ft. This can be seen of
Figure 4.27 below.
The ground speed of the UAV exceeded the specified speed of 600 ft/s by about 65 ft/s
when the UAV was performing its first turn, which resulted in an ATE of -500 ft. Nonetheless,
165
the CTE which started at 230 ft stabilized to 0 ft in about 12 s and the ALE was always stable
through out the entire run. These plots verify that the RTPP provided stable and valid guidance
in real-time even though the UAV was being flying faster than what the flight-pattern was
created for.
4.8.2
In Figure 4.28, the blue trace is the flight-pattern from Table 4.2 and the dash-dot red
trace is the actual MQM-107D flight trajectory. The part of the dash-dot red trace that does not
have a blue trace underneath it was analyzed in the previous section and is only shown to
emphasize that the UAV transitioned smoothly between flight-patterns. These traces verify that
166
the UAV completed pre-launch flight-pattern after it completed the real-time flight-pattern
without difficulty.
167
Figure 4.29: Flight-pattern from Tables 4.4 and 4.6 on DFCS Console Subsystem.
AGL of 150 ft. Figure 4.30 (b) shows the actual UAV AGL distance as a solid red trace and the
specified flight-pattern AGL as a solid blue trace. The UAV was always exceeded the specified
minimum AGL by at least 250 ft. The results on Figure 4.30 (a) and (b) show that the MQM107D stayed at the altitude of 6,750 ft MSL commanded by the flight-pattern and that the
minimum AGL of the UAV was well above the specified minimum AGL of 150 ft. Hence the
UAV flew at a safe flight altitude for the duration of the flight-pattern.
168
locations, respectively. The start and the middle of the true heading trace show that the UAV was
headed north (i.e. ψ = 0˚, 359˚); at the end of the plot, true heading is 45˚. These values show
that the UAV used the specified true heading for the flight-pattern. The roll angle plot shows that
the UAV performed a series of plots while following the flight-pattern. The magnitudes of the
CTE and the ALE errors as the UAV maneuvered these turns are shown on Figure 4.31 below.
169
The UAV ground speed was unstable. It exceeded the specified speed of 600 ft/s several
times during this part of the simulation. The ground speed transient at t = 740 s caused an ATE
magnitude of 150 ft. This resulted in a CTE of 350 ft. However, the ALE was not affected by the
CTE and the ATE. Overall, this data and the plots on Figures 4.24 and 4.28 verify that the UAV
followed the traces within a tolerance of CTE = 350 ft and ALE = 20 ft except during the climb
from the first flight-pattern to the second flight-pattern.
170
4.8.3
Milestone 6
This simulation shows that the UAV acquired the real-time generated flight pattern and
that it used it as guidance to travel to the start of the pre-launch generated flight pattern. The
true-heading specifications that were built in to the RTPP were used to generate the real-time
flight-pattern that would have the account for the airborne UAV direction and for the flightpattern direction when the UAV exited the flight-pattern. These heading constrained proved to be
essential for the real-time guidance success that was exhibited during this simulation. The RTPP
real-time response had to be estimated since precision benchmarking equipment was not
available. Nevertheless, real-time performance was exhibited by synergy of the RTPP and DFCS
171
when the airborne UAV successfully acquired to flight-pattern that was generated in real-time
and used it to the flight-patterns completion as guidance.
This simulation established that the RTPP can create flight-patterns that link perfectly to
allow a UAV to transition between them. This is shown in the blue trace on Figure 4.24 which
appears to be a single flight pattern, when in actuality the trace is composed of two distinct flight
patterns that connect perfectly. This can also be seen in the simulation in that an MQM-107D
transitioned smoothly from the real-time flight pattern to the pre-launch generated flight pattern
even though both flight-patterns were at different flight-altitudes. Hence, RTPP flight-patterns
force smooth transition between the flight-patterns it generates.
4.9
DATA ANALYSIS FOR FLIGHT SIMULATION AT 6,500 FT MSL
This simulation is used for two purposes: (1) to acquire data on how an MQM-107D
maneuvers rigorous RTPP flight-patterns; (2) to perform empirical testing to estimate the realtime performance of the RTPP.
Table 4.3. The simulation proceeded by manually launching a simulated MQM-107D subscale
UAV. The desired state of the UAV was a ground speed of 600 ft/s at a flight altitude of 6,500 ft
MSL. The ground speed was allowed to exceed 600 ft/s during the take-off phase where the
UAV was climbing to the specified flight altitude. When the MQM-107D reached an altitude of
approximately 6,500 ft MSL, the Barometric Altitude Hold (BAH) control mode was enabled so
that the DFCS GNC algorithms would maintain the MQM-107D at that altitude. At this point,
the UAV ground speed was reduced to approximately 600 ft/s and the Speed Hold on Throttle
(SHOT) control command was enabled to keep the ground speed at this rate.
The UAV was flown until it was at a location to the right and north of the start location of
the flight-pattern that is specified on Table 4.3. At this point the UAV was headed a north. Once
the UAV was sufficiently separated and headed away from the start location of the off-line
flight-pattern, the RTPP command was issued. The operator entered the SEG ASTAR keyboard
command from the DFCS console subsystem to request flight guidance from the current UAV
172
location to the start of the pre-launch flight-pattern. The real-time flight-pattern, which is
described on Tables 4.5 and 4.7, was generated by the RTPP. Figure 4.33 below shows the realtime flight-pattern as a red trace and the pre-launch generated flight-pattern as a black trace.
Figure 4.34 shows these flight-patterns as a single flight-trajectory over the WSMR terrain.
Figure 4.33: Real-time flight-pattern links to pre-launch flight-pattern.
173
Figure 4.34: Real-time flight-pattern linking to pre-launch flight-pattern over terrain.
4.9.1
Real-time Flight-pattern Maneuverability Analysis
The flight-pattern was set on the DFCS console subsystem and automatic control mode
was enabled and the DFCS GNC algorithms started commanding and controlling the UAV on
the newly generated red flight-pattern. The time it took for the RTPP to generate this real-time
flight-pattern is not known (an educated guess would be less than one second). However, a
bottleneck occurred when setting this flight-pattern to be used by the airborne UAV. It occurred
at the DFCS console subsystem. The bottleneck proves that using a keyboard to activate a flightpattern, although feasible, is not the best solution when attempting to minimize the offset
174
between the dynamic location of the airborne MQM-107D and the start location of the real-time
flight-pattern.
In Figure 4.35 below, the solid blue trace is composed of the RTPP flight-patterns from
Table 4.5 and from Table 4.3, in that order. The two flight-patterns are shown as a single plot to
emphasize the smooth transition between the real-time and the pre-launch flight-patterns. The
dash-dot red trace is the actual MQM-107D flight trajectory. It overlaps most of the real-time
flight pattern and part of the pre-launch flight-pattern. This plot is missing its first part. However,
this missing data only shows that the bottleneck effect is negligible since the part where the data
begins is locked with the real-time flight-pattern; this means that it was also locked up to a
certain point before then, which means that the UAV acquired the flight-pattern within enough
success that it was able to use it as guidance to take it to the destination location. This can be
verified by the plots, which show that the UAV followed the real-time flight-pattern until it
transitioned to the pre-launch flight-pattern.
175
Figure 4.35: Actual flight trajectory on flight-patterns from Table 4.5 and 4.7.
The plots on Figure 4.36 (a) show the flight-pattern as a blue trace, the actual UAV flight
trajectory as a dash-dot red trace, and the terrain elevation he as a black trace. The RTPP flightpattern altitude is ha = 6,500 ft MSL. Figure 4.36 (b) shows the actual UAV AGL distance as a
solid red trace and the specified flight-pattern AGL as a solid blue trace. The plots on Figure
4.36 (a) and (b) show that the altitude error cushion provided by minimum above-ground-level
criterion was not used since the MQM-107D was flying at altitude that easily exceeded the
minimum AGL distance.
176
The data point on the true heading plot is at 315˚; this value is consistent with the flight
trajectory shown as the dash-dot red trace on Figure 4.35 above. The UAV is transitions between
flight-patterns at approximately t = 470 s where oscillating true heading occurs. The roll angle
has slight transients when compared to the plots on Figure 4.20 (e), 4.26 (e), 4.31 (e), and 4.42
(e)—these are a result of my lack of experience in using the DFCS GNC system to command and
control a UAV. Nonetheless, these transients are negligible as can be seen on the plot of Figure
4.35 above where the UAV followed the flight-pattern with extreme precision. This is also
177
verified by the CTE and the ATE plots on Figure 4.38 below; both values are within the AGL
safety cushion.
The UAV ground speed was unstable. It started at 615 ft/s and peaked at 625 ft/s. It
continued to oscillate between 585 ft/s and 615 ft/s for the remaining time that the UAV was on
this real-time flight-pattern. This ground speed oscillation was caused by the ATE, which
178
appears to be sinusoidal. As ATE increases in the positive direction, the ground-speed drops and
as ATE decreases to the negative direction, the ground-speed increases. Nonetheless, the CTE of
has a peak of -350 ft and the ALE peaked at 40 ft. Aside from these extremes, the CTE
magnitude was at about 100 ft and the ALE magnitude was at about 20 ft. Overall, this data and
the plot on Figures 4.35 verify that the UAV followed the RTPP flight-pattern to within the AGL
safety radius.
4.9.2
In Figure 4.39 the flight-pattern is the blue trace and the actual MQM-107D flight
trajectory is the dash-dot red trace. This plot shows that the UAV transitioned smoothly to the
flight-pattern from Table 4.3 and that the UAV followed most flight-pattern flawlessly.
179
However, a problem occurred at the end of the run at location x = -15x104 ft and y = 0.5x105 ft—
the rabbit got ahead of the MQM-107D which caused the along-track-error to increase. This in
turn caused the DFCS GNC systems to increase the ground speed from the specified value of 600
ft/s, which is stipulated on Table 4.3 to approximately 700 ft/s. The DFCS GNC system
performed this action in an attempt to minimize the along-track-error as quickly as possible by
having the UAV catch up with the rabbit. During this action, the DFCS GNC system also
overrode the RTPP flight-pattern momentarily. At this point, I terminated the flight simulation
because the DFCS GNC algorithms took over the UAV and used different flight parameters that
those that had pre-planned for the simulation. What this simulation shows is that a maximum
ground-speed must be set for the duration that the target is on a flight-pattern: especially for the
lengthier flight-patterns.
Increasing the ground speed was entirely un-necessary because the guidance errors that
establish success or failure are the cross-track and the altitude errors. These errors do not require
that the simulated UAV keep up with the rabbit when the rabbit is moving faster than the target.
Also, the flight-patterns are generated for a maximum ground speed and in this case, it was
increased beyond that for which the flight-patterns were generated.
180
181
AGL of 150 ft. The smallest value of AGL distance is about 500 ft and it occurs at
approximately 1,090 s. Figure 4.41 (b) shows the actual UAV AGL distance as a solid red trace
and the specified flight-pattern AGL as a solid blue trace. The UAV always exceeded the
specified minimum AGL by at least 150 ft. The results on Figure 4.41 (a) and (b) show that the
MQM-107D stayed at the altitude of 6,500 ft MSL commanded by the flight-pattern and that the
minimum AGL of the UAV was well above the specified minimum AGL of 150 ft.
182
Figure 4.41: (a) Flight altitudes and terrain elevations; (b) Actual and desired AGL..
locations, respectively. The true heading plot shows that the UAV used the specified true
heading at the start of the flight on the flight-pattern. The final true heading should be 45˚;
however, it is approximately 200˚ since this is the UAV true heading when the simulation was
stopped as a result of the DFCS legacy guidance system overriding the RTPP guidance32. The
simulation was stopped since it is the CTE and the ALE that establish how successfully the UAV
32
The legacy guidance system overrode the RTPP guidance in order to minimize the ATE; however, ATE does not
measure how well a UAV stays on the flight-patterns; it measures if the UAV gets ahead or behind of the rabbit.
183
follows flight-patterns and the turns within them. This can be verified by comparing the roll
angle plot which shows that the UAV performed a series of turns while on the flight-pattern to
the CTE and the ALE plots on Figure 4.43 below which show that the error incurred as the UAV
maneuvered these turns is within 400 ft and 20 ft, respectively.
The ATE plot shows that the ground-speed that the DFCS GNC system commands to a
UAV depends on the UAV ATE. These plots show that an increase or decrease in ATE causes
184
the DFCS GNC system to compensate by decreasing or increasing the ground-speed (e.g. when
the ground-speed value oscillated at 600 ft/s). Hence, the DFCS GNC system always attempts to
minimize the along-track-error. Nevertheless, the CTE and the ALE stayed within the tolerance
established by the AGL error cushion even though it was the ATE transients that caused higher
than necessary CTE and the ALE magnitudes. Even though the RTPP guidance was overwritten
and the simulation was stopped prematurely, the CTE and the ALE show that the UAV was able
to maneuver most of this complicated flight-pattern.
4.9.3
Milestone 7
This simulation demonstrates that the RTPP can provide excellent guidance during
extreme situations, such as for a UAV that is flying away from its destination location.
185
Furthermore, this simulation exhibits real-time guidance in that an airborne UAV acquired a
flight-pattern that was generated in real-time and in that the UAV stayed on this real-time flightpattern until it acquired to the pre-launch generated flight-pattern. This simulation also
established that rigorous flight-patterns that the RTPP generates are maneuverable by UAV. This
is seen in the UAV flight-trajectories, CTE, and ATE. The combined set of plots show that the
UAV handled most of the flight-pattern from Table 4.3 which has a series of tight turns in
succession by staying on parameter up until the DFCS GNC system overrode the RTPP
guidance.
186
Chapter 5: Conclusion
The RTPP uses a virtual environment based on real-world measurements and parameters
to respond to requests that originate in its physical environment. The RTPP virtual environment
consists of a virtual terrain and a virtual UAV. The virtual terrain is created with the files
obtained from the TMC, and the virtual UAV is created from the expected parameters of a realworld UAV. The virtual UAV parameters are provided by guidance system operators. The
virtual UAV is not to be confused with the simulated UAV that are part of the DFCS flight
simulator. Simulated UAV are as part of the physical environment as are physical UAV since it
is transparent to the RTPP whether DFCS is using a simulated UAV or a physical UAV. The
virtual components have physical counterparts; but they can be distinguished. Concerning the
virtual environment, its components are—save the flight-patterns and waypoints—those
contained within the RTPP.
The RTPP physical environment includes the DFCS real-time computer network, the
DFCS geographical area, and the UAV. The RTPP interacts directly with the DFCS real-time
computer network by processing the requests that originate at the DFCS console subsystem,
while the DFCS CCS (Central Control System) computer buffers the RTPP from the DFCS
geographical area, the UAV, and the associated assets. To provide the requested flight
trajectories, the RTPP uses the virtual environment discussed above. It creates a virtual UAV
with the parameters that match the expected parameters of the real-world UAV. It also uses the
virtual environment to locate the obstacles that will be present at the expected flight altitude. And
the end result is that the RTPP generates and sends the flight trajectories through the DFCS realtime computer network, to the CCS computer, where the guidance system uses these flightpatterns to navigate UAV.
5.1
DISCUSSION
The goal of this work was to provide evidence that AI technologies have become
computationally feasible for solving real-world problems faced by DoD TCCS personnel. This
187
work proves this by using the AI theories in the implementation of real-time UAV guidance
system to be used in an existing DoD TCCS.
5.2
FUTURE WORK
5.2.1
System Integration Issue
5.2.1.1 Improve User-Interface
During simulations, mistakes such as typos at the DFCS console subsystem, cause timely
delays that impede the UAV from acquiring the flight-pattern immediately. The RTPP user
interface would benefit by using an interface-system that is less prone to such errors: one that
prevents errors when sending requests, coordinates, and parameters.
5.2.2
Artificial Intelligence
5.2.2.1 Minimize Quantization Error
Investigate how to remove the quantization error.
5.2.2.2 Trade-Offs between Heuristic Functions: Optimal vs. Sub-optimal Solutions
Investigate the tradeoffs between using an admissible heuristic function and obtaining
results quickly with less accuracy and between using a non-admissible heuristic function and
obtaining more accurate results at the cost of sometimes exhausting the computer’s memory.
5.2.2.3 Create a Heuristic Function
The goal of this project is to evaluate the real-world implementation of the A* algorithm.
Therefore, risk factors to the project, such as using an experimental heuristic function, were
removed. Having shown that the A* algorithm can be used to provide real-world and real-time
solutions, a more accurate heuristic function should be developed.
The diagnostic system nodes’ expanded counter was created for this very purpose since
the A* algorithm can use up the computer’s memory since it stores each node that is creates in
memory. The nodes generated counter notifies the developer every time 1,000 nodes get
generated. Therefore, the nodes expanded counter is a useful tool for determining the progress or
188
digression of projects involving the development of experimental heuristic functions. The nodes
expanded counter can be activated to slow down the process of overusing the memory or to
allow a developer to terminate the system when memory exhaustion is imminent.
5.2.2.3 Create a State-Space that contains 3-Dimentional Routes
Create a connected graph by implementing a third dimension
5.3
CONCLUSION
The RTPP is a solution that was created from research, design, and development to be
utilized in conjunction with DFCS to guide, navigate, and control UAV. It was created to
evaluate if heuristic search theories from AI could be used to solve existing problems being
faced by DoD TCCS personnel. The RTPP provides a prototype of the system that ameliorates
problems in the UAV flight trajectory generation process by providing the following solutions:
(1) automating the processes of performing obstacle avoidance and of generating flight-pattern;
(2) providing the capability to modify the shape of flight-patterns in real-time and when the
UAV is airborne; (3) reducing the work load of the DoD TCCS personnel, especially the
guidance system operators.
The RTPP solves problems in the UAV flight trajectory generation process by
automatically creating flight-patterns when provided with the following data: (1) DTED data; (2)
the flight-pattern’s start and destination location; (3) the UAV flight altitude; (4) the UAV
maximum ground speed to be used in the desired flight-pattern (5) the minimum AGL distance
for the desired flight-pattern. The RTPP tests each A* route that it generates to determine if it
can be used to generate a safe and maneuverable flight-pattern. If the complete set of A* routes
that exist for a desired state within the state-space cannot be converted to safe and maneuverable
flight-patterns, no flight guidance is provided since the RTPP only generates flight-patterns from
A* routes that have tested to be safe and maneuverable. Furthermore, the RTPP proved to be a
real-time solution for airborne UAV when it was linked to DFCS and it produced flight-patterns
in real-time in response to requests that were made from the DFCS console subsystem.
189
Additionally, the simulations that were performed with the 6-DOF DFCS flight simulator, RTPP
flight-patterns, and the simulated MQM-107D validate that RTPP flight-patterns are flyable and
that the RTPP performs as designed for an airborne UAV within a real-time environment.
In conclusion, the RTPP generates safe and maneuverable flight-patterns by performing
the following tasks: (1) A* route generation, (2) maneuverability validation of all generated A*
routes; (3) flight-pattern generation from safe and maneuverable A* routes. Regarding the
quality of the solution, the RTPP succeeds in solving the following problems: (1) reducing
collision risk that exists when flying at low elevations over mountainous terrain (2) eliminating
the need for flight-patterns to be created before each mission (3) reducing the dangers that exist
in changing flight-pattern shape in real-time (4) minimizing labor intensive tasks of DoD TCCS
personnel by allowing those that do not possess the required specialized knowledge to create
flight-patterns to create them with the RTPP.
190
References
[Bar93] Barto, A. G., S. J. Bradtke and S. P. Singh, “Learning to act using real-time dynamic
programming”, Artificial Intelligence, Vol. 72, pp. 81-138.
[Boe88] Boehm, B. W., “A spiral model of software development and enhancement,” IEEE
Computer Society, May 1988, Vol. 21, No. 5, pp. 61-72.
[Bro74] Brogan, W. L., Modern Control Theory, Quantum Publishers Inc., 1974.
[Cap02] Capozzi, B., D. Rathbun, S. Kragelund, and A. Pongpunwattana, “An evolution path
planning algorithm for autonomous motion of a UAV through uncertain environments,”
IEEE Proceedings: The 21st Digital Avionics Systems Conference, 2002,
Proceedings.pp. 8D2-1 - 8D2-12 Vol.2.
[Car07] Carrano, F. M., Data abstraction and problem solving with C++: walls and mirrors, 5th
Ed, Addison Wesley Developers Press, 2007.
[Cor90] Cormen, T.H., C.E. Leiserson and R.L. Rivest, Introduction to algorithms, McGrawHill, Inc., 1990.
[Dei01] Deitel H. M., and P. J. Deitel, C++ How to Program, 3rd Ed., Prentice-Hall, Inc., 2001.
[Dre65] Dreyfus, S. E., Dynamic programming and the calculus of variations, Academic Press,
1965.
[Fau94] Fausett, L., Fundamentals of neural networks: architectures, algorithms, and
applications, Prentice-Hall, Inc., 1994.
[Kru98] Kruglinski D. J., G. Shepherd and S. Wingo, Programming Microsoft Visual C++, 5th
Ed, Microsoft Press, 1997.
[Kum88] Kumar, V., D. S. Nau and L. N. Kanal, “A General Branch-and-Bound Formulation for
AND/OR Graph and Game Tree Search, in Search in Artificial Intelligence, ed. Kanal
and Kumar, Springer-Verlag, 1988” pp. 91-130.
[Lee75] Lee, W. H. Jr. and L. T. Richardson, “Automatic Control of Drones and RPV’s in
Formation,” AIAA, 1975, USA, 1075, AIAA 1975-1122.
[Har68] Hart, P. E., N. J. Nilsson and B. Raphael, “A formal basis for the heuristic determination
of minimum cost paths,” IEEE Transactions of Systems Science and Cybernetics, July
1968, Vol. 4, No. 2, pp. 100-107.
[Hil01] Hill, F. S., Computer Graphics Using OpenGL, 2nd Ed, Prentice-Hall, Inc., 2001.
191
[Mit88] Mitchell, J.S.B., “An Algorithmic Approach to Some Problems in Terrain Navigation,”
Artificial Intelligence, Vol. 37, pp. 171-201.
[Nav98] Navtech Seminars & GPS Supply, Inc., GPS and GNSS Simulation and Analysis Using
the GPSoft SatNav Toolbox for MATLAB®, Navtech Seminars, Inc., 1998.
[Nil71] Nilsson, N. J., Problem-solving methods in artificial intelligence, McGraw-Hill, Inc.,
1971.
[Nil80] Nilsson, N. J., Principles of artificial intelligence, Tioga Publishing Co., 1980.
[NIM07] National Imagery and Mapping Agency, “National Geospatial-Intelligence Data,”
http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html.
[Osb05] Osborne, J. and R. Rysdyk, “Waypoint Guidance for Small UAVs in Wind,” AIAA,
Infotech@Aerospace 2005, Arlington, Virginia, Sep. 2005, AIAA 2005-6561.
[Ran76] Raney, J. T., and K. D. Rehm, “Precision Location, Navigation and Guidance Using
DME Techniques,” IEEE Position Location and Navigation Symposium, 1976.
[Rog95] Rogerson, D., “Open GL III: Building an OpenGL C++ Class,” OpenGL Technical
Articles in MSDN Library for Visual Studio.NET 2003, Microsoft Corp., 2003
[Rus03] Russell, S. and Norvig, P., Artificial intelligence: a modern approach, 2nd Ed., PrenticeHall, 2003.
[Sec88] Secretariat, “Document 650-88, Targets Directory, Targets Ad Hoc Group, Range
Commanders Council”, Range Commanders Council, U.S. Army, White Sands Missile
Range
[Sot07] Soto, M., P. A. Nava and L. E. Alvarado, “Drone Formation Control System Real-Time
Path Planning,” AIAA, Infotech@Aerospace 2007 Conference and Exhibit, May 2007,
AIAA 2007-2770.
[Ste95] Stefik, M., Introduction to knowledge systems, Morgan Kaufmann Publishers, Inc.,
1995.
[USG07] U.S.G.S. Earth Resources Observations and Science, “Seamless Data Distribution
System,” http://seamless.usgs.gov/.
[Vis03] Visual C++.NET™, Visual Studio.NET™, Ver. 7.1.3088, Microsoft Corp., 2003
[Win94] Winston, W. L., Operations research: applications and algorithms, 3rd Ed., International
Thomson Publishing, 1994.
[Woo97] Woo M., J. Neider and T. Davis, OpenGL programming guide: the official guide to
learning OpenGL, version 1.1, 2nd Ed, Addison Wesley Developers Press, 1997.
[Yao05] Yao-hong Q., P. Quan, and Y. Jian-guo, “Flight path planning of UAV based on
Heuristically Search and Genetic Algorithms,” IEEE 32nd Annual Conference of
192
Industrial Electronics Society, 6-10 Nov. 2005, pp. Digital Object Identifier
10.1109/IECON.2005.1568876.
193
Glossary
3-D
=
3 dimensional
A*
=
Route finding algorithm, pronunciation: A-star
AGL =
Above Ground Level in ft
AGLm =
minimum Above Ground Level in ft
AI
Artificial Intelligence
=
BAH =
Barometric Altitude Hold
di
drone index
=
DFCS =
Drone Formation Control System
DME =
Distance Measuring Equipment
DoD
=
Department of Defense
DOF
=
Degrees of Freedom
Drone =
UAV
DTED =
Digital Terrain Elevation Data
ECEF =
Earth Center Earth Fixed (geocentric) coordinate system
ENU =
East North and Up coordinate system
fi
=
flight-pattern index
f(n)
=
evaluation function
FP
=
Flight-pattern
Full-scale
=
droned RPV
g(n)
=
cost function
G
=
32.2 ft/s2
geocentric
=
ECEF coordinate system
geodetic
=
latitude and longitude with respect to equator and prime meridian,
respectively, coordinate system
194
GUI
=
h(n)
=
heuristic function
h
=
MSL height (e.g. the elevation or the altitude) in ft
ha
=
flight-pattern altitude in ft MSL
he
=
terrain elevation in ft MSL
IS
=
Interrogator Subsystem
m
=
terrain map resolution–the number of points in the terrain map
mission
=
MSL =
Mean Sea Level in ft
MQM-107D =
a real-time event involving the remote operation of a RPV or UAV
subscale RPV (UAV)
n
=
node
ni
=
current node
nj
=
designates either the previous node or the next node
NED =
National Elevation Dataset
Nz
Target Normal Acceleration in Gs
=
Off-line
=
q
quantization value – the horizontal and vertical distance between points on the
=
UAV state denoting it is not airborne
terrain map
Vz
=
Target Vertical Acceleration in ft/s
rt
=
turn radius
RF
=
Radio Frequency
RFM =
Radio Frequency Module
RPV
Remotely Piloted Vehicle
=
RTPP =
Real Time Path Planner
Real-time
=
si
=
flight-pattern segment index
sh
=
Graphics Display Object (or screen) height
UAV state denoting it is airborne
195
sw
=
Graphics Display Object (or screen) width
sxmin
=
screen minimum x value in pixels on Graphics Display Object
sxmax =
screen maximum x value in pixels on Graphics Display Object
symin
=
screen minimum y value in pixels on Graphics Display Object
symax =
screen maximum y value in pixels on Graphics Display Object
SHOT =
Speed Hold on Throttle
Sub-scale
=
Target =
UAV
small UAV
Topographic = Earth surface projection to a flat plane
UAV =
Unmanned Aerial Vehicle
UHF
=
Ultra High Frequency
vg
=
ground speed in ft/s
WGS 84
=
World Geodetic Systems 1984
Weapon system
=
WSMR
=
White Sands Missile Range
xf
=
final route x location
xi
=
initial route x location
xmin
=
minimum x value on terrain map in ft
xmax
=
maximum x value on terrain map in ft
yf
=
final route y location
yi
=
initial route y location
ymin
=
minimum y value on terrain map in ft
ymax
=
maximum y value on terrain map in ft
z
=
distance between the z=0 plane and a reference object in ft
ψ
=
true heading in degrees
ψf
=
final true heading
ψi
=
initial true heading
196
ψm
=
magnetic heading
φ
=
bank angle in degrees
197
Appendix 1: Mathematics of Generating a Flight-Pattern from an A* Route
A1.1
FLIGHT-PATTERNS: ELEMENTS, INDEXING AND FORMAT
Flight-patterns are composed of three types of segments: (1) clockwise circular arcs, (2)
counter-clockwise circular arcs, and (3) straight lines. Combinations of these segments are used
to create the continuous and smooth curves within flight-pattern.
A1.1.1 DFCS Flight-Pattern Indexing Scheme
The DFCS guidance system uses multiple flight-patterns at one time. To prevent
ambiguities between flight-patterns and their segments, it provides a unique key to each distinct
flight-pattern and to each distinct segment. This prevents different flight-patterns from having
the same key and it allows segments in different flight-patterns to be referenced by using only
the segment key. The first segment of a flight-pattern is always assigned a key whose value is
equal to the key of the flight-pattern. This makes it easy to identify the first segment of a flightpattern. For example, the red flight-pattern in Figure A1.1 below has its first segment in the
middle of the figure and to the far left. Notice that underneath the green airplane symbol, there is
the value 2-2—the value to the left of the dash is the flight-pattern’s key and the value to the
right is the segment’s key. The other green numbers that are in the red flight-pattern’s
proximity33 identify some of the other segments on the red flight-pattern. The flight-pattern key,
which is the value to the left of the dash, always identifies the flight-pattern that a particular
segment belongs to.
33
At DFCS the first number is the flight-pattern key, the value after the dash is the segment key.
198
Figure A1.1: Two flight-patterns on the DFCS console subsystem.
In the figure above, notice that the red flight-pattern terminates at the right by joining to a
white flight-pattern. The red flight-pattern’s last segment is 2-35 and it joins to segment 5-26 on
the white flight-pattern. By comparing the flight-pattern numbers, it can be observed that the
white flight-pattern key is 5 and that red flight-pattern key is 2; this comparison can be used to
conclude that the red flight-pattern and the white flight-pattern are distinct. Observe that even
though the two flight-patterns join, the flight-patterns are distinct. Furthermore, the white flight-
199
pattern’s first segment is not identified; the absence of the segment 5-5 can mean that it is out of
the displays view port or that it is in the view port but not explicitly identified.
A1.1.2 Orientation of Circular Arc-segments
Circular arc-segments can have one of two orientations: clockwise and counterclockwise. Since the orientation of arcs depends on how the segment is directed (e.g. from North
to South, from South to West, etc.), arc orientations are not always intuitive. However, the arc’s
orientation can be derived by knowing the following items about a flight-pattern’s arc-segments:
•
The arc’s direction from its initial location to its final location
•
Keeping in mind that every arc on a flight-pattern is taken from a circle.
•
The general location (e.g. up, down, left, right), relative to the flight-pattern, of
this circle’s center point
For instance, in Figure A1.1, Segment 2-17, which follows Segment 2-2, is directed from South
to North. Furthermore, since the circle from which this arc is cropped is concaved toward the
right, the circle’s center point is also to the right. With this information, it can be concluded that
the circle is created by locking the radius at the circle’s center point and then sweeping the radius
clockwise. This method of sweeping the radius is analogous to how a needle on a clock moves.
As a different example, consider an arc-segment that is identical in shape and location to
Segment 2-17. Furthermore, assume that is lies directly underneath Segment 2-17 in Figure A1.1
and thus cannot be seen. Assume that this segment has the initial location of Segment 2-17 as its
final location and that it has the final location of Segment 2-17 as its initial point. Because the
initial and final locations are reversed, this invisible arc-segment is directed from North to South.
Because this arc is identical to Segment 2-17, the circle and its center point that were used to
create Segment 2-17 are also used. However, the radius now lines up from the center of the circle
to the initial location of the invisible arc. To reorient the direction of this radius such that it is
directed from the center of the circle to the final location of the invisible arc, the radius must be
swept in a counter-clock wise motion. Hence, this invisible arc that is identical in shape and
location to Segment 2-17 has counter-clockwise orientation.
200
A1.1.3 RTPP Flight-Pattern Format
Flight-patterns are stored as lists and the format for each record on this list is that shown
on Table A1.1 below. Every record on this list represents a unique segment on a flight-pattern.
Although the format for storing flight-patterns is very similar to that used by DFCS, the RTPP
does not use the DFCS flight-pattern indexing scheme. The RTPP does not label each flightpattern that it produces, and it numbers the segments of each different flight-pattern in
consecutive order starting with 1 at the first segment of each different flight-pattern. Using the
same format for storing flight-patterns, while using a generic scheme for indexing the segments
of every new flight-pattern makes DFCS flight-patterns compatible with DFCS and allows the
DFCS guidance system to assign keys that are free to be assigned to flight-patterns that it
receives from the RTPP.
Table A1.1: Flight-pattern Format.
Name
Symbol
Description
Segment
sc
The current segment of the flight-pattern.
Next segment
sn
The next segment of the flight-pattern.
If dfp = 0, the current segment sc is a line.
Segment type or
If dfp = -1, the current segment sc is a clock-wise arc.
dfp
direction
If dfp = 1, the current segment sc is a counter-clockwise arc.
Elevation
hifp
Current segment x-
Initial elevation in ft MSL of the current-segment sc.
Initial ENU x-coordinate in ft of the current segment
xifp
coordinate
sc .
Turn radius x-
ENU x-coordinate in ft of the turn radius for the
xo
coordinate
Current segment y-
current segment which has dfp = ±1.
yifp
Initial ENU y-coordinate in ft of the current segment
201
coordinate
sc .
Turn radius y-
ENU y-coordinate in ft of the turn radius for the
yo
coordinate
A1.2
current segment which has dfp = ±1.
A* ROUTES: POINTS, LINE SEGMENTS, AND VECTORS
A1.2.1 Representing A* Routes as Vectors
A* routes are stored as (x, y, h) ENU coordinates; joining these coordinates, the A* route
can be visualized as a series of line segments; these line-segments can be converted to vectors.
This leads to the first task in producing a flight-pattern from an A* route; to convert to vectors all
these line segments so that the directions of the segments in the flight-patterns can be derived.
This creates a series of vectors with magnitude q or 2 q and that have one of the following eight
direction angles: 0°, 45°, 90°, 135°, 180°, 225°, 270°, and 315°. All vectors that are computed
from A* routes can be described by Equation A1.1 below.
q, R θ ,
2q , R θ
(A1.1)
where
q
is the quantization value of the terrain map in ft; and
θ is the angle between two adjacent line segments on the A* route in degrees.
The magnitudes and angles result from the fact that each line segment is created by connecting
the centers of squares on the A* route. Hence the magnitudes are a direct reflection that the
distance between the centers of adjacent squares is either q or 2 q. Moreover, the reason the
angles are snapped to one of eight values can be explained by envisioning a point object at the
center square of any 3x3 grid within the terrain map. First, assume that the center square is
202
centered at the origin of an x-y plane and that the planes positive x-axis points toward 0°, its
positive y-axis points toward 90°, its negative x-axis points toward 180°, and that its negative yaxis point toward 270°. The point object is allowed to transition to any one of the eight
surrounding squares from the center square. Additionally, the point object is always constricted
to being at the center of the square that it occupies—i.e., if the point object is in the square, it is
located at the center point of that square. Therefore, the angles (made between the point object’s
current location and its next location) are quantized to one of eight possible values: up, down,
left, right, and the four diagonals.
A1.2.2 Representing A* Routes as Point-Vectors
A straight line of length n times q, or n·q, in an A* route is comprised of n smaller line
segments whose lengths are q. When these n line segments of length q get converted to vectors,
there will be n identical vectors 〈q, R θ〉 having magnitudes q and direction angles θ. The
redundant vectors can be eliminated by creating a new list (e.g. a waypoints list) that only
records the initial location (xi, yi, ha) and angle θ of each vector where an angle change ∆θ occurs
and that ignores all the vectors that follow until another angle change occurs at which point this
new location and angle are again recorded. This method eliminates the redundant vectors that are
not necessary to describe the straight line. It allows for the properties of two vectors to be used to
describe any line segment within an A* route:
•
The first vector 〈q, R θ1〉 is where a change in direction ∆θ occurs; this vector’s
initial location (x1, y1, ha) and angle θ1 are recorded to a list.
•
The second vector 〈q, R θ2〉 is where a change in direction ∆θ occurs; the vector’s
initial location (x2, y2, ha) and angle θ2 are recorded to a list.
This methodology can be used to guide a moving point-object that can maneuver sharp turns. It
can start traveling from the first vector’s initial location (x1, y1, ha) headed at an angle θ1 until it
reaches the second vector’s initial location (x2, y2, ha) where it changes its heading to θ2. Notice
that this method does not require any vector magnitudes to describe a straight line since each
location and direction of travel are provided by the properties of each of the two vectors. If the
203
initial location (xi, yi, ha) and angle θ of each vector where an angle changes ∆θ occurs are
recorded in order in a list, the list completely describe an entire A* route. Because the initial
locations (xi, yi, ha) and direction angles θ of these vectors can be used to specify an entire A*
route, a convention has been developed to describe these values. It is called the point-vector
notation, and it is defined in Equation A1.2 below:
( xi , yi , ha ), R θ
(A1.2)
where
xi
is an ENU x-coordinate in ft; and
yi
is an ENU y-coordinate in ft; and
ha
is the elevation of the desired flight-pattern in ft MSL; and
(xi, yi, ha)
is the initial location where motion begins at the direction angle θ;
and
θ is direction of travel in degrees.
A1.3
FLIGHT-PATTERN GENERATION
Angle changes ∆θ found on A* routes are used for representing A* routes as a set of
point-vectors on waypoints lists; waypoints lists differ from A* route lists, which are ordered
lists of ENU (x, y, h) coordinates. Using waypoints lists that are stored as point-vectors simplifies
the flight-pattern generation procedure by providing all the information necessary to derive the
values that get stored on a list whose format is that of Table A1.1. Moreover, the direction angle
θ on the point-vectors of the waypoint’s list is described using the true heading ψ from Equation
3.4. This eliminates any ambiguities concerning direction angles and allows the direction angles
θ = ψ to be used to derive the orientations of the arc-segments, which depend on the orientation
of each line segment on the waypoint’s list. The final result is that smooth turns are generated to
replace the sharp turn on waypoints lists.
204
A1.3.1 Generating a Waypoints List with Point-Vectors
The waypoints list contains all the line segments and sharp turns of the A* route from
which it is generated. The A* route and the waypoints list represent the exact same route except
that waypoints lists store the A* route more efficiently by using point-vectors that represent the
series of line segments (or redundant vectors) on A* routes. Each point-vector, or waypoint,
identifies the ENU (x, y, h) coordinate where every new direction of travel occurs. Hence, pointvectors contain only the location where each angle change ∆θ occurs. Table A1.2 below defines
the format for each record on the waypoints list.
Table A1.2: Waypoint Format.
Name
Symbol
Current segment x-
Description
Initial ENU x-coordinate in ft of the current line
xc
coordinate
segment.
Current segment y-
Initial ENU y-coordinate in ft of the current line
yc
coordinate
segment.
Elevation in ft MSL of the x-y plane in which the A*
Elevation
ha
route was generated.
The current direction of travel, specified as the current
Direction Angle
θc
true heading ψc, in degrees.
The records in the waypoints list are point-vectors 〈 (x, y, h), R θ 〉. Consecutive records
on this list contain different direction angles θ. This means that each record on the waypoints list
specifies a transition between the current direction of travel and a different direction of travel.
For instance, the first record on the waypoints list, which is Waypoint 1 w1, describes the
direction of travel θ1 = ψ1 from the given location (x1, y1, ha). The second record, which is
205
Waypoint 2 w2, provides the location (x2, y2, ha) where the direction of travel changes to θ2 = ψ2.
All the following waypoints in the list are used in a similar fashion, except for the one at the last
record, which is Waypoint f wf. This waypoint’s location (xf, yf, ha) and direction angle θf have
special meaning—the location is the destination location for which the A* route was generated;
the angle is a sentinel which has been assigned a unique value that indicates that the destination
location on the A* route has been reached.
A1.3.2 Angle Changes on a 3x3 Grid
The legs of a triangle and the numbered tiles on Figure A1.2 below are used to formally
identify all possible values that exist for the angle changes ∆θ of a point object that has reached
the center square of a 3x3 grid within an RTPP quantized terrain map. In these measurements,
only two legs of the triangle are used and the vertex of these two legs always occurs at Tile 1.
206
Figure A1.2: An A* route with ∆θ = 135˚ at the center square of a 3x3 grid.
Of the two angles (i.e. the inner and outer) that result at the vertex on Tile 1, it the smaller
of the two angles that is used to describe the angle change ∆θ that results from connecting the
previous leg, Leg p, to the next leg, Leg n. In Figure A1.2, Leg p is a constant which is created
by linking the centers of Tile 9 and Tile 1 and Leg n is a set of legs whose elements are created
by linking the centers of Tile 1 and Tile s, where s = 2, 3, 4, 5, 6, 7, 8, 9. The angle changes ∆θ
207
that a point object goes through when it starts from Tile 9 and passes through Tile 1 to reach Tile
s are as follows:
•
for s = 9, ∆θ= 0˚
•
for s = 8, ∆θ= 45˚
•
for s = 7, ∆θ= 45˚
•
for s = 6, ∆θ= 90˚
•
for s = 5, ∆θ= 90˚
•
for s = 4, ∆θ= 180˚
•
for s = 3, ∆θ= 135˚
•
for s = 2, ∆θ= 135˚
Notice that in the cases of s = 4 and s = 9, when Leg p joins to Leg n, the result is straight line.
To say an angle exists in a straight line is a contradiction. Therefore, the two angle changes that
result from s = 4 and s = 9, which are ∆θ = 0˚ and ∆θ = 180˚, are discarded and not counted as
angle changes because they do not cause angle changes within a line segment of an A* route.
Nonetheless, the point object did undergo angle changes when it traveled to the centers of Tile s,
for s = 2, 3, 5, 6, 7, 8. The set of angle changes is as follows: {45˚, 90˚, 135˚}. This means that a
point object that has traveled from Tile 9 to Tile 1 and then to Tile s for s = 2, 3, 5, 6, 7, 8 has
undergone a heading change of 45˚, 90˚, or 135˚.
A1.3.3 Angle Changes on A* Routes
In analyzing a point object at the center of a 3x3 grid of squares, it was discovered that
line segments that have angles of 0˚ or 180˚ between them can be ignored because they do not
cause angle changes within the A* route. Furthermore, when using the A* algorithm to find a
route in a terrain map that is portioned into squares, all the routes must advance in the direction
of the destination location as they are being generated; when traversing an RTPP terrain map,
only angle changes of 135˚ and 180˚ result in a route that is moving away from a specified
square. During the generation of an A* route, if an obstacle is encountered between the partially
generated route’s current location and the destination location, the route must turn sideways to
208
avoid the obstacle; sideways turns corresponds to an angle changes of 90˚ in RTPP terrain maps.
If the route cannot advance sideways (e.g. because of an obstacle or a penalized location), it must
backtrack to one of the two locations that are diagonal to the partially generated A* route’s end
point; this corresponds to an angle change of 45˚. It can also backtrack to one of the routes
existing locations, which corresponds to an angle change of 0˚. However, when partially
generated A* routes are forced to backtrack, the location that the A* route backed up to becomes
the end point of the A* route and the previous location is removed from it. This means that the
angle change of 45˚ also disappears when the previous location was removed from the A* route.
Lastly, Steps 2 and 4 from an excerpt taken from [Har68] backup the claim that RTPP A* routes
cannot contain angle change of ∆θ = 45˚.
“Search Algorithm A*:
1.)
Mark s “open” and calculate f(s).
2.)
Select the open node n whose value of f is smallest. Resolve ties arbitrarily, but
always in favor of any node n ∈ T.
3.)
If n ∈ T, mark n “closed” and terminate the algorithm.
4.)
Otherwise, mark n closed and apply the successor operator Γ to n. Calculate f for
each successor of n and mark as open each successor not already marked closed. Remark
as open any closed node ni which is a successor of n and for which f(ni) is smaller now
than it was when ni was marked closed. Go to Step 2.”
Step 2 forces the end points of partial paths to advance toward the goal node and Step 4 changes
the end point of a partially generated A* path to a child node created by a more recently
expanded node if this child node seems more promising. Hence A* routes always advance
toward the goal node and if any partially generated A* path backtracks to a previous node on the
path the node at which the backtracking occurred gets removed from the solution path.
A1.3.4 Describing Direction Angles with True Headings
The directions angles θ on A* routes correspond with the true heading description that
explains Equation 3.4; this allows the direction of motion for line segment on A* routes to be
specified as a true heading ψ. Furthermore, using true headings to describe the direction angles
209
of A* routes that are generated on terrain maps that are partitioned into squares produces A*
routes that are limited to having only one of the following eight values for the direction angle of
the resulting vectors: 0˚, 45˚, 90˚, 135˚, 180˚, 225˚, 270˚, and 315˚. The numbered tiles on Figure
A1.2 above and Equation 3.4 can be used to show the following: (1) how the quantized terrain
map leads to quantization of the direction angles θ; (2) how the true heading ψ is computed for
each direction angle θ; (3) how vectors that use true heading ψ as their direction angle are used to
describe the direction angles θ created by from Tile 1 to Tile s, where s = 2, 3, 4, 5, 6, 7, 8, 9.
The eight distinct vectors on a 3x3 square grid (such as the one shown on Figure A1.1),
are created by using Tile 1 as the tail (i.e. as the initial location), and the eight tiles that surround
it as the head (i.e. the final location). In each of the cases, Tile 1 is the reference tile and Tiles 4,
6, 9, and 5 represent True North, True East, True South, and True West, respectively, which is
consistent with the DFCS ENU coordinate system. The respective vectors between Tile 1 and
Tiles 4, 6, 9 and 5 are as follows: 〈q, R ψ1〉, 〈q, R ψ2〉, 〈q, R ψ3〉, and 〈q, R ψ4〉, where the true
heading ψ from each vector is as follows: (1) between Tiles 1 and 4, ψ1= 0˚; (2) between Tiles 1
and 6, ψ2 = 90˚; (3) between Tiles 1 and 9, ψ3 = 180˚; (4) between Tiles 1 and 5, ψ4 = 270˚;. the
respective vectors between Tile 1 and Tiles 2, 8, 7 and 3 are as follows: 〈 2 q, R ψ5〉, 〈 2 q, R
ψ6〉, 〈 2 q, R ψ7〉, and 〈 2 q, R ψ8〉, where the true heading ψ from each vector is as follows: (1)
between Tiles 1 and 2, ψ5 = 45˚; (2) between Tiles 1 and 8, ψ6 = 135˚; (3) between Tiles 1 and 7,
ψ7 = 225˚; (4) between Tiles 1 and 3, ψ8 = 315˚.
A1.3.5 Number of Records vs. Number of Segment
The number line segments l on an A* route that is stored using the format on Table A1.2
is not always equal to the number of segments s of a flight-pattern that is stored using the format
on Table A1.1. The number of A* route-line-segments l is equal to the number of flight-pattern
segments s only in the most trivial case of l = 1; the relationship between A* route-line-segments
l and the number of flight-pattern segments s is as follows: s = 2l - 1.
The number of records rf on flight-pattern lists depends on the number of records rw on
waypoints lists. A waypoints list with rw records represents an A* route that contains l = rw – 1
210
line segments where each successive line segment points in a different direction. For instance, a
waypoints list with rw = 2 records represents an A* route with only l = 1 line segment. This
means that a waypoint list with rw = 2 records always represents a straight line. This dependence
between records on the waypoints list rw and line segments l on the A* route is true for all real
rw. Using a different example, a waypoint list with rw = 3 records represents an A* route with l =
2 line segments. This relationship described by Equation A1.3 below.
l = rw − 1
(A1.3)
where
rw
l
is the number of records in the waypoints list; and
is the number of different line segments on the A* route.
Equation A1.4 below describes the dependence between the number of flight-pattern segments s
and the number of A* route-line-segments l.
s = 2l − 1
(A1.4)
where
l
is the number of different line segments on the A* route; and
s
is the number of distinct segments on the resulting flight-pattern.
This equation is useful for using the number of line-segments on the A* route to compute the
number of flight-pattern segments that are created as a result of replacing the sharp edges on the
A* route with arc-segments to create a flight-pattern. Therefore, an A* route that contains l = 1
line segments contain s = 1 distinct flight-pattern segments; an A* route that contains l = 2 line
211
segments contains s = 3 distinct flight-pattern segments; an A* route that contains l = 20 line
segments contains s = 39 distinct flight-pattern segments.
The number of records rf on the flight-pattern list can be computed by using the number
of flight-pattern segments s as shown on Equation A1.5 below.
rf = s + 1
(A1.5)
where
rf
is the number of records in the flight-pattern list; and
s
is the number of distinct segments on the resulting flight-pattern.
Equations A1.3, A1.4, and A1.5 are independent and they can combined to compute rw, l,
rf, and s in terms or each other. For example, an equation that computes the number of records rf
on the flight-pattern list by using the number of records rw on the waypoints list can be created
by performing substitutions; i.e. substituting Equation A1.3 into Equation A1.4 and the result
into Equation A1.5 produces the following equation: rf = 2rw – 2.
A1.3.6 Creating Flight-pattern Segments
Waypoints lists (whose record format is defined on Table A1.2) are used to generate the
flight-pattern segments whose format for each segment is defined on Table A1.1. Table A1.1
shows that there are three basic types of flight-pattern segments: (1) straight lines, (2) clockwise
circular arcs, and (3) counter-clockwise circular arcs. The conversion of each sharp edge on an
A* route to a smooth curve is accomplished by reconfiguring the two connecting A* route-linesegments into three flight-pattern segments: two lines that are linked by one arc.
A1.3.6.1
Angle Changes Between Two Consecutive Line Segments on A* routes
Two types of angle changes ∆θ occur on A* routes: ∆θ = 90˚ and ∆θ = 135˚. A* routes
with these two angle changes can be seen on Illustrations A1.1 and A1.2 below.
212
The A* route in Illustration A1.1 below is made up of three ENU coordinates that join to
create two line segments; the three ENU coordinates in order are as follows: (xi, yi, ha), (xf, yf,
ha), and (xu, yu, ha). The two line segment are converted to two point vectors whose angle change
between them is ∆θ = 90˚. The first line segment is created by linking location (xi, yi, ha) to
location (xf, yf, ha). These coordinates are also used to create the first vector 〈 q, R 0˚ 〉 and the
first point-vector 〈 (xi, yi, ha), R 0˚ 〉. In the first vector and in the first point vector, the tail of the
vector is at (xi, yi, ha) and the head is at (xf, yf, ha); therefore, for both vectors, the true heading ψ
= 0˚ is the direction of travel. The second line segment is created by using (xf, yf, ha) as the initial
location and (xu, yu, ha) as the final location. These two locations, in that order, create the second
vector 〈 q, R 90˚ 〉 and the second point-vector 〈 (xf, yf, ha), R 90˚ 〉. In the ENU coordinate
system, this direction of travel is east and it corresponds to a true heading ψ = 90˚34. The
corresponding waypoint list for this A* route is shown on Table A1.3 below.
The fact that the angle change is ∆θ = 90˚ and that is has the same value as the true heading ψ = 90˚ is
coincidental. If the second vector were directed west, the angle change would still be ∆θ = 90˚ and the true heading
would be ψ = 270˚.
34
213
Illustration A1.1: An A* route with an angle change of ∆θ = 90˚.
Table A1.3: Waypoint List for A* route from Illustration A1.1.
xc
yc
ha
ψc
xi
yi
ha
0˚
xf
yf
ha
90˚
xu
yu
ha
-1000
The A* route on Illustration A1.2 below is made up of three locations that join to create
two line segments with an angle change of ∆θ = 135˚ between them. The three locations are as
214
follows: (xi, yi, ha), (xf, yf, ha), and (xu, yu, ha); the first line segment is created by connecting
location (xi, yi, ha) to location (xf, yf, ha). This line segment represents the following vector and
point-vector, respectively: 〈 q, R 0˚ 〉 and 〈 (xi, yi, ha), R 0˚ 〉. The second vector is created with
the following locations: (xf, yf, ha), and (xu, yu, ha). This respective vector and point-vector, which
are 〈 q, R 45˚ 〉 and 〈 (xf, yf, ha), R 45˚ 〉, have true headings of ψ = 45˚, which corresponds to the
north-eastern direction. The second vector makes an angle change of ∆θ = 135˚ with the first
vector. The corresponding waypoint list for this A* route is shown on Table A1.4 below.
Illustration A1.2: An A* route with an angle change of ∆θ = 135˚.
Table A1.4: Waypoint List for A* route from Illustration A1.2.
215
A1.3.6.2
xc
yc
ha
ψc
xi
yi
ha
0˚
xf
yf
ha
45˚
xu
yu
ha
-1000
Sectors
Sectors are used to create arc-segment that continuously link two line segments. A unique
sector is required to smooth each of the two angle changes that occur on A* routes because the
angles α∆θ at the sector’s vertex are different for each of the two sectors. The sector vertex χ90˚
has a vertex angle of α90˚ = 90˚ and sector vertex χ135˚ has a vertex angle α130˚ = 45˚.
Equation A1.6 below computes the arc-segment length a∆θ of each sector: the arc
segment length for the sector χ90˚ shown on Illustration A1.3 below is a90˚ = 1.57q and the arc
length for the sector χ135˚ shown on Illustration A1.4 below is a135˚ = 0.785q.
a∆θ =
qα ∆θ π
180°
(A1.6)
where
a∆θ
q
is the length of the arc-segment in ft; and
is the length of the radius in ft; and
α∆θ is the sector’s angle in degrees.
Illustration A1.3 shows the sector χ90˚ that smoothes angle changes of ∆θ = 90˚ and the
flight-pattern records that result from smoothing angle changes of ∆θ = 90˚ are listed in order on
Table A1.5.
216
Illustration A1.3: Using sector χ90˚ to smooth an angle change of ∆θ = 90˚.
Table A1.5: Flight-pattern List for A* route from Illustration A1.3.
sc
sn
dfp
hifp
xifp
xo
yifp
yo
sp
sc
0
ha
xp
0
yp
0
sc
sn
-1
ha
xi
xo
yi
yo
sn
st
0
ha
xn
0
yn
0
st
-1000
-1000
ha
xt
0
yt
0
217
Illustration A1.4 shows the sector χ135˚ that smoothes angle changes of ∆θ = 135˚ and the
flight-pattern records that result from smoothing angle changes of ∆θ = 135˚ are listed in order
on Table A1.6.
Illustration A1.4: Using sector χ135˚ to smooth an angle change of ∆θ = 135˚.
Table A1.6: Flight-pattern List for A* route from Illustration A1.3.
sc
sn
dfp
hifp
xifp
xo
yifp
yo
si
sc
0
ha
xi
0
yi
0
218
sc
sn
-1
ha
xc
xo
yc
yo
sn
st
0
ha
xn
0
yn
0
st
-1000
-1000
ha
xt
0
yt
0
219
Curriculum Vita
Manuel Soto was born on October 20, 1972 to Modesto and Maria Estela Soto. He
attended public school in El Paso, TX, where he showed to have a knack for mathematics and
science. He began attending El Paso Community College in the fall of 1993, at which time he
began his pursuit for an Electrical Engineering degree. He made the Dean’s list during most of
the semesters.
Manuel’s first professional job began on the fall of 1994 as a Student Assistant at a
tutoring center at the El Paso Community College (EPCC) where he was a student. He was
chosen for this job over several candidates even though the job description required 30
completed college hours and he had only completed 27. During the spring of 1995 he was
awarded one of the Alliance for Minority Participation (AMP) awards which included a
monetary stipend, books and tuition for three credit hours, and a research job position with a
professor for the summer of 1995: all at the University of Texas at El Paso (UTEP). Manuel used
the award to enroll in the differential equations class and to be mentored by Dr. Benjamin Flores.
That summer, Manuel did research on Doppler radar and he upgraded the computer provided by
Dr. Flores—upgraded the BIOS, installed Windows 3.1, and set it up for performing MATLAB
simulations.
The next semester (Fall 1995) was the last semester that Manuel attended EPCC as a
student; it was also his second semester enrolled at UTEP. He continued working as a Student
Assistant at the tutoring center up until August of 1995, at which time he was hired as Math
Tutor at a different tutoring center within EPCC, where he worked until the summer of 1997. At
this time Manuel switched jobs to become a Research Assistant for Dr. Rene Villalobos. Here he
did research on Image Processing and Machine Vision. He also upgraded the image processing
system from DOS to Windows NT. During this research Manuel was awarded several Minority
Institutions for Excellence (MIE) stipends to help fund his research. Next, during spring of 1999,
Manuel worked for Dr. Sergio Cabrera as a research Assistant, where his research was
220
exclusively in Machine Vision. Manuel graduated in May 1999 with a Bachelors Degree in
Electrical Engineering.
From May 1999 to April 2000, Manuel Soto developed graphics, databases, and
database-driven web sites as a Software Engineer for the ESEI consulting firm. On May 2000,
Manuel Soto was hired by UNITECH as a Government contractor, where he is currently
employed as a Computer Engineer. In this job, aside from providing services (e.g. mission
support, hardware and software maintenance), he created a tank simulation module that has a
GUI interface to control servos that are simulating the tank’s steering and throttle controls. Also,
he assisted in creating and setting up modules for remote operation of M-60 tanks. Furthermore,
he created several Head-Down Displays (HDD) emulating real cockpits that are used by
controllers (e.g. U.S. Air Force pilots) to remotely operate unmanned aerial vehicles. Manuel is
currently researching and designing a new source-code repository for the DFCS source code to
update or replace the existing one. His latest work, which is part of this study, is to create an
operational version of the RTPP on DFCS.
As a result of this study, Manuel along with Dr. Patricia A. Nava and Mr. Luis E.
Alvarado as co-authors has published his first professional article in the American Institute of
Aeronautics and Astronautics journal. Additionally, Manuel and Mr. Luis E. Alvarado presented
practical applications from this study at the National Defense Industrial Association’s 45th
Annual Targets, UAVs and Range Operations Symposium & Exhibition.
Permanent address:
812 Porras
El Paso, TX, 79912
This Thesis was typed by Manuel Soto.
221

unmanned aerial vehicle real-time guidance system via state

Transcription

Similar documents

UAS, Teknologi Terkini, Perkongsian Pengalaman

a pilotless project

RCMP "F" - Draganfly

Value Proposition - University of Cincinnati

UAV Systems and Security

Safety, Reliability and Restoration PDF

TerraMap-3D® TerraMap-3D®

MC01515L Technical Sheet

3 YOU MUST SKI