GNSS and Inertial Fused Navigation Filter Simulation by Jonas Rogers A Master’s Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE In partial fulfillment of the requirements for the Degree of Master of Science in Electrical and Computer Engineering December 2017 APPROVED: Professor Alex Wyglinski, WPI ECE, Advisor Professor William Michalson, WPI ECE, Committee Member Professor Thomas Gannon, WPI ECE, Committee Member
Transcript
GNSS and Inertial Fused Navigation Filter Simulation
by
Jonas Rogers
A Masterrsquos Thesis
Submitted to the Faculty
of the
WORCESTER POLYTECHNIC INSTITUTE
In partial fulfillment of the requirements for the
Degree of Master of Science
in
Electrical and Computer Engineering
December 2017
APPROVED
Professor Alex Wyglinski WPI ECE Advisor
Professor William Michalson WPI ECE Committee Member
Professor Thomas Gannon WPI ECE Committee Member
Jonas
Approved for Public Release Distribution Unlimited 18-1385The authors affiliation with The MITRE Corporation is provided foridentification purposes only and is not intended to convey or imply MITREsconcurrence with or support for the positions opinions or viewpointsexpressed by the author
Abstract
A navigation filter simulation and analysis environment was developed through the
integration of DRAGON a high fidelity real-time PNT sensor measurement source
and Scorpion a modular navigation filter implementation framework The envi-
ronment allows navigation filters to be prototyped and tested in varying complex
scenarios with a configurable set of navigation sensors including GNSS and IMU
An analysis of an EKF using the environment showed the utility and functionality
of the system
Acknowledgments
I would like to thank everyone who provided me assistance on this project both
technical and logistical John David (JD) Quartararo for providing technical direc-
tion Professor Wyglinski for providing academic direction Joe Chapman and Matt
Douglas for supporting this collaboration The whole DRAGON team for being ex-
tremely helpful with everything through the process And finally the developers at
AFIT who helped debug Scorpion
I would also like to thank my wonderful wife who has supported me and my work
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
A Developmental and Result Plots 73
B Bibliography 98
iv
List of Figures
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
List of Figures
21 ECEF Frame with x y and z and Latitude and Longitude Note
that the ellipsoid in the diagram is not the Earth itself but instead a
generic ellipsoid that has been specified to closely match the Earthrsquos
surface [1] 9
22 East-North-Up local navigation frame with respect to the ECEF
frame at a particular position [2] 10
23 Euler angle representation in which the rotations are applied in order
about the z y and x axes in that order This is known as a 3-2-1
representation of Euler Angles [3] 12
24 GPS Satellite Constellation marking visible satellites in black from
the denoted position on the Earth in blue [4] 15
25 This is a block diagram showing the components and connections
within a GPS receiver The digital part is most often not fully imple-
mented in software The navigation processing and user interface are
typically done in software but the receiver channels and measurement
processing are often done in hardware [5] 18
26 This is a block diagram showing the components and connections in
the tracking loop of a GPS receiver This tracking loop implements
carrier phase tracking as well as code phase tracking [6] 19
v
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
27 Diagram showing Kalman filter update cycle In this diagram x
denotes the state estimate P is the error covariance matrix k is the
discrete time and y is a measurement The prediction step uses the
process model to propagate the states and covariances forward and
the update step uses the new measurement with the measurement
model to update the states and covariances [7] 29
28 Block diagram showing the data paths in a loosely coupled GNSSINS
navigation filter The GNSS receiver and IMU both operate indepen-
dently of each other simply feeding measurements into the navigation
system 31
29 Block diagram showing the data paths in a tightly coupled GNSSINS
navigation filter The navigation system receives pseudorange and
Doppler observables from the partial GNSS receiver and processes
them with the inertial measurements to produce a navigation solution
as well as corrections for the GNSS receiver to use in its tracking loops 32
31 The DRAGON and Scorpion systems were not linked to begin with
so Scorpionrsquos filter implementation framework was inaccessible from
DRAGONrsquos simulation tools Green blocks represent pieces of soft-
ware while blue blocks represent files 39
32 This diagram shows the message types and their analogous messages
that are consumed and produced by the converter tool developed as a
part of this thesis research Green blocks represent existing software
red blocks represent tools developed in this research and grey blocks
are messages 42
vi
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
33 Plots showing an in-progress result during development These plots
compare the received attitude solution data to the known truth data
This error was very odd 51
34 In-progress result during development Position plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 51
35 In-progress result during development Velocity plots showing the
received solutions and the known truth when the IMU orientation
was incorrect 52
36 The DRAGON and Scorpion systems are now linked with the conver-
sion tool developed for this research As before green blocks represent
pieces of software while blue blocks represent files The red block is
newly added 53
37 Block diagram showing the flow of data through the newly integrated
filter evaluation environment Scenario data can begin at either Scor-
pion or DRAGON and pass through the converter on the way to and
from Scorpion Results can then be analyzed with DRAGONrsquos anal-
ysis tools As before green blocks represent pieces of software while
blue blocks represent files The red block is newly added 54
41 This diagram explains the motion trajectory of the simulated vehicle
in Scenario A 58
42 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 60
43 The direct results received from Scorpion without any modifications 62
44 Attitude solutions Scorpion logged during execution of the EKF 63
vii
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
45 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error 64
46 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 65
47 Attitude solution plots for Scenario A using a tactical grade IMU 66
48 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 67
A1 In-progress result during development Attitude solutions from Scor-
pion after resolving the IMU orientation configuration error 74
A2 In-progress result during development Inverted attitude solutions
from Scorpion showing the erroneous spike in elevation and drop in
roll 75
A3 In-progress result during development Position plots showing mostly
correct data from the same test run as the incorrect attitude results 76
A4 In-progress result during development Velocity plots showing mostly
correct data from the same test run as the incorrect attitude results 77
A5 In-progress result during development Attitude plots showing the
solutions from Scorpion with the z axis of the IMU measurements
inverted The gaps in the solutions are times during which Scorpion
was not able to form a coherent solution and reset 78
A6 The raw IMU measurements being sent to Scorpion from the con-
verter This shows each axis independently 79
A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM output
formatting error in Scorpion 80
A8 Zoomed in attitude plot of solutions from Scorpion showing the jagged
time behavior in which samples showed up out of order 81
viii
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
A9 Zoomed in position plot of solutions from Scorpion showing the out
of order samples with the jagged errors in the solutions 82
A10 Position solution plots for Scenario A using an ideal IMU 83
A11 Velocity solution plots for Scenario A using an ideal IMU 84
A12 Attitude solution plots for Scenario A using an ideal IMU 85
A13 Position solution plots for Scenario B using an ideal IMU 86
A14 Velocity solution plots for Scenario B using an ideal IMU 87
A15 Attitude solution plots for Scenario B using an ideal IMU 88
A16 Position solution plots for Scenario C using an ideal IMU 89
A17 Velocity solution plots for Scenario C using an ideal IMU 90
A18 Attitude solution plots for Scenario C using an ideal IMU 91
A19 Position solution plots for Scenario A using a tactical grade IMU 92
A20 Velocity solution plots for Scenario A using a tactical grade IMU 93
A21 Attitude solution plots for Scenario A using a tactical grade IMU 94
A22 Position solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 95
A23 Velocity solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 96
A24 Attitude solution plots with no GPS measurements after 140 seconds
for Scenario A using a tactical grade IMU 97
ix
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
List of Tables
21 Grades of IMUs and their performance characteristics [8] 24
x
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
Acronyms
GPS Global Positioning System
INS Inertial Navigation System
IMU Inertial Measurement Unit
GNSS Global Navigation Satellite System
GLONASS Globalnaya Navigazionnaya Sputnikovaya Sistema
EU European Union
LEO Low Earth Orbit
MEO Medium Earth Orbit
SV Space Vehicle
PRN Pseudo-Random Noise
UTC Universal Coordinated Time
PNT Positioning Navigation and Timing
COTS Commercial Off The Shelf
AFIT Air Force Institute of Technology
xi
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
LCM Lightweight Communications and Marshalling
DRAGON Development Receiver Architecture for GNSS-Oriented Navigation
YAML Yet Another Markup Language
ECEF Earth Centered Earth Fixed
ECI Earth Centered Inertial
NED North East Down
ENU East North Up
DCM Direction Cosine Matrix
CTM Coordinate Transform Matrix
LLA Latitude Longitude and Altitude
ADC Analog to Digital Converter
DAC Digital to Analog Converter
FPGA Field Programmable Gate Array
KF Kalman Filter
EKF Extended Kalman Filter
UKF Unscented Kalman Filter
PF Particle Filter
RAIM Receiver Autonomous Integrity Monitoring
xii
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
[61] William J Klepczynski GPS for precise time and time interval measurementGlobal Positioning Systems Theory and Applications 2 1996
102
List of Figures
List of Tables
Introduction
Motivation
Current State of the Art
Thesis Contributions
Thesis Organization
Navigation Systems and Filtering Overview
Navigation Representations
Frames of Reference and Coordinates
Attitude Representations
Position and Motion Representations
Global Navigation Satellite Systems
GNSS Fundamentals
GNSS Receiver Functions
GNSS Navigation
Inertial Navigation Systems
Inertial Navigation
Fused Navigation
Properties and Benefits
Filtering and Estimation
Filters
Software Tools Utilized
DRAGON
Scorpion
Summary
Filter Analysis Environment
Introduction
Analysis Environment Architecture Implementation
Interface Design
Interface Implementation
Hurdles
Results
Chapter Summary
Filter Analysis
Introduction
Analysis Methodology
Results
Analysis
Chapter Summary
Conclusion
Future Work
Developmental and Result Plots
Bibliography
Chapter 1
Introduction
11 Motivation
Over the past few decades the United Statesrsquo Global Positioning System (GPS)
has garnered widespread use around the world and across many industries Initially
developed as a high precision positioning aid for the US military GPS has since
been opened to the public and become ingrained in the technology we use every
day GPS is used by the military the consumer industry the banking industry the
power grids the farming industry surveyors and academia [9] [10] This widespread
adoption and use has led to a complacency regarding the trustworthiness of the GPS
system which is not nearly as robust as it is generally considered [11]
There was a recent incident in which every ship in a region of the Black Sea
reported their GPS systems reporting a vastly different location than their true
position The cause is still unknown but there was certainly something malicious
going on as the validity of all satellite transmissions were verified [12] Another
example from 2013 is the spoofing of a yachtrsquos GPS receiver out at sea where GPS
is heavily relied upon due to the lack of landmarks A professor from The University
1
of Texas was able to intentionally and successfully spoof GPS signals to force the
GPS receiver on the ship to produce incorrect coordinates [13] An over-reliance on
GNSS can leave a system open to catastrophic failure
There are a number of vulnerabilities in GPS both to benign faults as well as
to malicious attacks [14] The satellite signals can be corrupted denied or spoofed
and one or many signals could be affected Countermeasures have been researched
that allow receivers to understand when their GPS signal may be compromised and
in some cases continue to navigate Among the countermeasures are a variety of
strategies Receiver Autonomous Integrity Monitoring (RAIM) looks for statistical
deviations between satellites being tracked in order to determine if one is incorrect
and unusable [15] and GNSS-INS Fused navigation uses an Inertial Measurement
Unit (IMU) with a GNSS receiver in order to provide backup functionality during
short GNSS outages [16]
These countermeasures are designed to operate automatically in a contested
environment but testing and tuning the real-world operation of such devices can be
tricky It is dangerous and illegal to broadcast GNSS signals outside of a controlled
and isolated environment and even if a test room is available there needs to be
an actual device to test There are Commercial Off-The-Shelf (COTS) receivers
which can run in real-time and be tested in such a way but they are usually black
boxes with no view of the internal operation and no way to modify the internal
algorithm in order to prototype any new designs This prompts the desire for an
open architecture with customizable internal algorithm implementations
As far as customization goes simulation is often the easiest way to test a new
algorithm Simulations also offer the benefit of being able to understand generalized
performance across a wide array of environments A common way of doing this is
with a Monte-Carlo simulation in which a scenario is tested many times (on the
2
order of 10000 runs) with random variables in the simulated environment The
results of all runs can be statistically analyzed together to obtain characteristics of
the device under test This kind of Monte-Carlo simulation can be run through real
hardware but all runs must then be done in real-time and sequentially (for each
instance of a device) making this kind of simulation very time consuming
In a full simulation approach many runs can be executed in parallel and can run
faster than real-time as long as the platform has enough resources Simulation also
allows all runs to be completely deterministic by modeling stochastic processes such
measurement noise in a deterministic manner To this end a sophisticated simula-
tion approach to the evaluation of navigation filter models should be developed to
address this need
12 Current State of the Art
Multi-sensor navigation filters are systems that combine sensor measurements from
multiple different sensors often including GNSS to produce estimates of certain
parameters associated with navigation These quantities often include but are not
limited to position velocity and attitude The Extended Kalman Filter (EKF) is
the most common navigation filtering and estimation algorithm and is the basis for
most sensor fusion applications Systems that use only GNSS may also make use
of an EKF to facilitate the propagation of estimates with a physical model of the
system in use
Countermeasures are typically integrated into the navigation filter used in the
system While simulation as a method of evaluation for filter designs is not un-
common the simulation system is often the means to the end rather than the end
itself [17] [18] Researchers use their own simulation systems to test the filter they
3
built so to replicate the results the simulation environment must also be replicated
The simulations yield performance information about the filter that the simulation
was built specifically for This does not always yield the most robust simulation
so a generalized simulation environment would benefit all researchers It would also
reduce the effort required to evaluate a new filter design
There are very few systems like this in the literature One example of an at-
tempt at a unified simulation environment is the NavLab software developed in [19]
by Kenneth Gade It is a post-processing simulation tool that generates measure-
ments and runs them through filters designed in MATLAB This is valuable to test
the theory behind a design but since it a post-processing application for testing a
prototype version of a filter it does not completely fill the space The author is not
aware of a test-bed that allows full control over development and robust testing of
multi-sensor navigation filter implementations
As far as sensor measurement synthesis a corporation has created a Development
Receiver Architecture for GNSS-Oriented Navigation (DRAGON) for the analysis
of primarily GNSS receivers DRAGON has capabilities to synthesize measurements
for other sensors as well such as barometric altimeters and varying grades of IMUs
in addition to GNSS receiver outputs when given motion trajectory scenarios This
system provides the ability to design a GNSS receiver in a modular manner and
have it run on real hardware to react to inputs fed into it The tool is suited for
extensibility it has interfaces to output data as well as take in data from external
processes These processes may asynchronously send signals back into the receiver
or to a separate navigation filter without affecting the efficiency of the receiver
DRAGONrsquos utility as a navigation measurement source is unmatched in real-time
prototyping
A tool developed by the Air Force Institute of Technology (AFIT) called Scorpion
4
can be used complementarily with DRAGON to enhance the filtering capabilities
Scorpion is a filter design tool intended to help students at AFIT get a feel for
developing parts of real complex navigation filters in a controlled system [20] The
system provides all the scaffolding and structure needed to design and run a naviga-
tion filter so the users are able to focus on the algorithms and sensor measurement
processors used to make the filter run properly and improve performance Conse-
quently Scorpion is always adding new filters to its capabilities which is valuable
for testing many approaches out of the box
Independently these tools are very useful for each of the tasks they have been
designed to assist with However considering that GPS receivers often leverage
navigation filters to improve their solutions and integrate integrity monitoring a
combination of these tools would be incredibly powerful for GNSS system developers
and any other researchers looking to quickly iterate on filter design with an accurate
GNSS simulation to test with This integration and filter analysis is precisely the
task performed for this thesis
13 Thesis Contributions
The main contributions to the body of public research that have resulted from this
thesis are as follows
bull Integration between a real-time measurement generation source and a filter
implementation tool This has never been done to such a degree to allow
complex filters to be prototyped running in a real-time simulation The high
fidelity of the testing environment will allow researchers and filter designers
to prototype and test their navigation filters and obtain highly relevant and
truly useful results
5
bull Analysis of an Extended Kalman Filter (EKF) under various scenarios using
this robust integration An EKF was be tested through the resulting system
to demonstrate the capabilities and robustness of the test environment This
analysis shows new ways to debug filter implementations not possible or not
nearly as easy without this tool
bull Insights into the intricacies of multi-sensor navigation filter testing Through-
out the thesis the details of multi-sensor navigation filters and their imple-
mentations are discussed There are very small changes that can cause almost
undetectable errors in performance in certain scenarios but can be catas-
trophic in others These are discussed as they are encountered
14 Thesis Organization
The remainder of the thesis is organized to be read sequentially Chapter 2 presents
all background information necessary to understand the work done for this thesis
This includes information on navigation representations the internal functioning of
a GNSS receiver navigation systems estimation and filtering and descriptions of
the specific technologies used for the research Chapter 3 describes the design and
implementation of the interface between DRAGON and Scorpion and some issues
encountered while implementing it Chapter 4 provides an analysis of an EKF using
the newly integrated testing tools It demonstrates the new capabilities gained in
the integration of DRAGON and Scorpion Finally Chapter 5 offers a summary
of the work done and its impact in the field of navigation and give suggestions for
future work to be done on the subject
6
Chapter 2
Navigation Systems and Filtering
Overview
This chapter provides an in-depth overview of GNSS- and INS-based navigation
techniques and the technologies used to implement and supplement them The
chapter begins with a discussion of navigation representations including units of
measurement and frames of reference in Section 21 The chapter continues with
a discussion of GNSS in Section 22 describing the fundamentals of GNSS how
receivers function and how navigation is achieved using satellite signals The sub-
sequent section Section 23 covers Inertial Navigation Systems their functioning
and their uses in the navigation world Bringing these together Section 24 dis-
cusses the fusion of satellite navigation systems and inertial navigation systems to
create more robust and accurate navigation systems Finally Section 25 provides
an overview of the specific tools used to complete the research done as a part of this
thesis
7
21 Navigation Representations
To discuss navigation with any precision mathematical representations of the rel-
evant quantities must be established The quantities discussed most often in this
report will be position velocity and attitude The frame of reference for these
quantities will also be of great importance throughout this report so they will be
described here initially
211 Frames of Reference and Coordinates
A coordinate frame is a reference origin point and defined axes with which to com-
pare other positions and motions [21] Positions and motions of an object are defined
relative to a fixed coordinate frame such that they have meaning other than simply
relative to themselves and their own past motion Coordinate frames are often se-
lected with meaning with the origin often at a landmark the center of an object or
the center of the Earth and with the axes aligned orthogonally to each other point-
ing along some natural axis such as the directions on the surface of the Earth the
rotation axis of the Earth or out of an object in the primary direction of travel [21]
The best coordinate frame to use is determined by the objective of system
One frame commonly used in navigation is the Earth Centered Earth Fixed
(ECEF) frame (depicted in Figure 21) In this frame the origin of the coordinates
is located at the center of the Earth and the x y and z axes come out from the
center through the equator at the IERS Reference Meridian (0 degrees) the equator
at 90 degrees east and the north pole of the Earthrsquos rotation axis respectively Since
the axes are defined with respect to physical features on the Earth the frame rotates
with the Earth hence ldquoEarth Fixedrdquo The ECEF frame is useful in navigation on
Earth because any point on Earth will always have the same coordinates in the
8
Figure 21 ECEF Frame with x y and z and Latitude and Longitude Note thatthe ellipsoid in the diagram is not the Earth itself but instead a generic ellipsoidthat has been specified to closely match the Earthrsquos surface [1]
ECEF frame regardless of any other factors [21] This is in contrast to the Earth
Centered Inertial (ECI) frame in which the origin is still located at the center of
the Earth and moved with it but the axes are defined relative to the stars in the
sky thus keeping the axes oriented in the same direction relative to the galaxy The
Earthrsquos rotation does not have an impact on the ECI frame at all
Local navigation frames are centered within the object or vehicle that is the focus
of a navigation system The axes are usually defined to be meaningful with respect
to the motion of the vehicle Most objects move along the surface of the Earth thus
several common coordinate axes are North-East-Down (NED) and East-North-Up
(ENU) This local navigation frame definition allows a user to navigate by repre-
senting their position orientation and motion relative to directions on the surface
of the Earth [22] A diagram depicting the relationship between the ECEF frame
9
and a sample local navigation frame using ENU coordinates is shown in Figure 22
Figure 22 East-North-Up local naviga-tion frame with respect to the ECEFframe at a particular position [2]
The final relevant frame is the lo-
cal body frame which is centered within
the body of the object that is the subject
of navigation This origin is the same
as the the origin of the local navigation
frame However the axes differ in the
local body frame Instead of being fixed
in terms of the cardinal and vertical di-
rections on Earth they are fixed to the
body of the object Commonly in what
is called a NED-like body frame the x
axis will point in the primary direction of motion the y axis will be level out the side
of the vehicle 90 degrees from the x axis and the z axis is defined as straight down
out of the vehicle in order to maintain the right-handed coordinate system [23]
These axes are only a very common example The only requirement for the axes in
a body frame is that they must be fixed to the structure of the vehicle
212 Attitude Representations
Once a coordinate frame is defined it is possible to begin discussion of the orientation
of the object or vehicle The orientation or attitude is the representation of the
direction the vehicle is facing Conventionally attitude is described as a rotation
from the navigation frame to the body frame or vice versa [24] Since the navigation
and body frames have the same origin transforming between them is only a rotation
and intuitively the orientation of a vehicle with respect to its surroundings on Earth
10
is going to be some rotation
This brings up the subject of rotation representations There are many ways
to describe a rotation One of the most common is the Tait-Bryan 3-2-1 Euler
Angle representation also known as roll-pitch-yaw or bank-elevation-heading In
this representation three rotations are applied to the frame sequentially beginning
with roll [21] By applying the three rotations sequentially any rotation may be
represented uniquely Figure 23 shows a rotation represented in 3-2-1 Euler angles
Applying the Euler angle rotations in the wrong order will result in an incorrect
attitude A drawback of Euler angles is that they suffer from gimbal lock wherein
certain orientations will eliminate the possibility of mathematically rotating any
more around one axis resulting in the loss of a degree of freedom [25]
Quaternions are often considered the ldquobestrdquo attitude representation for naviga-
tion due to their simplicity and mathematical properties A quaternion describes a
rotation as a vector with 4 components q = [q0 q1 q2 q3] [25] One of these values
is a scalar quantity and the other three are rotations whether the scalar component
is the first or the last in the vector depends on the implementation Since there are
four components quaternions exist in an under constrained space such that there
are two equivalent representations for each rotation in 3 dimensions [24] However
quaternions are generally regarded as unintuitive because their components do not
directly relate to any physical quantities [25]
Rotation Matrices are another robust method of describing rotations In 3 di-
mensional space a rotation matrix is a 3times3 orthogonal matrix that when multiplied
by a vector will rotate that vector Rotation matrices are also sometimes known
as Coordinate Transform Matrices (CTMs) and Direction Cosine Matrices (DCMs)
The relative ease of understanding rotation matrices makes them another popular
choice for attitude representation However rotation matrices are somewhat ineffi-
11
Figure 23 Euler angle representation in which the rotations are applied in orderabout the z y and x axes in that order This is known as a 3-2-1 representation ofEuler Angles [3]
cient in that they contain redundant information using 9 values to represent only
6 unique quantities They also require more calculations to propagate
Rotation matrices are useful as a midpoint in conversion between other attitude
representations and when an attitude needs to be transformed to another coordinate
frame [26] [27] Building the correct rotation matrix to convert between frames is
simply a matter of filling in the matrix elements based on Equation (21) In the
equation x y and z are the axes for the destination frame xprime yprime and zprime are the
12
axes for the origin frame and θst is the angle between the s and t axes [25]
R =
cos(θxprimex) cos(θxprimey) cos(θxprimez)
cos(θyprimex) cos(θyprimey) cos(θyprimez)
cos(θzprimex) cos(θzprimey) cos(θzprimez)
(21)
213 Position and Motion Representations
Representing the position of an object relative to a defined frame can simply be
done by describing the location of the objectrsquos body frame origin with respect to the
frame in which the position is desired or vise versa [21] Since this is effectively just
representing a point in three dimensional space any coordinate system will work
The geocentric ECEF and ECI frames represent points in Cartesian coordinates
(x y z) This is very consistent irrespective of location on Earth as there can be no
regional differences in representation
Latitude longitude and altitude (LLA) make up what is known as a geodetic
positioning system A diagram showing LLArsquos relationship to the ECEF frame is
shown in Figure 21 To define the system an ellipsoid roughly describing the shape
of the Earth is needed The World Geodetic System 1984 (WGS 84) defines such an
ellipsoid that is currently used by the GPS system and many other terrestrial navi-
gation systems The WGS 84 ellipsoid defines a frame of reference with origin axes
and an ellipsoidal surface representing the surface of the Earth [28] The ellipsoid is
defined with a number of constants such as the Earthrsquos semi-major axis flattening
factor and angular velocity The WGS 84 ellipsoid allows position to be represented
in the ellipsoidal coordinates LLA There are other Earth ellipsoid definitions that
are used by other systems which means LLA coordinates do not always represent
the same exact position For example GLONASS uses the PZ-90 (Parametry Zemli
The following section will detail the Global Navigation Satellite Systems that make
use of these representations
22 Global Navigation Satellite Systems
A system that provides the ability for users on a planet to locate themselves with
respect to that planet is called a navigation system When the system accomplishes
this by having satellites orbiting the planet for the users to reference it is a satellite
navigation system or a ldquosat-navrdquo system [30] A sat-nav system that provides a 3-D
positioning service to users all across the planet is referred to as a Global Navigation
Satellite System [21] There only three GNSSs active as of 2017 the US operated
GPS the Russian GLONASS and the European Union (EU)-run Galileo Galileo
is not fully operational yet and China has a system planned called Beidou that will
be deployed in the coming years
GPS became the first active GNSS in 1993 with the activation of the 24th satellite
in the system [31] GPS is operated today by the US Air Force and is always un-
dergoing improvement including recent and planned launches of new satellites with
increased capabilities The new satellites support many more waveforms allowing
higher precision positioning [32] The following sections will cover all necessary
information about GNSS needed to follow the research done for this thesis
221 GNSS Fundamentals
When the Soviet Union launched Sputnik US scientists were able to track its lo-
cation based on the pings it sent out They recorded the arrival time and Doppler
shift of the pings at multiple locations on the surface An effort then began to
14
reverse the calculation Allow a user to locate himself on the surface by doing cal-
culations based on the arrival times of signals sent by multiple satellites in orbit
around the Earth [31] The functionality of all modern GNSSs consist of the fol-
lowing operations A constellation of satellites orbit the planet in specific orbits
and specific timings and spacings from each other to ensure that enough are visible
from any point on the surface to properly navigate Each satellite broadcasts one
or more radio frequency signals that contains specific information that can be used
for positioning
Much of the discussion will refer only to the USrsquos GPS GLONASS and Galileo
follow largely the same principles of operation GPS is composed of 3 segments
the space segment the control segment and the user segment The space seg-
ment is composed of the satellites also known as Space Vehicles (SVs) The
control segment is composed of the monitoring equipment and team of engineers
who control the satellites and what they broadcast The user segment refers to
every GPS receiver that uses the system to determine its location andor time
Figure 24 GPS Satellite Constellationmarking visible satellites in black from thedenoted position on the Earth in blue [4]
In the space segment GPS SVs
orbit the Earth at an altitude of
roughly 20200 km in what is con-
sidered Medium Earth Orbit (MEO)
[21] The other GNSSs Galileo and
GLONASS also have their satellites po-
sitioned in MEO close to the GPS satel-
lites in altitude The GPS satellites are
arranged into 6 distinct orbits called
planes each with 4 satellites following
15
the same path spaced out throughout the orbital path (see Figure 24 [33] In
contrast Galileo and GLONASS both use only 3 planes with 8 satellites in each
plane [34] [35] Each SV is equipped with a power source multiple redundant high
precision atomic clocks small boosters for trajectory adjustments and an array of
antennas for transmitting and receiving The high precision clocks on-board are
critical for user equipment to be able to determine accurate ranges to the space
vehicles
The control segment is responsible for maintaining the systems that keep GPS
operating This includes keeping and publishing information on the status of the
space vehicles updating the information that the SVs broadcast and recording the
quality of service around the world [36] Monitor stations around the world listen to
the broadcasts from the satellites and forward the information to the central control
station The operators in the control station use the information from the monitor
stations to ensure the satellites are functioning correctly and track their movement
through space They predict each satellitersquos trajectory over the next 6 or so hours to
a very high degree of precision and represent this information in 16 constants related
to the Keplerian orbit equations [21] These constants are collectively referred to as
the ephemeris parameters and are what allows user receivers to know the precise
locations of the satellites they are listening to The control segment uploads the
ephemerides to the satellites through up-link stations which are also considered
part of the control segment
The final piece of a GNSS is the user segment which is composed of all the
receivers that use the signals broadcast out by the satellites Receivers are very
complex because they do all the processing to determine the location of the user
only listening to the GNSS signals and not transmitting anything [5] Devices in
the user segment are responsible for filtering out as much error as possible to find
16
its position solution The following subsection will go into more depth on GNSS
receiver functionality
222 GNSS Receiver Functions
GNSS receivers perform very intensive processing to track the satellites and produce
a position solution for the user Because of this they are almost always implemented
in hardware as software would not be able to keep up with the high rate of data
flowing through the system in real time Some software receivers have been imple-
mented but they are primarily for research and are not practical for commercial
use [37]
A block diagram showing the components of a GPS receiver can be seen in
Figure 25 Much of the analog circuitry is static and simply does some initial
processing on the received RF signal to move it to some intermediate frequency for
later processing removing the carrier frequency and leaving only the chipping code
and data message The true signal of any GNSS will be below the noise floor even
at this intermediate frequency meaning that environmental noise will have more
signal power than the signal itself [5] This makes detecting and decoding the signal
tricky
Once the signal has been put through the ADC the receiver has discrete digi-
tal samples to process At this point in the processing the samples are duplicated
and sent to multiple receiver channel blocks to extract the raw observables Each
receiver channel looks for a specific satellitersquos transmissions [5] There are 32 pos-
sible channels in the GPS framework so most GPS receivers will have 32 channel
processors The way the receiver is able to pull the signal out from below the noise
is with cross correlation The code signal transmitted by each satellite is a unique
pseduorandom sequence of 1s and 0s that has the property of having a very low
17
Figure 25 This is a block diagram showing the components and connections withina GPS receiver The digital part is most often not fully implemented in softwareThe navigation processing and user interface are typically done in software but thereceiver channels and measurement processing are often done in hardware [5]
autocorrelation when it is not perfectly aligned A receiver knows exactly the code
it expects to receive from each satellite but it does not know the phase offset It
therefore generates the code it expects and shift it in time cross correlating with
the received signal at each shift offset until it sees a peak This cross correlation
with the expected code is effectively an autocorrelation of the original transmitted
code which allows the receiver to determine the time offset It must also shift
the signal in frequency to determine the doppler shift of the received signal This
two-dimensional search for phase and frequency shift is known as acquisition [5]
Acquisition is an expensive process requiring many operations and consuming
much power To be able to decode the data modulated on the signal the receiver
needs to use a tracking loop to estimate and predict the time offset of future sam-
ples The tracking loop also allows the receiver to obtain the code phase of the
signal which can be used to improve position accuracy After acquiring the signal
18
of a satellite the receiver has a solution for the time and frequency offset of that
particular satellite In the future when it processes samples to track the satellite it
can use that information to predict the time and frequency offsets shortening the
process drastically The tracking loops use 3 ldquotapsrdquo denoted as ldquoearlyrdquo ldquopromptrdquo
and ldquolaterdquo where each tap is an offset to correlate with By looking at the correla-
tion values on these 3 taps the receiver can tell which way it needs to shift its notion
of the time offset to be most accurate A block diagram depicting this GPS receiver
tracking loop can be seen in Figure 26 With this tracking loop structure main-
taining knowledge of the offset of the signal is much more efficient than acquiring
every time a fix is desired [5]
Figure 26 This is a block diagram showing the components and connections inthe tracking loop of a GPS receiver This tracking loop implements carrier phasetracking as well as code phase tracking [6]
After a receiver has acquired the GNSS signal it is able to decode the informa-
tion that is modulated on it GPS signals modulate the date and time from their
clocks ephemeris data and almanac data over the chipping sequence [14] Demod-
19
ulating this information is done by first aligning the receiver generated code with
the received code and then checking the sign of the prompt tap The signal can
align properly yielding a correlation value of 1 or be 180 degrees out of phase when
the chipping sequence is inverted to encode data The data message is analyzed to
resolve the ambiguity and is typically corrected later in the receiver software This
information is how the receiver is able to get the transmission time at the satellite
and begin the calculations to determine its own time and location
223 GNSS Navigation
Once a receiver has acquired and begun tracking at least 4 GNSS satellites it is able
to solve the equations to determine position and time Four satellites are required
because there are four unknowns in the system 3 dimensions of position and time
error [5] With modern tracking loops and techniques such as carrier phase tracking
position error can be reduced to the order of 10 cm in optimal conditions [5]
Naturally conditions for GNSS to function are not always perfect Errors in
GNSS positioning can be induced by a wide array of variables Among the biggest
error sources are ionospheric distortion and multi-path errors but there are also
many other smaller errors that can compound [22] Some of these errors can be mit-
igated with smart processing For example ionospheric distortion can be measured
and the solutions offset by the correct amount if a receiver is able to track signals
at multiple frequencies [38]
The environment also plays a role in GNSS errors Receivers must have a roughly
direct line of sight to the satellites in the sky Since many fewer satellites are
visible and usable when a receiver has a high occlusion angle GNSS-derived position
solutions will be less accurate when the receiver is in a canyon urban or otherwise
[39] GNSS solutions are less accurate when the receiver is located inside a building
20
or or underneath a structure In such a scenario the sky is fully occluded from view
so a receiver will only be able to process multi-path reflections of signals Using the
reflections instead of a direct line-of-sight signal leads to very erratic behavior in the
location solutions
A number of external augmentations to GNSS to improve precision and worst
case performance exist Since they are typically locally based this section will focus
specifically on GPS as operated by the United States Differential GPS (DGPS) is
based on the principle that locations close to each other will observe many of the
same errors [40] In a DGPS system base stations at specifically surveyed locations
listen to the GPS satellite broadcasts and solve for errors in the pseudorange calcu-
lations They then broadcast out a correction to a local area (often within a range
of 50 km) Exact knowledge of the receiverrsquos location allow for determination of
errors common between locations including ionospheric distortion errors satellite
clock errors and satellite ephemeris errors [5] DGPS systems will not be able to
account for a receiverrsquos multi-path errors
GPS and all GNSSs are inherently external positioning aids The receiver only
passively listens to signals that it trusts are being broadcast out by satellites in
the sky The receiver must trust that the information it is getting is authentic and
correct if it can even hear the signal As mentioned earlier GPS is very susceptible
to jamming because of its low signal power on the surface of Earth There have been
efforts recently to demonstrate the fallibility of GNSSs Todd Humphreys at The
University of Texas at Austin was able to show that GNSS signals can be spoofed
very effectively with consumer grade hardware to mislead receivers [11] Since it
is becoming cheaper and easier to deny or otherwise impair GPS service other
methods of positioning must be investigated
21
23 Inertial Navigation Systems
Inertial Measurement Units (IMUs) record the motion of a system typically with
accelerometers and gyroscopes and sometimes with magnetometers The measure-
ments from these sensors when applied to kinematic equations describing their
relationships to real world motion can produce navigation solutions [41] These
systems are referred to as Inertial Navigation Systems (INSs) Since IMUs only
measure specific force (which includes inertial acceleration gravity and Coriolis
forces) and rotation using an INS alone yields acceleration from which velocity
and position changes can be derived However a nice feature of INSs is that they
produce solutions at a high frequency many IMUs generate measurements hundreds
of times per second allowing solutions to adjust quickly to changes in motion
231 Inertial Navigation
Fundamentally an IMU measures forces that create motion of an object Two
main forces associated with motion are gravity and inertia [42] An IMU produces
measurements of acceleration and rotation by measuring the gravity and inertia
acting on the object it is mounted to The quantities that can be estimated by
an INS being used with measurements from an IMU are position velocity and
attitude [8]
To obtain a navigation solution from the measurements of an IMU kinematic
equations are used From [42] Equation (115) states that the true acceleration P
equals the acceleration due to gravity g plus the specific acceleration S which can
be expressed as
P = g + S (22)
Accelerometers produce measurements of specific force so to determine the in-
22
ertial acceleration of an object the gravitational acceleration must be subtracted
from the specific acceleration To remove the gravitational component of acceler-
ation knowledge of the orientation and motion of the object is required This is
typically achieved through calibration before operation begins [42] Once the gravi-
tational component has been removed the following equations can be used to obtain
position p and velocity v
v =
intT
adt (23)
p =
intT
vdt =
intintT
adt (24)
Where the measurement period or time since the last measurement must also
be known in order to do the calculation It is denoted here as T
Gyroscopes (gyros) produce measurements of the rate of rotation over the mea-
surement period To obtain the discrete rotation value θ the rate of rotation ω
must be integrated over the measurement period as well
θ =
intT
ωdt (25)
All values must be calculated in all 3 dimensions for a complete position solution
in 3-D space Since the quantities that compose the navigation solution are acquired
through integration any errors in the original measurements will be amplified in the
solution [21] It is because of this that errors in unbounded INS solutions grow over
time
All IMUs have inherent errors in their operation which cause solutions based
solely on IMU measurements to diverge from the true solution over time [21] These
errors can generally be represented as a bias and noise but IMUs can also have scale
23
Table 21 Grades of IMUs and their performance characteristics [8]
IMU Grade Accelerometer Bias (mg) Gyro Angle Random Walk (degradichr)
factor and misalignment errors as well Bias is an offset in the measurements that
may vary slowly over long periods of time and thus is mostly consistent between
consecutive measurements Noise is a random offset that has no correlation to other
measurements taken around the same time The accuracy of the navigation solution
produced by an IMU relies heavily on the grade of the IMU with higher grade IMUs
yielding more accurate solutions over a longer period of time navigating solely with
the IMU Grades of IMUs are typically characterized as follows in Table 21 with
the errors listed Higher grade IMUs have much smaller biases leading to better
navigation over longer periods of time
An INS by itself cannot navigate because it has no absolute position from which
to calculate gravity and coriolis forces By fusing the solutions with a system that
does provide absolute position the INS can contribute to the solutions in an exter-
nal frame GNSS solutions often provide the position reference to an Earth centered
frame Furthermore magnetometers can provide an Earth centered frame for at-
titude In combining these sources of measurements a fused solution is created
Fused solutions will be discussed in more detail the following section
24 Fused Navigation
Since GNSS receivers have become commonplace over the past few decades nav-
igation system designers have begun considering GNSS as the primary source of
24
positioning information despite the lack of guarantee of service [15] As noted in the
GNSS section GNSSs are not invulnerable and the signals received from them can-
not always be heard or trusted As such more research focus lately has been put on
multi-sensor systems that incorporate an internal sensor that cannot be interfered
with via jamming or spoofing [43] The complement to GNSS in these systems is
typically INS due to widespread applicability compared to other technologies
241 Properties and Benefits
One of the primary benefits of using a fused system that draws on multiple data
sources is the diversity and independence of those information sources Through
effective filtering combining multiple data sources the weaknesses of individual data
sources may be mitigated If GNSS is unavailable for instance in the case the user
is in a building or underground an INS would allow the user to continue navigating
through the outage Most of the position error in an INS system comes from the
propagation of heading errors [16] Although the INS may drift due to gyroscope
imprecision and the fact that integrating errors worsens the solution over time it
will still navigate relatively well for a few minutes depending on the grade of the IMU
With the aid of a technique called Zero Velocity Updates where the IMU biases are
re-calibrated while the IMU is at rest errors may be somewhat bounded [44]
Inertial and GNSS solutions work together nicely to complement each otherrsquos
flaws GNSS is susceptible to external influences whether that be multi-path errors
jamming or spoofing When accompanied by an internally based data source such
as an IMU aberrations in the GNSS signal may be detected and adjusted for [45]
INSs have errors maintaining a link to an external frame of reference since they drift
over time but aiding with a GNSS can provide that fix to an Earth based frame A
GNSS will typically only generate solutions between 1 and 10 times per second but
25
an INS can provide solutions at every new IMU measurement often in the range of
100-300 times per second [45] This high rate from the IMU allows for much more
accurate and quick response to movements between GNSS solutions
242 Filtering and Estimation
The method used to incorporate multiple sources of data into one solution is filtering
Filtering is used in many capacities not only sensor measurement combination
Fundamentally a filter is an algorithm that is constantly estimating the state of an
object or system [46] The state of a system can also be described as a variable
or group of variables that fluctuate over time as a response to the dynamics of
the system [47] There are typically two steps involved in estimating a state the
prediction step and the measurement update In general the estimation algorithm
propagates the current state forward in time based on some physical dynamics model
of the system and some notion as to which parts of the state are the most trustworthy
in the prediction step [48] It is then able to incorporate a received measurement
using the systemrsquos measurement model
One of the most common estimation and filtering paradigms is the Kalman fil-
ter The estimation algorithm presented first in 1960 [49] is the base of many more
complex filtering techniques developed since At its core the Kalman filter is based
on a Bayesian model in which the true state of the system exists continuously but
is only observable through some set of measurements The measurements are influ-
enced by the state of the system but do not necessarily provide exact information
about the state [21] As each new measurement comes into the system it is pro-
cessed into the current state estimate with a weighted average The filter does not
need to store the history of all measurements to maintain its state instead it stores
a current state estimate and an error covariance matrix [21]
26
The state estimate x is a collection of states representing the system which
for navigation purposes often includes position velocity attitude and sometimes
several sensor measurement biases The error covariance matrix defined in Equation
(26) serves multiple purposes including representing the full state estimate error
distributions and storing the correlation between elements of the state It is the
expectation of the state estimate error squared namely
P = E((xminus x)(xminus x)T )
= E(δxδxT )
(26)
In addition to the state estimate and the error covariance matrix a Kalman filter
has a set of equations collectively called the system model or process model that
describe how the states in the state estimate propagate forward in time including
how the covariance errors grow between measurement updates [21] Equation (27)
shows how the state estimate is propagated through time with the system model
transition matrix Φ where k indicates time step and the minus and + superscripts
convey whether the state estimate is before or after the measurement has been
incorporated Equation (28) shows how the error covariance matrix propagates
which also depends on the system noise Q [21]
xminusk = Φkminus1x+kminus1 (27)
Pminusk = Φkminus1P+kminus1Φ
Tkminus1 +Qkminus1 (28)
The final piece of a Kalman filter is the measurement model which defines
how new measurement data should impact the state estimate the measurement
model is a set of equations derived from the physical dynamics of the system In
Equation (29) the measurement z is formulated to be incorporated into the filter
27
The measurement model is represented as a matrix H and measurement noise is
wmk [21]
zk = Hkxk + wmk (29)
With the new measurement the filter can be updated with a new state estimate
The equation used to update the state estimate is presented in Equation (210) K
is a weighting matrix known as the Kalman gain that is be determined later in
Equation (212) [21]
x+k = xminusk +Kk(zk minusHkxminusk )
= xminusk +Kkδzminusk
(210)
Finally the state error covariance is updated with the new measurement using
[21]
P+k = (I minusKkHk)Pminusk
= Pminusk minusKk(HkPminusk )
(211)
The Kalman gain Kk is calculated using [21]
Kk = Pminusk HTk (HkP
minusk H
Tk +Rk)minus1 (212)
where R is the expectation of the measurement noise squared
R = E(wmwTm) (213)
A diagram showing the steps to update the filter using these elements is shown
in Figure 27
The Kalman filter provides an optimal solution given the information available
for all linear systems with Gaussian measurement probabilities These requirements
are quite stringent however The primary limitation of Kalman filtering comes from
28
Figure 27 Diagram showing Kalman filter update cycle In this diagram x denotesthe state estimate P is the error covariance matrix k is the discrete time and y isa measurement The prediction step uses the process model to propagate the statesand covariances forward and the update step uses the new measurement with themeasurement model to update the states and covariances [7]
these assumptions and requirements in its definition namely that the measurements
be a Gaussian distribution about the true value the process model and measurement
model be linear and the noise is truly a zero mean random process [50] These
limitations are addressed in a number of extensions to the Kalman filter model In
some scenarios nonlinear state and measurement models may be modified slightly
with some assumptions to linearize them in what is known as a linearized Kalman
filter This process introduces new errors and assumptions into the system which
can be detrimental
A popular extension to the linearized Kalman filter is the Extended Kalman
Filter (EKF) which allows a nonlinear process model and measurement model to be
used by linearizing around the current state estimate using Taylor Series expansions
[21] Specifically EKFs replace the Φ and H with nonlinear functions of the state
estimate f(x) and h(x) In an EKF the state propagation becomes
xminusk = x+kminus1 + f(x+kminus1 tk)τs (214)
29
the measurement model becomes
z(t) = h(x(t) t) + wm(t) (215)
and the state update becomes
x+k = xminusk +Kk[zk minus h(xminusk tk)]
= xminusk +Kkδzminusk
(216)
EKFs are able to use the Kalman filter process for each term of the Taylor series
expansion Since many real world processes are nonlinear including even basic
navigation EKFs are used extremely widely Since the Taylor series expansion is
imprecise with only a few terms EKFs do not find optimal solutions like linear
Kalman filters do
An Unscented Kalman Filter (UKF) is similar to an extended Kalman filter but
instead of tracking the state space of the model it propagates a set of points in the
covariance space This is more accurate than an EKF for some systems that are
highly non-linear because the EKF linearizes equations at a loss The UKF uses the
original non-linear equations to propagate the sample points forward and computes
a new mean and covariance based on the result of the transformations [48] This is
highly processor intensive but in some scenarios much more accurate as well
243 Filters
In navigation the concept of a loosely coupled filter is one in which two sensors
or measurement sources each produce a solution of their own which are then com-
bined in a filter to produce a fused solution Loosely coupled filters are often used in
scenarios where the internals of the hardware are not accessible for instance when
30
combining two distinct sensors together in one system [51] This combination of in-
dependent sensor solutions can yield improved accuracy and reliability in the overall
solution Many navigation filters use this technique with inertial systems to improve
upon the base accuracy of the GPS solution produced by the receiver Figure 28
shows a block diagram of a simple GNSSINS loosely coupled filter
Figure 28 Block diagram showing the data paths in a loosely coupled GNSSINSnavigation filter The GNSS receiver and IMU both operate independently of eachother simply feeding measurements into the navigation system
Tightly coupled filters are complex filters that integrate components of different
sensors before a solution is computed Particularly GNSS observables including
pseudoranges Doppler shift and carrier phase measurements to satellites are inputs
to the tightly coupled filter as well as raw IMU measurements of acceleration and
rotation The calculations normally done in the GPS receiver to determine the
position from the pseudoranges is instead calculated by the filterrsquos dynamics model
[44] A tightly coupled filter is typically implemented as an INS filter that has
the structure to process pseudorange measurements as well to bound the position
solution and to some extent the velocity solution [52] A block diagram depicting an
example of a GNSSINS tightly coupled navigation filter can be found in Figure 29
The implementation of tightly coupled filters is not common in consumer technology
because of the high complexity of the filter design and relative lack of performance
gain for most consumer purposes However there is a wealth of research in the public
31
literature and in government applications [18]
Figure 29 Block diagram showing the data paths in a tightly coupled GNSSINSnavigation filter The navigation system receives pseudorange and Doppler observ-ables from the partial GNSS receiver and processes them with the inertial measure-ments to produce a navigation solution as well as corrections for the GNSS receiverto use in its tracking loops
25 Software Tools Utilized
To complete this thesis some existing tools were used to build upon The DRAGON
tool and AFITrsquos Scorpion were integral to the completion of this work DRAGON
was responsible for generation of all measurements with accurate representations
of biases and many different types of noise added to the generated signals Scorpion
is the filter design and prototyping tool that allows navigation engineers to test
their filters in real time The following subsections provide the relevant background
information on each piece of software
251 DRAGON
The DRAGON tool is a technology developed by a corporation to enable research
and development of GNSS technologies While the primary function of DRAGON
is to operate as a receiver processing GNSS signals sent by satellite constellations
32
it has two other important features used in this research it can play back satellite
transmissions determined by time and motion of a simulated receiver and it is able to
generate simulated inertial measurements corresponding to the simulation scenario
More work has been done recently to enable DRAGON to simulate other sensors
as well including barometric altimeters and even some camera images for visual
navigation With the modularized GNSS receiver implementation and simulation
capabilities DRAGON is a very capable measurement source DRAGON is able to
run in real time through portability of its implementation to a Xilinx Zynq FPGA
which provides the hardware acceleration to run a full GNSS receiver in real time
To allow access to the data flowing through DRAGON a utility called the event
proxy was developed DRAGON uses a publish-subscribe middleware framework to
facilitate communication between all the components of the system Since the GNSS
receiver is modularized all components of it are separate processes in the DRAGON
system and each component consumes messages (also known as events) from other
processes and transmits new messages with updated information This architecture
allows for a listening process to subscribe to broadcasts from any element in the
system
The event proxy does just this listening for any event types it is specified to
listen for and forwarding them over a TCP connection to whatever process is using
the event proxy This external process may run on the same machine or a different
machine since the connection is over TCP A process using the event proxy creates
callback functions for events which are run whenever an event of a particular type
is received As an example DRAGON includes a utility called the network logger
that uses the event proxy to listen to all events in the system and log them to files
Having this utility separate from the operation of the system is a great feature for
debugging as it allows monitoring without interference Another possibility with the
33
network logger is running a scenario on an FPGA and logging data to an external
computer
In addition to DRAGONrsquos GNSS receiver simulation it also has a very high
quality and highly tunable IMU model that allows it to generate statistically accu-
rate IMU measurements from a motion profile The motion profiles are created to
specify a starting location date and time and subsequent time and location pairs
Software within DRAGON fits polynomial splines to the motion profile to interpo-
late between the samples and derives velocity and acceleration measurements from
the splines The canonical model of an IMU is then used to simulate biases and noise
that impact the measurements generated by the device [53] This model is tunable
to different grades of IMU (see Table 21) which is very useful for analyses to de-
termine how high-quality an IMU must be to achieve certain goals DRAGON does
have the capability to process its measurements in a real-time filter implementation
but extending the capability to Scorpionrsquos existing and future library of filters will
continually add value as new filters are designed and added to Scorpion
Finally DRAGON includes many utilities and tools for analysis of the simula-
tions The network logger records every event in the system to a series of binary
files There is then a suite of MATLAB tools designed to read and analyze those
log files Many of the tools are for plotting and analyzing the functionality of GNSS
receivers but there are also many to compare PNT solutions with truth and visu-
alize the data being produced by specific event types These analysis tools are very
valuable for evaluating and debugging navigation solutions
252 Scorpion
Scorpion is a framework for the implementation of Bayesian estimation filters typ-
ically used in navigation contexts [20] It is actively developed by the Autonomy
34
and Navigation Technology Center at AFIT as a tool to aid in the education of stu-
dents studying navigation systems Given its use as a teaching tool the project has
amassed a very diverse body of work in the form of sensor processing modules state
representations mechanization equations and other pieces of the internal workings
of a navigation filter This makes it a unique resource by virtue of its extensibility
but also by the work already done and included with the framework
Scorpion itself is comprised of the core modules that can be pieced together
to form a filter Any implementation of a filter using Scorpion can choose which
modules to use in its filter design This is everything from the core filter concept (eg
EKF UKF PF) to the internal state representation to the sensors connected as
inputs to the system and the transport layer mechanism to facilitate the movement
of measurements and solutions into and out from the system
Scorpion includes a wrapper interface that receives messages over the Lightweight
Communications and Marshalling (LCM) protocol [54] and passes the messages into
its core filter To send or receive messages through the LCM protocol an application
must create an instance of the LCM operational piece Scorpion uses messages
defined by the All Source Positioning and Navigation (ASPN) specification which
are different from the custom messages defined by DRAGONrsquos messaging system
LCM and ASPN are third party standards and are not specific to Scorpion
The internal state model used in the EKF used for this research is the 15 state
Pinson model (Pinson 15) The Pinson model is an error model that keeps track
of the estimates of errors from the measurements rather than the estimates of the
state itself In the Pinson 15 model the states include 3 values for position one for
each axis in whichever coordinate frame is used in this case NED Also included
are 3 states for velocity and 3 states for acceleration The final 6 states are for
estimating the accelerometer and gyroscope errors when using an IMU Keeping
35
track of the IMU errors as a component of the state is an effective way to improve
the performance of the system IMU errors can be estimated because they can be
modeled
Scorpion also has built in support for other sensor types including camera sensors
for vision based navigation It also has extensibility to allow developers to add their
own sensors as inputs to the system by defining the information format and the
mechanization equations that relate those measurements to the internal state of
the filter A robust way to test the filters developed in Scorpion is outside the
scope of the project however Currently the most common method of testing is by
replaying recordings of test sessions during which data was collected This could
most definitely be improved upon
26 Summary
Much of the material presented in this chapter will be valuable in understanding the
functionality and impact of the work done for this thesis Understanding coordinate
frames and position and attitude representations is essential when talking about
navigation systems Likewise navigation systems reside as the base upon which
everything discussed is built Filtering and state estimation are powerful tools to
achieve the end of a navigation system Kalman filtering and its derivatives are able
to consume measurements from multiple sensors and with some knowledge of the
physical system in which they reside determine how trustworthy the measurements
are and find the most optimal solution The most prevalent measurement source
for use in navigation systems is the GNSS receiver which uses transmissions from
satellites to locate itself in space and time Finally DRAGON is a GNSS receiver
simulator and general measurement source and Scorpion is a filter implementation
36
framework that can be leveraged to design and implement any Bayesian filter in a
real-time data-streaming environment
37
Chapter 3
Filter Analysis Environment
The first major contribution to the field of research produced for this thesis project
is the creation of a high fidelity navigation filter analysis environment Leveraging
the GNSS receiver simulation tool and the Scorpion filter design tool a comprehen-
sive evaluation framework was constructed The following sections will detail the
implementation challenges and results obtained throughout the process
31 Introduction
The research performed for this thesis was roughly separated into two pieces The
first piece of the research involved studying the DRAGON tool and AFITrsquos Scor-
pion filter construction tool designing an interface between the two and actually
implementing that interface Once the interface was in place the second piece of
the research was to demonstrate the capabilities of the combined system by doing
some filter analyses Hurdles were encountered and overcome throughout both parts
of the research This chapter will describe the integration task and the following
chapter will cover the analysis done to demonstrate the functionality of the com-
bined system In the development of the filter analysis environment the work can
38
be split roughly into interface design and interface implementation with the im-
plementation section being further divided into work moving data from DRAGON
to Scorpion and vice versa
32 Analysis Environment Architecture Implemen-
tation
Starting out at the beginning of the year the goal of this project was to integrate
the GNSS receiver simulation and testing tool with AFITrsquos navigation filter design
and implementation tool called Scorpion Subsequently there would be an analysis
of some existing filters provided through Scorpion using DRAGON to demonstrate
the functionality and usefulness of the integration To approach this a deep under-
standing of the two technologies was required to be able to architect the interface
between the tools Figure 31 shows the components of each system and the fact
that they are not able to interact
Figure 31 The DRAGON and Scorpion systems were not linked to begin with soScorpionrsquos filter implementation framework was inaccessible from DRAGONrsquos sim-ulation tools Green blocks represent pieces of software while blue blocks representfiles
After studying both tools some similarities and some differences were noted
39
Each tool used its own standards and set of classes to define the structures holding
data as it flowed throughout the systems and each technologyrsquos software was in
different programming languages DRAGON in C++ and Python and Scorpion in
Kotlin Fundamentally however the quantities used in both tools represented the
same functional pieces and both tools included some network interface however
different
321 Interface Design
Through discussions some options were discussed on how best to structure the inter-
face Some high level approaches discussed were the creation of a fully standalone
application that interfaces with both tools ferrying information back and forth ad-
ditional components added onto both DRAGON and Scorpion and an additional
component added onto just one of the tools The benefits and drawbacks of each
are discussed in the following paragraphs
The creation of a standalone tool has the benefit of not needing to modify either
preexisting tool This is generally a good thing because modifying the existing
tools risks breaking some other functionality within them A separate tool will not
interfere with the functionality of either existing tool and if each tool is being run
standalone this application will not have any impact on its operation Such an
application could also be written in any range of programming languages However
a separate tool may not have access to all data easily and may introduce delays in
the transmission of the data It would also need to be run separately which may be
a hassle and could complicate the process introducing more points for failure
Components integrated into both tools would have a few advantages First it
would allow the tools to be run as-is without running an additional application Sec-
ondly having pieces on both sides would mean a single standard interface between
40
the tools could be adopted potentially allowing them to use the interface for future
integrations with other tools However a drawback of this approach is potentially
slowing the operation of both tools Integrated components would also necessitate
writing the components in the programming languages used by the tools Also a
specification must be maintained somewhere for the interface between the tools and
if one is changed the other must also be changed
The final option discussed was adding a component to one of the tools to facilitate
the interface with the other This has the benefits of maintaining all logic in one
place and not needing to run a separate tool It would also limit the connection
between tools to one interface instead of two which would likely result in a lower
transmission time than having two interfaces However one tool would still need to
be modified which could impact its performance The tool would also need to be
written in the language used by whichever tool it is integrated into
Since both DRAGON and Scorpion are designed to perform their operations in
real time or faster they are optimized for performance and speed and any additions
to the core functionality of them would need a lot of optimization and verification
before it could be used Therefore interfering with the existing functionality as
little as possible was an important requirement This reasoning drove the decision
to build a separate application to facilitate the transfer of information between the
two tools
The choice to make a fully separate application was also partially motivated by
the fact that the DRAGON has an existing library the event proxy for interacting
with the receiver over a TCP interface The Event Proxy plugs into the publish-
subscribe network of the receiver and forwards specified message types over TCP
to the application using it It is also able to publish events back into the receiver
network From a technical standpoint a user application creates an instance of an
41
Event Proxy and points it at the address and port the receiver is accessible on
The application can then define custom callback functions to be run whenever a
certain type of event arrives Since the new interface application will be creating an
instance of the DRAGON toolrsquos Event Proxy it will be much closer to DRAGON
than Scorpion As such the code base will reside with the rest of the DRAGON
software
322 Interface Implementation
As a starting point for the interface application DRAGON has a network logger
utility that utilizes the Event Proxy to log events within the receiver without im-
pacting the runtime performance of the receiver The network logger contained a
useful framework for interacting with the Event Proxy and the simulated receiver
through it Building up from this framework the interface application inherited
command line argument management an event response factory framework and
an event-driven multi-threaded main operation flow Figure 32 shows the message
types that are consumed and produced by the new converter tool and the mes-
sage types that map to each other Each message type and the transformations
performed on it will be described in this section
Figure 32 This diagram shows the message types and their analogous messagesthat are consumed and produced by the converter tool developed as a part of thisthesis research Green blocks represent existing software red blocks represent toolsdeveloped in this research and grey blocks are messages
42
Each event typersquos callback function must be independently implemented so the
application was configured to handle IMU events and PNT solution events The
IMU events are generated every time an IMU publishes data and contains the ac-
celerometer and gyro measurements produced by the IMU as well as some meta-
data regarding the number and orientation of the sensors in the IMU PNT solution
events contain position velocity time covariance and sometimes attitude They
are much more general and can be generated by a number of sources In DRAGON
PNT events can be generated by the GNSS receiver the truth source (if it exists)
and the inertial navigation system DRAGON also creates and uses observation
events that contain GNSS observable quantities like Doppler shift and carrier phase
measurements that can be processed in a tightly coupled filter
The ASPN events are defined by a set of YAML files maintained by AFIT Tools
are run automatically to generate class definitions in Python and Kotlin for LCM
messages matching the ASPN definitions Since the DRAGON event proxy already
uses Python it made sense to use the Python implementations of the ASPN LCM
messages The ASPN IMU message is defined as having 3 gyros and 3 accelerome-
ters aligned orthogonally The 3D geodetic position message is defined by latitude
longitude and altitude and has a 3times 3 covariance associated with it The position
velocity attitude message contains a geodetic position a 3 dimensional velocity in
the NED frame and an attitude represented by 3-2-1 Euler angles with respect to
the NED frame It also contains a 9 times 9 covariance matrix Finally the GNSS
message allows for pseudoranges Doppler shifts and carrier phase measurements to
be provided
In creating the interface to translate the events from DRAGONrsquos format to the
ASPN standard used by Scorpion the units and reference frames needed to be
checked and converted if necessary The ASPN standard is somewhat more limited
43
with regards to the flexibility of messages in the system For instance the IMU
messagersquos requirement of 3 gyros and 3 accelerometers in an orthogonal configuration
is of course the most common IMU configuration but it is not necessarily the only
one Some land vehicles will eschew the up axis accelerometer as it does not give
much information when traveling on flat ground Since DRAGONrsquos IMU messages
support any number of axes and orientations of the axes the converter must check
to see if the format is compatible The converter tool rejects any messages that do
not comply with the ASPN standard This is reasonable because the DRAGON
tool will be running a simulation that can be specifically configured to match the
ASPN definition of an IMU
The DRAGON specification for IMU messages happens to use the same units
as the ASPN standard ms2 for accelerometer measurements and rads for gyro
measurements so no unit conversion was necessary Once the axis configuration is
verified the converter packages up the measurements into an LCM IMU message and
broadcasts it on a sensor-specific channel The message also contains time-stamps
and meta-data about the sensor that generated the message
For PNT events the converter first checks the type of the PNT solution and if
it is a GNSS solution it proceeds to format and send it Truth inertial and fused
solutions are unused in this implementation because the focus is on integrating
GNSS measurements with raw inertial sensor measurements So once an event is
determined to be a GNSS PNT event the position and velocity are extracted from
the event data and transformed to match the ASPN standard For position this
means transforming the coordinates from the ECEF position used by DRAGON to
LLA as required for ASPNrsquos geodetic position message This conversion is handled
by DRAGON which includes both LLA position and ECEF position in its PNT
message although the position covariance is only provided with respect to ECEF
44
Velocity measurements are also produced as part of the PNT event by the GNSS
receiver from the Doppler shift to the satellites However Scorpion does not yet sup-
port a message that contains associated position and velocities without an attitude
Because of this the converter must reformat the GNSS PNT events into basic geode-
tic position LCM messages and drop the velocity measurements This is somewhat
detrimental to the navigation solution because the velocity measurements usually
contain much less noise than the position measurements due to the fact that they
are derived from the doppler shift of the carrier signal (as opposed to the phase of
the code signal for position)
Finally the covariances associated with the measurements must be converted to
match the new reference frame being sent to Scorpion First the position subsection
of the covariance matrix provided by the PNT event was extracted Then an ECEF
to NED DCM is generated with Equation (21) using the position measurement as
the origin for the local NED frame This DCM P is then applied to the covari-
ance matrix C with the formula PCPminus1 The resultant matrix is the position
covariance matrix with respect to the NED reference frame rather than the original
ECEF frame With the position in LLA and the position covariance in terms of
NED the 3D geodetic position LCM message was filled out and broadcast out for
Scorpion to consume
Although not fully implemented in this research it is possible with this frame-
work to have DRAGONrsquos observation events converted into ASPN GNSS messages
This would enable Scorpion to run a tightly coupled filter using the raw observations
from the GNSS receiver and the inertial measurements In future use of this system
the ability to easily add new message conversions and have everything seamlessly
send to Scorpion will allow expansion for much more complex filters to be designed
in the future
45
The last message implemented was the live configuration messages This allows
Scorpion to be configured to accept certain message types with specific initial con-
ditions over the wire without manually setting it in the main code used by Scorpion
Although Scorpion does not yet fully support this protocol it should in the near fu-
ture The ability to configure Scorpion in a live setting lowers the bar for the initial
amount of work that must be done to get the systems working together This will
be a great quality of life improvement once Scorpion fully supports the standard
Scorpion to DRAGON
After processing the measurements with its filter Scorpion generates a naviga-
tion solution containing position velocity and attitude The navigation solution
is broadcast on the same LCM bus that the converter is already connected to in
order to send measurements into Scorpion so the converter can listen for these solu-
tions from Scorpion Scorpionrsquos solutions are formatted as ASPN position velocity
attitude messages as described above
The conversion tool sets up and registers a callback method to handle any in-
coming LCM messages on Scorpionrsquos solution channel This callback method runs
whenever a solution message arrives It extracts the time position velocity at-
titude and covariance and reformats them into a DRAGON PNT event which
supports all of those fields The time is converted from seconds output by Scor-
pion to baseband time in samples as used by DRAGON This is simply a scaling by
the sampling rate The position is again formatted as LLA and must be converted
to ECEF which is done using Equations (31) through (33) which is derived from
the Mathworks documentation at [55] The symbols micro ı h λs R f and rs rep-
resent latitude longitude height mean sea-level the equatorial radius flattening
46
and radius at the point The position p is the point in ECEF coordinates
λs = atan((1minus f)2tan(micro)) (31)
rs =
radicR2
1 + (1(1minus f)2 minus 1)sin2(λs)(32)
p =
px
py
pz
=
rscos(λs)cos(ı) + hcos(micro)cos(ı)
rscos(λs)sin(ı) + hcos(micro)sin(ı)
rssin(λs) + hsin(micro)
(33)
The velocity in NED is converted to ECEF using equations derived from Equa-
tion (34) which is from Equation (2152) by Groves [21] It says the earth based
velocity in the earth frame veeb is obtained by multiplying the coordinate transform
matrix from the local navigation frame Cen by the earth based velocity in the nav-
igation frame vneb The coordinate transform matrix is defined as follows where L
is latitude and λ is longitude
veeb = Cenv
neb (34)
Cen =
minussin(L)cos(λ) minussin(λ) minuscos(L)cos(λ)
minussin(L)sin(λ) cos(λ) minuscos(L)sin(λ)
cos(L) 0 minussin(L)
(35)
Attitude is a rotation which is represented by Scorpion as 3-2-1 Euler angles
known as roll pitch and yaw DRAGON uses quaternions to represent its angles
so the Euler angle representations are converted to quaternions using Equation (36)
from [56] In these equations q4 is the scalar component of the quaternion and θ1
47
θ2 θ3 are roll pitch and yaw respectively
q =
q1
q2
q3
q4
=
cos(12θ1)cos(
12θ2)cos(
12θ3)minus sin(1
2θ1)sin(1
2θ2)sin(1
2θ3)
cos(12θ1)sin(1
2θ2)sin(1
2θ3) + sin(1
2θ1)cos(
12θ2)cos(
12θ3)
cos(12θ1)sin(1
2θ2)cos(
12θ3)minus sin(1
2θ1)cos(
12θ2)sin(1
2θ3)
cos(12θ1)cos(
12θ2)sin(1
2θ3) + sin(1
2θ1)sin(1
2θ2)cos(
12θ3)
(36)
Converting the raw measurements is fairly straightforward for each of them but
converting the 9 times 9 covariance matrix is a bit messier Each 3 times 3 sub-matrix
along the diagonal needs to be transformed independently to match the conversions
done to the raw quantity but the rows and columns that run through that section
also need to be transformed The converter tool accomplishes this by building a
transformation matrix and multiplying it by the incoming covariance matrix The
transformation matrix is constructed as is seen in Equation (37) For position
an ECEF to NED DCM is generated (using Equation (21)) and transposed to
invert it making it an NED to ECEF DCM Velocity uses the exact same NED to
ECEF DCM The attitude section of the transformation matrix is actually in the
same configuration so that section of the transformation matrix is simply a 3 times 3
identity matrix To apply the transformation matrix to the covariance we apply
the following
T ecefned =
P ecefned 03times3 03times3
03times3 V ecefned 03times3
03times3 03times3 I3
(37)
Cecef = TCnedTminus1 (38)
After this large covariance matrix is generated all the fields of the PNT event
are populated and the event is published back into the DRAGON system via the
48
event proxy Since the event passes back through the event proxy a simultaneously
operating instance of the network logger will be able to record DRAGON events as
well as the navigation solutions from Scorpion
323 Hurdles
Along the way to a functional converter several hurdles were encountered During
the implementation of the chosen design it came to light that there were a number
of ASPN message types that could transport the same information For example
there is an IMU message containing gyroscope and accelerometer measurements but
there were also messages for individual gyroscopes and accelerometers There is no
one correct way to map the messages together but the mapping must be reflected
in the sensor processing in Scorpion The final mapping was chosen to be least
ambiguous and generate few redundant or unnecessary messages It can also be
seen that PNT events in DRAGON map to two different ASPN messages because
of the inclusion of an attitude measurement in the Scorpion solution compared to
the GNSS solution
Another issue run into was one of time-stamps The ASPN messages used by
Scorpion specified two time-stamp fields time arrived and time valid with little
description differentiating the two When the solution returned to DRAGON the
converter initially used the time arrived value to generate the baseband time for
the PNT event but it was yielding an odd issue where there was an offset in the
solution time from the baseband time sent into Scorpion The offset started out
as roughly the UTC time-stamp in seconds but it did not stay the same over
the course of the simulation After some investigation it was determined that
the time valid value should be used instead to generate the baseband counter
value It was suspected that the time arrived value was a UTC tag for when the
49
measurement was received by the CP on the machine running the simulation likely
for logging purposes
Like many issues that come up when interfacing multiple tools together con-
figuration synchronization needs to be verified to ensure that the tools have the
same view of the data Creating the conversion tool for this interface the attitude
showed an odd error where the motion seemed to be following the correct pattern
but the heading and bank angles were offset by 180 degrees and the bank angle was
also inverted In addition there is an odd segment on the elevation angle that is
incorrect even with the manual ldquocorrectionsrdquo
This situation can be seen in the plots in Figure 33 The position and velocity
solutions looked fine compared to the attitude as can be seen in Figures 34 and 35
The issue was eventually tracked down to a configuration file within Scorpion setting
the default IMU orientation to a non-standard orientation Whereas the orientation
configuration should have been a 1 to 1 mapping of the axes from DRAGON to
Scorpion the configuration file instead specified the x and z axes to be inverted
The errors made sense in retrospect because bank angle is a function of the x axis
(pointing out the nose) and the heading angle is a function of the z axis (vertical
axis)
This was a very subtle error that could have had many sources The initial
investigation led to transposing the attitude rotation matrix in an attempt to check
if Scorpion was representing its attitude as a rotation from the body to navigation
frame instead of the traditional navigation to body frame Yet it was simply a
misconfiguration of the sensor alignment and lever arm The lessons learned from
this debugging process can be applied to all software projects It can help ease
debugging to keep all configuration centrally located and document all configuration
options and their effects
50
Figure 33 Plots showing an in-progress result during development These plotscompare the received attitude solution data to the known truth data This errorwas very odd
Figure 34 In-progress result during development Position plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
51
Figure 35 In-progress result during development Velocity plots showing the re-ceived solutions and the known truth when the IMU orientation was incorrect
52
33 Results
The interface between DRAGON and Scorpion was completed and the systems
successfully linked The converter tool allows data to be sent from DRAGON to
Scorpion by reformatting events from the DRAGON system into LCM messages
defined by the ASPN standard The implementation allows easy expansion of the
system to include more message types in the future
Figure 36 shows the newly connected DRAGON and Scorpion systems Through
the new converter interface DRAGONrsquos simulations can be processed using a filter
in Scorpion and any navigation solutions generated by Scorpion can be transported
into DRAGON for study with DRAGONrsquos existing MATLAB analysis tools
Figure 36 The DRAGON and Scorpion systems are now linked with the conversiontool developed for this research As before green blocks represent pieces of softwarewhile blue blocks represent files The red block is newly added
An example of the data flow through the new filter analysis environment when
running with either a DRAGON simulation data or a live recording from Scorpion
can be seen in Figure 37 This shows the ability to ferry data back and forth
between DRAGON and Scorpion to facilitate the operation of a navigation filter
DRAGON can act as a high fidelity sensor measurement source with simulation
scenarios or with real recordings The event proxy forwards the relevant events
53
to the conversion tool which transforms and reformats them into LCM messages
that have been defined to match the ASPN standard The conversion tool then
broadcasts the LCM messages which Scorpion receives and feeds into its internal
filter The filter produces navigation solutions and broadcasts them back over the
LCM bus The converter tool receives the navigation solutions and again transforms
and reformats them into PNT events for DRAGON and publishes them back to the
event proxy From there the network logger records all the events to files which
can then be analyzed in MATLAB
Figure 37 Block diagram showing the flow of data through the newly integrated fil-ter evaluation environment Scenario data can begin at either Scorpion or DRAGONand pass through the converter on the way to and from Scorpion Results can thenbe analyzed with DRAGONrsquos analysis tools As before green blocks represent piecesof software while blue blocks represent files The red block is newly added
34 Chapter Summary
The development of the filter analysis environment as described in this chapter was
a long journey through many standards documents interface design documentation
raw code and configuration files The initial design discussions resulted in a plan to
54
create a standalone tool to connect to each of DRAGON and Scorpion independently
in order to interfere with their operation as little as possible The implementation
of the interface involved many coordinate transforms and angle rotations to convert
the quantities used in DRAGON to a format Scorpion could understand and vice
versa Issues encountered throughout the process were also described and finally
the flow of data through the completed filter analysis environment was described
55
Chapter 4
Filter Analysis
The second major contribution to the field of research produced for this thesis project
is the analysis of an EKF using the newly constructed filter analysis environment as
described in Chapter 3 This analysis will demonstrate the functionality and utility
of the environment developed in the first part of this research
41 Introduction
The work described in the following sections acts as a follow-up on the development
done to create the analysis environment in the previous chapter A loosely cou-
pled implementation of an EKF that takes in GNSS and IMU measurements will
be evaluated to demonstrate the use of the analysis environment The filter from
Scorpion is a pre-built one that the developers at AFIT use to test their system
Testing of the EKF has been limited to testing against prerecorded data without the
integration with DRAGON and its analysis tools With the new integration some
bugs were discovered while evaluating the EKF for fused GNSS and INS navigation
56
42 Analysis Methodology
For this analysis the testing procedure described in Figure 37 was applied with the
simulations starting from DRAGON Multiple simulation scenarios were run and
all relevant runs were from DRAGON because the log files Scorpion uses to run its
system do not have truth data and thus cannot be used to verify the accuracy of the
filter beyond simply watching the large scale motion of the navigation solution This
is also the reason that some bugs were not discovered by the AFIT team working
on Scorpion prior to this analysis being conducted
The initial testing scenarios were driven by a requirement of Scorpion that the
data start with a period of stationary recording or simulation in order to get align-
ment The way this worked was that initially samples going into Scorpion would
be passed to an aligning filter that used static gyro-compassing to detect the atti-
tude of the sensor frame which is generally aligned with the body frame To do
this gyro-compassing Scorpion required a position solution typically from a GNSS
receiver and gyroscope measurements from a tactical grade or better IMU It uses
the position and very slight angles changes over about 30 to 60 seconds to detect
the rotation of the Earth and determine the orientation of the sensor frame Once
the orientation is obtained the internals of the Scorpion system perform a hand-off
from the aligning filter to the navigation EKF
A test scenario was developed specifically for the purpose of testing this and other
systems that require periods of stationarity at the beginning of the simulation This
scenario will be referred to as Scenario A and the motion trajectory for Scenario A
is described in Figure 41 The motion was designed to exhibit dynamics on every
axis of the inertial units and move in every direction to allow for analysis of all
aspects of the navigation system Two additional scenarios were generated to verify
57
Figure 41 This diagram explains the motion trajectory of the simulated vehicle inScenario A
that the high dynamics of Scenario A were not the source of any problems seen in
the EKFrsquos solution
Scenario B included the same 2 minutes of stationary time at the beginning of
the simulation but instead accelerates east to 50 ms at a much slower pace over
the course of 45 seconds instead of about 10 It then pitches upwards and climbs
gradually to a modest altitude of 1000 meters Scenario C begins with the same
stationarity and then accelerates slowly to 15 ms in an eastward direction and
continues at a constant velocity after reaching 15 ms
With each scenario DRAGON executed the simulation generating GPS mea-
58
surements and IMU measurements The GPS receiver in DRAGON produces posi-
tion solutions and associated covariances The IMUs tested were all of ideal grade
meaning there was no bias and no noise providing perfect measurements in order to
gauge the optimal performance of Scorpionrsquos standard EKF For all tests the con-
version tool translated the position solutions from the GPS receiver and the IMU
measurements from the simulated inertial motions It also converted the full posi-
tion solution from Scorpion including position velocity attitude and all covariances
to the PNT event format used by DRAGON
As another part of the analysis GPS signals were withheld from the Scorpion
filter after navigating for a few minutes to simulate an outage This allowed analysis
of the performance of the filter while ldquocoastingrdquo or running on just inertial mea-
surements The conversion tool facilitated the elimination of GPS signals by simply
refraining from transmitting the position messages to Scorpion This test was done
with multiple different grades of IMUs as simulated by DRAGON
Finally the solutions that are sent back to DRAGON are logged to files along
with the truth data for the simulations and the raw GPS and IMU measurements
that were sent to Scorpion during the simulation Using DRAGONrsquos MATLAB
analysis tools these quantities were compared and analyzed for discrepancies and
performance This procedure was repeated for each scenario and multiple other
times throughout testing when bugs were detected and eliminated
43 Results
Initial testing was done with Scenario A which is where most bugs were uncovered
After fixing the IMU orientation configuration issue as seen in Figure 33 and de-
scribed in the last chapter the plots in Figure A1 were produced This was clearly
59
not right either and at first it was ambiguous whether it was even an improve-
ment over the previous results It was indeed closer and the fact that all the axes
of orientation started at the correct value was important as it removed the offsets
that were present before the IMU orientation configuration fix was implemented
However there was indeed something else wrong with the system and it took a long
time to track down
To demonstrate that there were fundamentally two issues with this solution
another set of plots are presented in Figure 42 to show that when inverting the
plots almost everything from the solution matches the truth values There is still
that odd spike in the elevation angle and the early drop in the heading angle After
some inspection it was determined that the spike in elevation when added to the
heading angle at the same time would produce the correct solution The mystery
was why that portion of the rotation was appearing as elevation rather than heading
especially when the rest of the solutions were correct on a large scale
Figure 42 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
60
The position and velocity plots in Figures A3 and A4 show that the solution be-
ing produced is correct in terms of position and velocity It is just the attitude that
has large errors This led to the conclusion that something with the IMU measure-
ments was incorrect since GPS measurements bound the positions and velocities
but do not provide any explicit orientation information All orientation information
in the filter comes from the IMU measurements
The investigation began with another look into the orientation settings of DRAGON
and Scorpion One configuration tried was inverting just the z axis the vertical axis
to see if it would correct all of the sign errors The plots in Figure A5 show the
results of that attempt
After the orientation in some sense was ruled out as the cause of the issue
the conversion tool was the first piece of scrutiny since it was very new and still
in development at that point To verify this plots were generated for the raw
solutions being received Before undergoing any conversion the roll pitch and
yaw received from Scorpion were logged directly and plotted alone The results
showing exactly the solutions being received can be seen in Figure 43 The fact
that this also showed the same results that the network logger was recording from
the conversion tool indicated that the transformations of the data from Scorpion
back into DRAGON PNT events was being done correctly
Having verified the output of the conversion tool matched its input on the receiv-
ing side from Scorpion the transforms for the ingoing measurements from DRAGON
needed to be verified To do this the raw IMU values being sent were plotted and
compared to what should be expected based on the motion trajectory for Scenario
A This plot of IMU values is presented in Figure A6 From the plots it can be seen
that the IMU values are exactly what would be expected Consider that the IMU
rotates with the vehicle so its measurements will include a rotation in the pitch
61
Figure 43 The direct results received from Scorpion without any modifications
axis during the banked turn because of the bank In order for the craft to remain
level to the ground when performing the banked turn some of the rotation will be
in the yaw axis but some will be in the pitch axis as well So the conversion tool is
sending the expected data to Scorpion This result led to the belief that there was
some issue within the EKF in Scorpion
The errors seen are very interesting because the position and velocity track per-
fectly but the attitude errors are enormous The EKF must be navigating correctly
to be able to track position and velocity accurately at least on a large scale Be-
cause of this the output of the solutions from the internals of the filter were the
first suspect After digging into the code for a bit there was some question about
a formula in an attitude conversion being done before the solution was outputted
but it turned out to be an alternate formulation that was correct The error was
still at large
Following some discussions with the developers of Scorpion it was discovered
that Scorpion produces log files from its internal state when it runs by default
62
Plotting these log files from Scorpion yielded an interesting result shown in Figure
44 This looks correct like it would match the truth solution that was expected for
Scenario A So to hone in on the error Scorpionrsquos logs showed a correct solution but
an incorrect solution (as seen in Figure 43) was being received by the conversion
tool
Figure 44 Attitude solutions Scorpion logged during execution of the EKF
After more discussion with the developers of Scorpion a separate output method
was uncovered that was used exclusively for sending solution out over the LCM net-
work interface In this output method the attitude solution was being transformed
incorrectly The specific error was in the conversion from a rotation matrix used in
the internal state of the filter to roll pitch and yaw for transmission The method
erroneously transposed the rotation matrix before converting to Euler angles which
changed the meaning of the rotation matrix Originally represented as a rotation
from the navigation to the body frame the transpose changed it to a body to nav-
igation frame rotation causing all of large scale attitude errors in the solutions
Once this bug was uncovered and repaired the large scale motion of the plots was
63
fixed as seen in Figure 45
Figure 45 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error
These plots show that the attitude correctly follows the truth values for Scenario
A However with the large scale motion corrected the remaining errors stuck out In
Figure 45 as well as the earlier Figures A3 and A4 the errors are much larger than
would expected out of any fused solution and even larger than would be expected
from a raw GPS solution The position errors on the order of 30 or so meters off
should instead be on the order of a few meters and the attitude errors should not
even approach 1 degree of error with an ideal IMU Additionally the shape of the
error graphs is very jagged with very high frequency noise which should not be the
case Typically the error would appear like a somewhat random walk over small
time segments gradually moving up and down around the expected value
Upon further inspection the solutions coming from Scorpion were not in chrono-
logical order with consecutively arriving samples sometimes going slightly back in
time This phenomenon can be seen in Figure 46 (and Figure A8) which are plots
from Scenario A zoomed in on the beginning of the turn maneuver and the climb
64
Figure 46 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
The jaggedness it was hypothesized was directly related to the erratic errors in all
of the solutions
After performing a review of the converter code with some of the members of the
DRAGON team some seemingly minor bugs were fixed including replacing integer
literals in formulas with floating point literals The converter tool runs in Python
27 so the type inference needed an explicit decimal point to interpret the value as
a floating point number For example (1 - f) became (10 - f) Additionally
a fresh simulation environment was created Running the simulations again in the
new environment after cleaning up the converter code the jaggedness and out of
order solutions had been eliminated The original cause was never determined but
it was most likely related to the fresh simulation environment Cached files or other
persistent elements outside of the code could have been causing the errors initially
Discovering this all the simulations were run again and more testing was done
The results from Scenarios A B and C are presented in Figures A10 through A18
It should be noted that there is a bias in the altitude in all cases This is simply be-
65
cause the GNSS solutions outputted by DRAGON did not include any atmospheric
corrections which causes a position bias (mostly in the vertical channel) The EKF
converges to that incorrect vertical position
With the filter performing correctly more variables in the simulations could be
modified to test the filterrsquos response The first test was running Scenario A with a
lower grade IMU All of the previous tests were run with an ideal IMU that showed
no bias and had no noise added to the measurements but this is not realistic for
real-world performance Because of Scorpionrsquos use of gyro-compassing to determine
orientation the lowest quality IMU that could be used was a tactical grade which
is a level below navigation grade but a level above industrial grade This tests the
response of the filter to imperfect measurements The plots showing the solutions
are shown in Figures A19 through A21 Only results for Scenario A are presented
because they are the most demonstrative of the performance of the filter The
attitude plot is reproduced in Figure 47 as well
Figure 47 Attitude solution plots for Scenario A using a tactical grade IMU
The next test again used the tactical grade IMU and also dropped GPS signal
66
after 140 seconds in the middle of the climb to altitude At this point the EKF
must navigate based solely on IMU measurements in what is known as a period
of coasting The EKF should have established a good set of bias estimates for the
IMU by this point and continue to navigate fairly well without losing track of the
vehiclersquos true position for a few minutes The results from this test can be seen in
Figures A22 through A24 The position solution plot is reproduced in Figure 48
Figure 48 Position solution plots with no GPS measurements after 140 seconds forScenario A using a tactical grade IMU
44 Analysis
After collecting the results they were viewed as a whole to represent the performance
of the default EKF built into Scorpion Once the interface with Scorpion and the
converter was worked out to function properly the errors seen in the plots were very
small
Average lateral position error in Scenario A when using the tactical grade IMU
was on the order of 1 meter The average vertical position error was about 12 meters
67
The vertical error is expected because of the lack of atmospheric corrections in the
GNSS solution produced by DRAGON Another factor that impacts the vertical
direction is that GPS satellites are only visible above the receiver limiting the
information available to solve for position It can also be seen in the plots that the
position solution gradually improves over time This is most likely due to the EKF
getting increasingly better estimates of the IMU biases and using that information
to make better predictions
The velocity errors in Scenario A from the simulation using the tactical grade
IMU were noisy but did not deviate from the truth by more than 15 ms and
for the most part were much lower around 01 ms There were some spikes in
the errors but since the estimate recovered quickly it did not impact the position
estimates much In the results using the ideal IMU the errors are around the same
level as seen in the plots using the tactical grade IMU showing that most error is
introduced by the dynamics of the scenario rather than the quality of the IMU
For the attitude plots the impact of the IMU quality can be seen much more
clearly This is because the highly accurate GPS signal cannot contribute to the
attitude estimate (in this configuration) In the results using the ideal IMU the
attitude errors never exceed 01 degrees and do not have any trend over the course
of the simulation The simulation using the tactical grade IMU however begins
with a large attitude error greater than 2 degrees likely due to biases inherent in
the IMU during the gyro-compassing procedure As the simulation continues the
EKF is able to improve its estimates of the biases in the IMU and thereby produce
more accurate attitude estimates getting down to 03 degrees by the end of the
simulation
In the lost GPS signal test the position and velocity estimates both start to trail
off away from the true value noticeably after GPS signal is cut The east position
68
estimate is off by a kilometer after two minutes without GPS It is expected that a
tactical grade IMU would drift without GPS and the errors seen here are within the
expectations of what an EKF should produce with the given resources suggesting
that Scorpionrsquos EKF is implemented correctly and is tuned well
The attitude error plot during the test with the GPS outage is also interest-
ing It begins very high at almost 4 degrees off but it shows a huge improvement
immediately after the vehicle begins moving likely due to the information gained
by the motion allowing the filter to resolve some of the IMU biases Interestingly
the attitude estimates continue to improve albeit much more gradually after the
GPS signal is lost This is not the expected behavior as GNSS measurements are
the only information which can help constrain the free inertial drift This is only
one simulation run however and a Monte-Carlo analysis may have shown different
results The attitude errors statistically should grow without GPS to bound the
inertial drift
The insight into the errors when coasting without GPS was not possible to obtain
before this tool was developed The granularity and accuracy of information that
this combined analysis environment provides is unmatched by either tool alone and
by other available tools In addition further research could use this tool to perform
Monte-Carlo analysis and obtain statistical results with the same degree of precision
45 Chapter Summary
Throughout this chapter the saga of testing and bug fixing the filter and integration
was presented alongside results of simulations An analysis of the results showed that
the EKF performed relatively well with the resources it was given when both GPS
and IMU measurements are available When the GPS signal was removed Scorpionrsquos
69
EKF solutions began to drift with errors growing to about a kilometer in 2 minutes
without GPS as expected with a tactical grade IMU This result indicates that the
EKF is operating and tuned properly Overall the ability of Scorpionrsquos EKF to
track the motion and orientation of the object without a vehicle dynamics model in
a high dynamics scenario shows the value of an EKF for navigation
70
Chapter 5
Conclusion
The research performed for this thesis involved analysis of existing tools design of a
new system to facilitate an interface between them implementation of that interface
design and an analysis of an Extended Kalman Filter using the newly developed
interface The main takeaways from this research include the following
bull A tool has now been developed that will allow navigation filter designers and
developers to prototype their designs in an environment that easily facilitates
testing of the prototypes The simulation environment is very high quality
and includes a suite of analysis tools to monitor the performance of the filter
and tune it to the desired performance
bull The new integrated navigation filter environment allows testing of different
filter and sensor configurations (eg different quality IMUs) by virtue of the
reconfigurability of both DRAGON and Scorpion and the flexibility of the
conversion tool to match the capabilities of both tools
bull The environment supports the addition of new sensor types for more complex
navigation filters and can continue to evolve and grow with each new sensor
71
module added
bull Scorpionrsquos default EKF was tested with varying quality IMUs and with a
GPS outage and its performance was found to be about average for an EKF
although it was shown to be in need of improvement when coasting without
GPS
51 Future Work
While the work done for this thesis has proven the concept of a real-time integrated
navigation filter simulation environment one of the biggest achievements is opening
the door for more complex filter implementation and analysis Some ideas for future
work related to this research are presented below
bull It would be extremely powerful to have this work extended to facilitate tightly
coupled filters by adding conversions for DRAGONrsquos observation events
bull Image based navigation would also greatly expand the capabilities of the sys-
tem and bring it to full relevance with a current trend in navigation of inte-
grating vision based systems into navigation filters
bull Using DRAGONrsquos very recently developed GNSS fault simulation capabilities
the system could be used to evaluate the performance of navigation filters in
compromised environments
bull This system could be used to compare different filter paradigms and imple-
mentations in identical but non-trivial scenarios
72
Appendix A
Developmental and Result Plots
Additional plots from the development process and results are presented in full size
in this Appendix
73
Figure A1 In-progress result during development Attitude solutions from Scorpionafter resolving the IMU orientation configuration error
74
Figure A2 In-progress result during development Inverted attitude solutions fromScorpion showing the erroneous spike in elevation and drop in roll
75
Figure A3 In-progress result during development Position plots showing mostlycorrect data from the same test run as the incorrect attitude results
76
Figure A4 In-progress result during development Velocity plots showing mostlycorrect data from the same test run as the incorrect attitude results
77
Figure A5 In-progress result during development Attitude plots showing thesolutions from Scorpion with the z axis of the IMU measurements inverted Thegaps in the solutions are times during which Scorpion was not able to form a coherentsolution and reset
78
Figure A6 The raw IMU measurements being sent to Scorpion from the converterThis shows each axis independently
79
Figure A7 Attitude plots from Scorpionrsquos solutions after fixing the LCM outputformatting error in Scorpion
80
Figure A8 Zoomed in attitude plot of solutions from Scorpion showing the jaggedtime behavior in which samples showed up out of order
81
Figure A9 Zoomed in position plot of solutions from Scorpion showing the out oforder samples with the jagged errors in the solutions
82
Figure A10 Position solution plots for Scenario A using an ideal IMU
83
Figure A11 Velocity solution plots for Scenario A using an ideal IMU
84
Figure A12 Attitude solution plots for Scenario A using an ideal IMU
85
Figure A13 Position solution plots for Scenario B using an ideal IMU
86
Figure A14 Velocity solution plots for Scenario B using an ideal IMU
87
Figure A15 Attitude solution plots for Scenario B using an ideal IMU
88
Figure A16 Position solution plots for Scenario C using an ideal IMU
89
Figure A17 Velocity solution plots for Scenario C using an ideal IMU
90
Figure A18 Attitude solution plots for Scenario C using an ideal IMU
91
Figure A19 Position solution plots for Scenario A using a tactical grade IMU
92
Figure A20 Velocity solution plots for Scenario A using a tactical grade IMU
93
Figure A21 Attitude solution plots for Scenario A using a tactical grade IMU
94
Figure A22 Position solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
95
Figure A23 Velocity solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
96
Figure A24 Attitude solution plots with no GPS measurements after 140 secondsfor Scenario A using a tactical grade IMU
97
Appendix B
Bibliography
[1] Mike1024 [Public domain] via Wikimedia Commons ECEF ENU longitudelatitude relationships 2010 [Online accessed September 5 2017]
[2] Krishnavedala [Creative Commons Attribution-Share Alike] via Wikime-dia Commons Diagram of earth centered earth fixed coordinates in relationto latitude and longitude 2017 [Online accessed September 5 2017]
[3] Juansempere [Creative Commons Attribution] via Wikimedia Commons Tait-bryan angles ZYX321 convention 2013 [Online accessed September 5 2017]
[4] El Pak [Public domain] via Wikimedia Commons Constellation GPS 2008[Online accessed September 5 2017]
[5] Elliott Kaplan and Christopher Hegarty Understanding GPS Principles andApplications Artech house 2005
[6] The-Crankshaft Publishing Carrier and code tracking (GPS and galileo re-ceiver) part 4 2017 [Online accessed September 25 2017]
[8] VectorNav Technologies LLC Inertial measurement units and inertialnavigation Available at httpswwwvectornavcomsupportlibrary
imu-and-ins (20170828) 2017
[9] Siddharth Sridhar Adam Hahn and Manimaran Govindarasu Cyberndashphysicalsystem security for the electric power grid Proceedings of the IEEE 100(1)210ndash224 2012
[10] Hermann Auernhammer Precision farming the environmental challenge Com-puters and Electronics in Agriculture 30(1)31ndash43 2001
98
[11] Todd E Humphreys Brent M Ledvina Mark L Psiaki Brady W OHanlon andPaul M Kintner Jr Assessing the spoofing threat Development of a portableGPS civilian spoofer In Proceedings of the ION GNSS International TechnicalMeeting of the Satellite Division volume 55 page 56 2008
[12] Dana Goward Mass GPS spoofing attack in black seaAvailable at httpmaritime-executivecomeditorials
[14] Nathan Olivarez Mitigating the effects of ionospheric scintillation on GPScarrier recovery Masterrsquos thesis Worcester Polytechnic Institute April 2013
[15] William R Michalson Ensuring GPS navigation integrity using receiver au-tonomous integrity monitoring IEEE Aerospace and Electronic Systems Mag-azine 10(10)31ndash34 1995
[16] Torsten Schonberg M Ojala Jussi Suomela A Torpo and Aarne Halme Po-sitioning an autonomous off-road vehicle by using fused DGPS and inertialnavigation International Journal of Systems Science 27(8)745ndash752 1996
[17] Neal A Carlson and Michael P Berarducci Federated kalman filter simulationresults Navigation 41(3)297ndash322 1994
[18] J Wendel J Metzger R Moenikes A Maier and GF Trommer A performancecomparison of tightly coupled GPSINS navigation systems based on extendedand sigma point kalman filters Navigation 53(1)21ndash31 2006
[19] Kenneth Gade Navlab a generic simulation and post-processing tool for nav-igation MIC Journal 2005
[20] Scorpion slick sheet Available at httpswwwafitedudocsScorpion
pdf (20171006) 2017
[21] Paul D Groves Principles of GNSS inertial and multisensor integrated navi-gation systems Artech house 2013
[22] Pratap Misra and Per Enge Global positioning system signals measurementsand performance second edition Massachusetts Ganga-Jamuna Press 2006
[23] Oleg Stepanovich Salychev Applied Inertial Navigation problems and solu-tions BMSTU Press Moscow Russia 2004
99
[24] F Landis Markley and John L Crassidis Fundamentals of Spacecraft AttitudeDetermination and Control volume 33 Springer 2014
[25] James Diebel Representing attitude Euler angles unit quaternions and ro-tation vectors Matrix 58(15-16)1ndash35 2006
[26] Gregory G Slabaugh Computing euler angles from a rotation matrix Retrievedon August 6(2000)39ndash63 1999
[27] Stanley Wayne Shepperd Quaternion from rotation matrix[four-parameterrepresentation of coordinate transformation matrix] Journal of Guidance andControl 1 1978
[28] WM Mularie Department of defense world geodetic system 1984 its definitionand relationships with local geodetic systems National Geospatial-IntelligenceAgency Tech Rep 152 2000
[29] C Boucher and Z Altamimi ITRS PZ-90 and WGS 84 current realizationsand the related transformation parameters Journal of Geodesy 75(11)613ndash619 2001
[30] Ramjee Prasad and Marina Ruggieri Applied satellite navigation-using GPSGALILEO and augmentation systems 2005
[31] Thuy Mai Global positioning system history Available at httpswwwnasagovdirectoratesheoscancommunicationspolicyGPS_Historyhtml
(20170810) 08 2017
[32] National Coordination Office for Space-Based Positioning Navigation andTiming GPS modernization Available at httpwwwgpsgovsystems
gpsmodernization (20170810)
[33] National Coordination Office for Space-Based Positioning Navigation andTiming GPS space segment Available at httpwwwgpsgovsystems
gpsspace (20170810)
[34] Information Analysis Center for Positioning Navigation and Timing Ko-rolyov Russia Glonass history Available at httpswwwglonass-iacru
enguideindexphp (20170814)
[35] Bernhard Hofmann-Wellenhof Herbert Lichtenegger and Elmar Wasle GNSSndashGlobal Navigation Satellite Systems GPS GLONASS Galileo and moreSpringer Science amp Business Media 2007
[36] Sherman G Francisco GPS operational control segment Global PositioningSystem Theory and Applications 1435ndash466 1996
100
[37] Todd E Humphreys Mark L Psiaki Paul M Kintner and Brent M LedvinaGNSS receiver implementation on a DSP Status challenges and prospectsProceedings of ION GNSS 2006 2006
[38] Sam Pullen Young Shin Park and Per Enge Impact and mitigation of iono-spheric anomalies on ground-based augmentation of GNSS Radio Science44(1) 2009
[39] Youjing Cui and Shuzhi Sam Ge Autonomous vehicle positioning with GPS inurban canyon environments IEEE Transactions on Robotics and Automation19(1)15ndash25 2003
[40] Bradford W Parkinson and Per K Enge Differential GPS Global PositioningSystem Theory and Applications 23ndash50 1996
[41] Robert M Rogers Applied mathematics in integrated navigation systems vol-ume 1 AIAA 2003
[42] Averil B Chatfield Fundamentals of high accuracy inertial navigation volume174 AIAA 1997
[43] Samer Khanafseh Naeem Roshan Steven Langel Fang-Cheng Chan MathieuJoerger and Boris Pervan GPS spoofing detection using raim with ins cou-pling In Position Location and Navigation Symposium-PLANS 2014 2014IEEEION pages 1232ndash1239 IEEE 2014
[44] Saurabh Godha Gerard Lachapelle and M Elizabeth Cannon Integrated GP-SINS system for pedestrian navigation in a signal degraded environment InION GNSS volume 2006 2006
[45] Salah Sukkarieh Eduardo Mario Nebot and Hugh F Durrant-Whyte A highintegrity IMUGPS navigation loop for autonomous land vehicle applicationsIEEE Transactions on Robotics and Automation 15(3)572ndash578 1999
[46] Rudolph Van Der Merwe Arnaud Doucet Nando De Freitas and Eric A WanThe unscented particle filter In Advances in Neural Information ProcessingSystems pages 584ndash590 2001
[47] M Sanjeev Arulampalam Simon Maskell Neil Gordon and Tim Clapp Atutorial on particle filters for online nonlinearnon-gaussian bayesian trackingIEEE Transactions on Signal Processing 50(2)174ndash188 2002
[48] Simon J Julier and Jeffrey K Uhlmann A new extension of the kalman filter tononlinear systems In Int symp aerospacedefense sensing simul and controlsvolume 3 pages 182ndash193 Orlando FL 1997
101
[49] Rudolph Emil Kalman et al A new approach to linear filtering and predictionproblems Journal of Basic Engineering 82(1)35ndash45 1960
[50] Fred Daum Nonlinear filters beyond the kalman filter IEEE Aerospace andElectronic Systems Magazine 20(8)57ndash69 2005
[51] Isaac Skog and Peter Handel Time synchronization errors in loosely cou-pled GPS-aided inertial navigation systems IEEE Transactions on IntelligentTransportation Systems 12(4)1014ndash1023 2011
[52] Steven E Langel M Samer Fang-Cheng Chan and Boris S Pervan Tightlycoupled GPSINS integration for differential carrier phase navigation systemsusing decentralized estimation In Position Location and Navigation Symposium(PLANS) 2010 IEEEION pages 397ndash409 IEEE 2010
[53] Naser El-Sheimy Haiying Hou and Xiaoji Niu Analysis and modeling ofinertial sensors using allan variance IEEE Transactions on instrumentationand measurement 57(1)140ndash149 2008
[54] Albert S Huang Edwin Olson and David C Moore LCM Lightweight com-munications and marshalling In Intelligent robots and systems (IROS) 2010IEEERSJ international conference on pages 4057ndash4062 IEEE 2010
[55] LLA to ECEF position Available at httpwwwmathworkscomhelp
aeroblksllatoecefpositionhtml (20171013)
[56] D M Henderson Euler angles quaternions and transformation matricesAvailable at httpsntrsnasagovarchivenasacasintrsnasagov
19770024290pdf (20171015)
[57] Richard W Pogge Real-world relativity The GPS navigation sys-tem Available at httpwwwastronomyohio-stateedu~poggeAst162Unit5gpshtml (20170104) 10 2016
[58] Jack B Kuipers et al Quaternions and rotation sequences volume 66 Princetonuniversity press Princeton 1999
[59] Peter JG Teunissen and Alfred Kleusberg GPS observation equations andpositioning concepts In GPS for Geodesy pages 187ndash229 Springer 1998
[60] Federal Aviation Administration GNSS frequently asked questions - GPSAvailable at httpswwwfaagovaboutoffice_orgheadquarters_
