NOMENCLATURE
Symbols
-
$a_{\sigma}$ ,
$b_{\sigma}$
-
error factors of satellite measurements
- b
-
bias error of inertial measurement unit (IMU)
-
$ B_{r,i}^s $
-
phase ambiguity at frequency i
- c
-
velocity of light in vacuum
- C
-
rotation matrix
-
$ {dt}_r $
-
receiver clock offset
-
$ {dT}^s $
-
satellite clock offset
- D
-
differential code biases (DCB)
-
$ e^s_{r} $
-
vector from satellite to receiver
- El
-
elevation angle
-
$ f^m $
-
specific force
-
$ f_i $
-
frequency
- F
-
state transition matrix
- G
-
gravity vector
-
$ G_k $
-
transition matrix of state noise
-
$ I_{r,i}^s $
-
ionospheric delay at frequency i
-
$ I_n $
-
n-dimensional identity matrix
- K,k
-
cross-coupling error of IMU
-
$ m_w $
-
tropospheric wet mapping function
- p
-
position
- P
-
pseudorange of satellite measurements
-
$\tilde{P}$
-
corrected pseudorange
- Q
-
covariance matrix of states
- R
-
covariance matrix of measurement noise
- S,s
-
scale factor error of IMU
-
$ T_r^s $
-
tropospheric delay
- v
-
velocity
- w
-
white noises
- W
-
covariance matrix of white noise
- x
-
estimated states of filter
-
$ Z_{T,r} $
-
troposphere zenith total delay (ZTD)
-
$ \beta $
-
state transition item of the first-order Gauss–Markov procedure
-
$ \theta $
-
radir angle
-
$ \rho_r^s $
-
geometry distance between satellite and receiver
-
$ \varepsilon $
-
un-modelled errors
-
$ \lambda $
-
wavelength
-
$\tilde{\Phi}$
-
corrected phase range
-
$ \phi $
-
carrier phase of satellite signal, including true phase and phase errors
-
$ \Phi $
-
phase range
-
$ \omega $
-
angular velocity
Abbreviations
- CNES
-
Centre national d’etudes spatiales
- DCB
-
differential code delay
- ECEF
-
earth-centred earth-fixed
- ENU
-
east-north-up
- EKF
-
extended Kalman filter
- GNSS
-
global navigation satellite system
- IMU
-
inertial measurement unit
- IGS
-
international GNSS service
- ISB
-
inter-system bias
- MEMS
-
micro-electro-mechanical system
- PPP
-
precise point positioning
- PPK
-
post-processed kinematic
- PCO
-
phase centre offset
- PCV
-
phase centre variation
- RTK
-
real-time kinematic
- RMS
-
root-mean-square
- UAV
-
unmanned aerial vehicle
- UPD
-
un-calibrated phase delay
- URA
-
user range accuracy
- ZTD
-
zenith total delay
1.0 INTRODUCTION
Accurate navigation algorithms for Unmanned Aerial Vehicles (UAVs) have been discussed in many application areas, such as agriculture, construction, urban mobility etc. Various approaches are available and widely used. Global Navigation Satellite System (GNSS) Real-Time Kinematic (RTK) is a decent approach owing to its centimetre-level accuracy and ultra-rapid convergence. However, RTK suffers from its requirement for a static reference station(Reference Odijk, Verhagen and Teunissen1), which makes it inconvenient and expensive. Similarly, Ultra-Wide Band (UWB) is a pseudo-satellite technology that can provide 10cm-level precise positioning solutions(Reference Gezici, Tian and Giannakis2), but it needs several stations and is also limited by its short communication distance. Moreover, Simultaneous Localisation and Mapping (SLAM), based on visual sensors or Light Detection and Ranging (LiDAR), is also a preferred high-accuracy navigation technology, but these algorithms need prior or closed-loop mapping for high accuracy, or the positioning solution will slowly drift in time(Reference Delmerico and Scaramuzza3). Also, the SLAM algorithm needs a large number of feature points, including building texture, trees and grass, etc. which are absent in open-sky areas. Comparatively, Precise Point Positioning (PPP) can provide a stable accurate position in global coordinate frames after convergence without local reference stations.
The PPP technique was introduced in the late 1990s(Reference Zumberge, Heflin, Jefferson, Watkins and Webb4,Reference Kouba and Hroux5) , using the ionosphere-free combination of dual-frequency GNSS phase and code observations. It utilises precise ephemeris and precise error models to eliminate observing errors and estimates the incomplete modelled errors as parameters(Reference Kouba and Hroux5). There are two main advantages of PPP(Reference Gao, Li, Zhuang, Yang, Pan and Zhang6). Firstly, PPP has the capability to efficaciously provide centimetre-level absolute positioning solutions in open-sky environments. Secondly, PPP does not need base stations, which makes it possible to obtain high-accuracy solutions at any location as long as sufficient GNSS observations are available. Traditional PPP operates on a post-processing approach, since the precise correction products provided by the International GNSS Service (IGS) have a latency of several hours to several days. Thanks to the work of the IGS Real-Time Service (IGS-RTS) and global stations(Reference Laurichesse and Mercier7–Reference Mireault, Lahaye, Collins, Caissy and NrCan9), precise real-time products were officially launched through Networked Transport of RTCM via Internet Protocol (NTRIP) on 1 April 2013(Reference Elsobeiey and Al-Harbi10). The RTS products, which are formatted for state-space representation (SSR), consist of corrections to the broadcast ephemerides, the code biases, the phase biases and ionosphere Vertical Total Electron Content (VTEC) information(Reference Wang, Li, Ge, Neitzel, Wang and Yuan11). Currently, several RTS products are provided by different agencies, such as GFZ (Deutsches GeoForschungsZentrum), CODE (Centre for Orbit Determination in Europe), CNES (Centre national dtudes Spatiales) and WHU (Wuhan University), but most of them are only available for either GPS or GPS + GLONASS. CNES is the first agency to provide SSR corrections for BDS and Galileo satellites, thus enabling four-constellation real-time PPP.
However, PPP position fixes are vulnerable to poor GNSS observations, cycle slip and data outages, which may cause divergence and make PPP take several tens of minutes to re-converge. By contrast, the Inertial Measurement Unit (IMU) can provide continuous position, velocity and attitude at high rate without any external information(Reference Eh12), but its accuracy degrades rapidly over time due to the accumulating character of IMU sensor errors, especially for Micro-Electro-Mechanical System (MEMS) IMU(Reference Rabbou and El-Rabbany13). In practice, continuous and stable navigation solutions are required for UAV autopilot operation. PPP-only systems cannot provide continuous solutions in GNSS-challenged environments, whereas IMU-only systems cannot provide stable position and velocity outputs over long durations. Hence, integrating PPP and IMU could overcome the drawbacks of each individual system. In such integration, the continuous IMU solutions are utilised to bridge the discontinuous GNSS solutions under poor satellite tracking conditions(Reference Gao, Ge, Li, Pan, Chen and Zhang14). Such integration was first attempted in the post-processing model by combining GPS PPP and tactical-grade IMU(Reference Zhang and Gao15). A land vehicle test(Reference Shin and Scherzinger16) showed that tight GPS/IMU coupling can provide much greater robustness than loose coupling. According to the studies of Roesler et al.(Reference Roesler and Martell17) and Rabbou(Reference Rabbou and El-Rabbany13), tightly coupled integration between PPP and IMU can provide land platform positions with both horizontal and vertical accuracy better than 15cm. Besides, Gao et al.(Reference Gao18,Reference Gao24) confirmed that IMU can aid in the recovery of GNSS data outages or cycle slips and enable rapid re-convergence when PPP/IMU are integrated with tight coupling.
Most previous studies have been based on the post-processing PPP model because of the absence of precise real-time multi-GNSS products(Reference Zhang and Gao15–Reference Roesler and Martell17). For the real-time case, previous works mainly focused on GPS only, or double- or triple-constellation PPP integrated with high-level IMU(Reference Rabbou and El-Rabbany13,Reference Gao18,Reference Gao24) , although no aerial tests were presented. We introduce four-constellation real-time PPP with tightly coupled integration using a consumer-grade MEMS IMU on a UAV. The multi-GNSS PPP model and its tightly coupled integration with the IMU are presented. A corresponding prototype system is designed, and the related software is realised. An on-board test is carried out using a quadrotor equipped with a SwiftNav PIKSI multi-GNSS receiver and an ADXRS620+ADXL203 consumer-grade MEMS IMU. The measurement data are tightly integrated in real time ysing the on-board ARM core chip to test the positioning accuracy. To test the system performance under GNSS-challenged environments, GNSS-denied and GNSS-degraded environments are simulated with different time durations. The computational load is also evaluated.
The paper is organised as follows: Section 2 introduces the four-constellation GNSS real-time PPP model, the IMU model and the four-constellation GNSS real-time PPP and IMU tight integration model. Section 3 presents the experimental setup and results, including an open-sky flight test, a series of GNSS outage simulations, a GNSS-insufficient simulation and the computational load test. A discussion of the results is also presented in this section. Finally, Section 4 summarises the study.
2.0 ALGORITHMS
2.1 Multi-GNSS real-time PPP model
Similar to the RTK algorithm, PPP utilises both code and carrier phase measurements in the filtering process, and also estimates the integer ambiguity. Differently, PPP eliminates measurement errors by corrections, precise models and estimation, while RTK eliminates them based on the double-difference between satellites and receivers. The observation equations for the un-differenced GNSS pseudorange and carrier phase can be expressed as follows:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn1.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn2.png?pub-status=live)
where
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn3.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn4.png?pub-status=live)
and i and j represent two different frequencies,
$ P^s_{r,i} $
is the pseudorange between satellite s and receiver r, and
$ \Phi_{r, i}^{s}=\lambda_{t} \phi_{r, i}^{s} $
is the phase range, where
$\phi_{r, i}^{s}$
is the carrier phase measurement.
$\rho_{r}^{s}=\left|p_{r}-p^{s}\right|$
is the geometrical distance between the receiver antenna mass centre and satellite mass centre, c is the speed of light in vacuum,
$d t_{r}$
and
$d T^{s}$
represent, respectively, the receiver clock offset at the signal receiving time and the satellite clock offset at the signal transmitting time,
$I_{r, i}^{s}$
is the ionospheric delay along the signal propagation path at frequency i,
$T_{r}^{s}$
is the tropospheric delay of the signal path,
$D_{r, P_i}$
and
$ D^s_{P_i} $
are the differential code biases (DCB) for the receiver and satellite,
$ \lambda_i $
is the wavelength at frequency i,
$B_{r, i}^{s}$
indicates the non-integer phase ambiguity, which contains the integer phase ambiguity
$N_{r, i}^{s}$
and the un-calibrated phase delay (UPD)
$\phi_{r, 0, i}$
and
$\phi_{0, i}^{s}$
, where
$\phi_{r, 0, i}$
is the initial phase (cycle) of the receiver local oscillator and
$\phi_{0, i}^{s}$
is the initial phase of the transmitted navigation signal at initial time.
$d \Phi_{r, i}^{s}$
represents the carrier-phase correction terms, including the antenna phase centre offsets (PCO)
$d_{r, pco, i}^{T}$
, antenna phase centre variations (PCV)
$d_{r, pcv, i}$
, station displacement by earth tides
$d_{r, {disp}}^{T}$
and phase windup effect
$\phi_{p w}$
, and
$e_{r, e n u}^{s}$
is the vector from satellite s to receiver r in the East-North-Up (ENU) frame.
$ E^s $
is the coordinate transformation matrix from the satellite body-fixed frame to the Earth-Centred Earth-Fixed (ECEF) frame,
$e_{r}^{s}$
is the vector from satellite to receiver in the ECEF frame, El is the satellite elevation angle, ad
$ \theta $
is the satellite nadir angle. Finally, the symbols
$\varepsilon_{p}$
and
$\varepsilon_{\Phi, i}$
are the pseudorange and phase-range observation noise and un-modelled multipath error.
In the real-time PPP model, the satellite orbit error, satellite clock error, code bias and phase delay can be corrected by applying internet broadcast data, the PCO and PCV can be eliminated by using IGS antenna files, and the earth tide effect and phase windup can be modelled precisely. Besides, there are two dominant errors: ionospheric delay and tropospheric delay, which should be considered carefully in the data processing. The former is often eliminated by applying the ionospheric-free combination of pseudorange and carrier phase measurements. The combination can be expressed as
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn5.png?pub-status=live)
where
$ P_{IF} $
and
$ \Phi_{IF} $
are the ionospheric-free combination of pseudorange and phase-range,
$ f_i $
and
$ f_j $
are the frequency of two difference GNSS signals in the same constellation, and
$ P_i $
,
$ \Phi_i $
,
$ P_j $
and
$ \Phi_j $
are the pseudorange and phase range of the corresponding frequencies.
The tropospheric delay is often estimated. It is divided into the zenith hydro-static delay and zenith delay, and the relative mapping functions:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn6.png?pub-status=live)
where
$Z_{H, r}$
is the tropospheric zenith hydro-static delay, which can be calculated by applying the Saastamoinen model.
$Z_{T, r}$
is the tropospheric Zenith Total Delay (ZTD), which should be estimated in the filtering process.
$ m_H $
is the hydro-static mapping function, and
$m_{W}$
is the wet mapping function. For the mapping functions, we use the Niell Mapping Function (NMF) [17] in this paper. The ZTD is usually modelled as a random walk process:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn7.png?pub-status=live)
where
$\omega_{z} \sim N\left(0, q_{T}^{2} \Delta t\right)$
,
$ q_T $
represents the power spectral density (PSD) of ZTD and
$ \Delta{t} $
is the time duration between the k-th and
$ k-1 $
-th time step.
By applying the corrections and ionospheric-free combination, the observation equations can be rewritten as follows:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn8.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn9.png?pub-status=live)
where the subscript IF indicates the ionosphere-free combination, and M indexes the satellite systems, including GPS, GLONASS, BDS and Galileo. The equations show different receiver clock errors between the satellite systems, which is called inter-system bias (ISB), being due to the different signal structure and different hardware delay for each GNSS system. The ISB should be considered and estimated when multi-GNSS observations are used together in the PPP data process(Reference Gao18). It can be written as
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn10.png?pub-status=live)
where ISB
$ _{M,N} $
is the ISB of system N with respect to system M, and the subscripts G, R, C, E correspond to GPS, GLONASS, BDS and Galileo, respectively. Similar to the tropospheric ZTD, ISB is also modelled as a random walk process as shown in Equation (7).
For each observation, the noise is not the same, which is related to the atmospheric thickness along the signal path, multipath effects, the User Range Accuracy (URA) and the carrier-to-noise ratio. We use the following coefficients to represent the observation noise:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn11.png?pub-status=live)
where
$ F_M^s $
is the URA of system M,
$ R_r $
is the inverse of the standardised carrier-to-noise error ratio, and
$a_{\sigma}$
and
$b_{\sigma}$
are error factors. Empirically, we set
$a_{\sigma}$
as 0.003m for phase-range measurements and 0.3m for pseudorange measurements, and set
$b_{\sigma}$
as the same as
$a_{\sigma}$
.
Finally, the state parameters for four-constellation real-time PPP is
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn12.png?pub-status=live)
where
$p_{r}=\left[x_{r}, y_{r}, z_{r}\right]^{T}$
is position of the antenna mass centre in ECEF coordinates, and
$d t_{r}=\left[d t_{r, G}, \operatorname{ISB}_{G, R}, \operatorname{ISB}_{G, C}, \operatorname{ISB}_{G, E}\right]^{T}$
is the clock vector containing the GPS receiver clock delay and ISBs of the other three systems.
${\textbf{\textit{v}}}_{r}$
represents the velocity, and
${{\textbf{\textit{d}}}\dot{\textbf{\textit{t}}}}_{r}$
is the frequency drift. Because
$ {\textbf{\textit{v}}}_{r} $
and
$ {{\textbf{\textit{d}}}\dot{\textbf{\textit{t}}}}_{r} $
can be derived respectively from
$ {\textbf{\textit{p}}}_{r} $
and
$ {\textbf{\textit{d}}} {\textbf{\textit{t}}}_{r} $
, the total number of states includes three positions, m clocks (for an m-constellation system), one tropospheric ZTD and n cycle ambiguities (assuming there are n satellites in view). Therefore, the minimum number of visible satellites to support PPP is
$ 4+m $
.
2.2 IMU model
The IMU consists of an accelerometer and gyroscope, which can provide three-axis specific force and three-axis angular velocity measurements. These measurements can be employed in an Inertial Navigation System (INS) for dead reckoning and attitude determination. When using the ECEF frame as the navigation frame, the INS dynamic can be written as(Reference Liu, Zhan, Liu and Liu20)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn13.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn14.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn15.png?pub-status=live)
where e is the ECEF frame, m is the IMU measurement reference frame, i is the inertial frame,
$ {\boldsymbol{\omega}}_{xy} $
represents the angular velocity of the y -frame with respect to the x -frame,
$ {\textbf{\textit{C}}}_{m}^{e} $
is the rotation matrix from the m-frame to the e-frame,
$[*]^{\times}$
represents matrix cross product,
$ {\boldsymbol{\omega}}_{im}^{m} $
and
$\ {\textbf{\textit{f}}}^{m} $
is the angular velocity and specific force of the IMU output, respectively, and
$ G^{e} $
is the gravity vector in the e -frame.
The IMU device has a series of error sources in both the specific force and angular velocity measurements, especially for a MEMS IMU. The error models can be written as follows:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn16.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn17.png?pub-status=live)
where
$ \tilde{{\boldsymbol{\omega}}}_{i m}^{m} $
and
$\ \tilde{{\textbf{\textit{f}}}}^{m} $
are the true angular rate and acceleration, respectively.
$ {\textbf{\textit{b}}}_i(i=g,a) $
is the bias error, and
$ {\textbf{\textit{I}}}_3 $
is the three-dimensional identity matrix.
$ {\textbf{\textit{M}}}_i(i=g,a) $
is the mixed matrix of the scale factor error (
$ {\textbf{\textit{S}}} $
) and cross-coupling error (
${\textbf{\textit{K}}}$
), as shown in Equation (18).
$ {\textbf{\textit{w}}}_i(i=g,a) $
represents other un-modelled errors, which can be regarded as white noise.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn18.png?pub-status=live)
The dynamic behaviour of the variation of the IMU cross-coupling error can be modelled as white noise and can be absorbed into
$ {\textbf{\textit{w}}}_i(i=g,a) $
(Reference Groves21). The scale factor and bias can be described by the first-order Gauss–Markov procedure(Reference Robert and Hwang22), which can be expressed as
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn19.png?pub-status=live)
where
${\textbf{\textit{w}}}_{i} \sim N\left(0,2 \sigma^{2} \Delta t /\tau_{i}\right)(i=b, s)$
,
$ \Delta{t} $
is the time difference between the
$ k$
-th time step and the
$ k-1 $
-th time step,
$\tau_{i}(i=b, S)$
is the correlation time,
$ {\textbf{\textit{w}}} $
is white noise and
$ \sigma $
is the variance of
$ {\textbf{\textit{w}}} $
determined by the instability of the IMU bias and scale factor error. Commonly, one can find the variance of the errors from the product specifications. However, since there are many other unexpected factors such as the temperature, device ageing etc. that may affect the stability of the biases and scale factor errors, we use larger measurement error variances than the specifications in our implementation to accommodate such uncertainties.
Finally, the estimated parameters for the IMU model are
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn20.png?pub-status=live)
where
${\textbf{\textit{s}}}_{i}=[s_{x}^{i}, s_{y}^{i}, s_{z}^{i}]^{T}(i=a, g)$
is the diagonal element of the matrix
${\textbf{\textit{M}}}_{i}$
.
In IMU-only navigation, the user has to apply compensation or calibration algorithms to make the IMU outputs accurate. Meanwhile, in integrated GNSS/INS algorithms, the errors of the IMU can be estimated in real time with the assistance of GNSS. In this case, only one needs to obtain proper initial states for the IMU biases and scale factors, as well as their variances. In our implementation, the initial scale factors are set to zero, and the biases are estimated using the first 1s of IMU data. Hence, the UAV must remain stable for the first 1s after powering-on. The initial biases are estimated as
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn21.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn22.png?pub-status=live)
where
$ \bar{{\boldsymbol{\omega}}}_{i m}^{m} $
and
$\ \bar{{\textbf{\textit{f}}}}^{m} $
are the 1-s-averaged IMU outputs.
2.3 Multi-GNSS real-time PPP/IMU tight integration
The tight integration of PPP and IMU utilises raw observations of GNSS (pseudorange and phase-range) and IMU (specific force and angular velocity) to achieve higher navigation quality than each method individually. The Extended Kalman Filter (EKF) is used to deal with the nonlinear terms of the states and measurements and combine the two kinds of signal. The estimated parameters for EKF processing are
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn23.png?pub-status=live)
where
$ \delta $
represents the error (update) between two consecutive measurements. The definitions of the parameters can be found in Equations (12) and (21).
To apply the EKF algorithm, one should first derive the linearised state-space representation, which is given as
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn24.png?pub-status=live)
where
$ {\textbf{\textit{F}}}_k $
is the state transition matrix and
$ {\textbf{\textit{H}}}_k $
is the measurement matrix.
The process model can be derived from the vehicle motion model, GNSS model, INS dynamics model and INS error model as follows:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn25.png?pub-status=live)
where
$\delta \bm{x}$
is the state vector, which is given in Equation (21), and
$ \bm{w} $
is the noise vector, which is
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn26.png?pub-status=live)
The items represent the white noises from the vehicle velocity, accelerometer bias and scale factor, the gyroscope bias and scale factor, the receiver clock offset (from the different navigation systems) and frequency drift, the tropospheric delay and the receiver phase ambiguity, respectively. We define the covariance matrix of
$ {\textbf{\textit{w}}} $
as
$ {\textbf{\textit{W}}}_k $
, which is a diagonal matrix determined by the user dynamics. The matrices
$ \bm{F} $
and
$ \bm{G} $
are given as follows:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn27.png?pub-status=live)
where
${\textbf{\textit{F}}}_{p p}, {\textbf{\textit{F}}}_{w}, {\textbf{\textit{F}}}_{v p}, {\textbf{\textit{F}}}_{p v}$
are system dynamics matrices representing the relationship between the position and velocity.
$\beta_{i}=e^{-\Delta t / \tau_{i}}$
is the state transition term of the first-order Gauss–Markov process.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn28.png?pub-status=live)
where
$ \beta $
has the same definition as in Equation (25). Finally,
$ \bm{F}_t $
represents the relationship between the clock offset and frequency drift of the GPS satellite clock and ISB items, having the following form:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn29.png?pub-status=live)
The linearised measurement model of the PPP/IMU tight integration filter is formed by the IMU-predicted pseudorange and phase-range and the GNSS measurements. The measurement equation is
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn30.png?pub-status=live)
where
$ \tilde{\textbf{\textit{P}}}_{i, IF}^{s} $
and
$ {\tilde{\boldsymbol{\Phi}}}_{i, I F}^{s} $
are the corrected GNSS pseudorange and phase-range measurements of GPS, GLONASS, BDS and Galileo.
${\textbf{\textit{e}}}_{r, i}^{s}=[\left({\textbf{\textit{p}}}_{x}^{s}-{\textbf{\textit{p}}}_{r, x}\right) / \rho_{r}^{s} \quad({\textbf{\textit{p}}}_{y}^{s}-{\textbf{\textit{p}}}_{r, y}) / \rho_{r}^{s} ({\textbf{\textit{p}}}_{z}^{s}- {\textbf{\textit{p}}}_{r, z}) / \rho_{r}^{s}]^{T}$
is the vector from a specific receiver to the satellite,
$ {\textbf{\textit{m}}}_w $
is a column vector containing four same tropospheric delay wet mapping functions
$ m_w $
,
$ \boldsymbol{\lambda}_IF $
is the frequency corresponding to each satellite system and
$ \boldsymbol{\varepsilon}_{i, k} $
is the GNSS measurement noise. The covariance matrix of
$ \boldsymbol{\varepsilon}_{i, k} $
is
$ {\textbf{\textit{R}}}_{i, k} $
, which is a diagonal matrix with the elements described by Equation (11).
$ {\textbf{\textit{P}}}_{IMU} $
and
$ {\boldsymbol{\Phi}}_{IMU} $
are the IMU-predicted GNSS measurements, which can be written as
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn31.png?pub-status=live)
where
$ {\textbf{\textit{p}}}_{r,IMU} $
is the IMU-predicted position calculated by Equation (23).
The EKF process can be described in two steps, the first of which is the prediction step:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn32.png?pub-status=live)
where
$ \hat{\cdot} $
indicates estimated values and
$ {\cdot}^- $
indicates predicted values.
$ {\textbf{\textit{Q}}}_k $
is the covariance matrix of states at the k -th time step. Commonly, we set the initial
$ {\textbf{\textit{Q}}} $
matrix as an infinite diagonal matrix.
The second step of EKF is the update step, which is given as follows:
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_eqn33.png?pub-status=live)
where
$ {\textbf{\textit{K}}}_{k} $
is the Kalman gain.
The tight integration scheme is shown in Fig. 1. The raw data of the GNSS receiver output is first combined with precise corrections and then sent to the integration process. In the GNSS receiver and IMU combined system, IMU measurements always arrive more frequently than from the GNSS receiver. Therefore, the filter must process IMU-only measurements when GNSS data are not available, by just applying the prediction step using Equation (30). When GNSS data arrive, EKF measurement updates will be applied. After updating the integrated state, IMU errors, including the biases and scale factors of the accelerometer and gyroscope, are fed back to the IMU error models and employed to correct the measurements.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig1.png?pub-status=live)
Figure 1. Description of the real-time multi-GNSS PPP/IMU tight integration algorithm.
3.0 EXPERIMENT AND DISCUSSION
A real UAV test was conducted to evaluate the performance of the developed real-time four-constellation GNSS PPP and consumer-grade MEMS IMU integrated system. The test was carried out in an open-sky area at Shanghai Jiao Tong University, China. A SwiftNav PIKSI multi-GNSS receiver was used to collect raw observation and ephemeris data. An ADXRS620+ADXL203 consumer-grade MEMS IMU was used to collect the three-axis specific force and angular velocity. A Raspberry Pi 3B embedded board was employed as a real-time on-board processor. Post-Processed Kinematic (PPK) technology was applied as the UAV reference position. To apply PPK technology, a service from QXWZ (Chinese reference network service provider) was applied.
The time duration of the test was about 1h. The UAV was first placed on the ground waiting for PPP convergence, then it took off at the 46th minute of the test time, and landed at the 53rd minute. The trajectory is shown in Fig. 2. The speed limitation of the UAV is 18m/s, and the average speed during the test was 3m/s. A sky plot of the observable satellites is shown in Fig. 3, where satellites with green trajectories indicate that two frequencies were tracked, while orange trajectories indicate that only one frequency was tracked. Since the GNSS receiver did not support acquisition of the BDS GEO signal, the available satellites of the BDS system are not so abundant.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig2.png?pub-status=live)
Figure 2. The UAV trajectory during the test.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig3.png?pub-status=live)
Figure 3. A sky plot of the observable satellites during the experiment. Satellites with green trajectories indicate that two frequencies were tracked, while orange trajectories indicate that only one frequency was tracked. (a) GPS (b) GLONASS (c) BDS (d) Galileo.
In the data processing, the GNSS data were selected as three groups: BDS, GPS+BDS, GPS+BDS+GLONASS+Galileo. For real-time PPP, BKG NTRIP Client (BNC) software was used to collect correction data from the internet. We also modified the source of BNC to apply four-constellation GNSS PPP and IMU tight integration. A precise stream from CNES (CLK93) was utilised for precise ephemeris correction. Satellites with elevation angles of less than
$ 10^{\circ} $
were deleted to ensure high measurement quality. Satellite PCVs were corrected using the IGS antenna file (igs14.atx). The ZTD of the tropospheric delay was estimated, and other errors were corrected using corresponding precise models. For IMU processing, the biases and scale factors were estimated and corrected when GNSS data were available.
3.1 Open-sky performance
To compare the PPP performance between single- and multi-constellation GNSS, we applied different data processing with the same dataset. Note that the on-board real-time processing was set as the four-constellation GNSS PPP/IMU combination mode, whereas all other modes were processed off-board. The available satellites during this process and the corresponding Position Dilution of Precision (PDOP) are shown in Fig. 4.
The three GNSS modes and three GNSS/IMU integration modes of data processing were conducted using the same settings. The performance comparison in the NEU frame is shown in Fig. 5, and the corresponding RMS value is presented in Table 1. Since PPP needs tens of minutes to achieve convergence whereas only the performance during the flight period is the main focus here, we just take the time range from 46 to 53min to calculate the bias and RMS. The biases of the three direction errors are subtracted to make the plot clearer. Since the PPP bias is related to the quality of the precise orbit and clock, which lies beyond the scope of this article, we do not discuss it in detail. The reader can refer to Ref. [Reference Kazmierski, Sośnica and Hadas23] for more detailed information. The relative statistics are shown in Fig. 6.
According to the results, real-time PPP can provide an accurate position output, with a RMS of less than 0.025m in horizontal and 0.1m in vertical direction, after convergence. By applying two-GNSS PPP, the RMS is reduced by 58.2%, 30.0% and 22.1% for the north, east and up component, respectively, with respect to single-GNSS PPP. The RMS is further reduced by 70.3%, 73.8% and 72.8% when using four-system observation. Besides, PPP/IMU tight integration can provide a smoother position output and achieve a lower RMS. Compared with GNSS-only processing, the combined system reduces the RMS by 2.7%, 8.4% and 3.1% in the three directions respectively, for BDS-only processing. For the two.system case, it decreases by 7.2%, 2.6% and 8.3%, respectively, and for the four-system case, it is reduced by 3.9%, 3.1% and 15.3%, respectively.
To evaluate the performance of the vehicle velocity determination, the velocity error relative to the PPK velocity output is shown in Fig. 7. The corresponding RMS value is presented in Table 2, and the relative statistics are given in Fig. 8. The results show a great improvement when applying multi-GNSS PPP and PPP/IMU tight integration. The two-GNSS PPP reduces the RMS by 40.0%, 43.5% and 43.4% in the north, east and up directions, respectively, with respect to the single-GNSS PPP. The RMS is further reduced by 65.2%, 72.3% and 51.9% when using four-system observation. Besides, by applying PPP/IMU tight integration, the RMS reduces by 40.0%, 35.2% and 57.5% in the three directions respectively, for BDS-only processing. For the two-system case, it decreases by 27.6%, 16.5% and 55.9%, respectively, and for the four-system case, it is reduced by 9.1%, 3.8% and 28.4%, respectively.
Consequently, the performance of real-time PPP can be improved significantly by applying multi-constellation GNSS systems. This is because of the improvement in satellite availability and geometric distribution. PPP/IMU tight integration can smooth the position and velocity output and achieve a lower disturbance, especially for kinematic vehicle motion because of the high short-term precision of the IMU integral.
Table 1 Position RMS of the six modes of data processing (in mm)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_tab1.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig4.png?pub-status=live)
Figure 4. Number of satellites and corresponding PDOP, where 1 Sys, 2 Sys and 4 Sys refer to BDS, GPS+BDS and GPS+BDS+GLONASS+Galileo, respectively.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig5.png?pub-status=live)
Figure 5. Positioning performance comparison of the six modes of data processing. The biases of the three direction errors are subtracted to make the plot clearer. (a) PPP only (b) PPP/IMU integration.
Table 2 Velocity RMS of the six modes of data processing (in mm/s)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_tab2.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig6.png?pub-status=live)
Figure 6. Positioning performance comparison of PPP and PPP/IMU tight integration.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig7.png?pub-status=live)
Figure 7. Velocity determination performance comparison of the six modes of data processing. (a) PPP only (b) PPP/IMU integration.
3.2 GNSS outage simulation
GNSS outage is a common scenario in GNSS positioning, especially for carrier-phase-based processing. Internally, this occurs when the GNSS receiver becomes unlocked for some specific satellites, which leads to cycle slips or phase jumps. Externally, it occurs when a vehicle passes through a bridge, crowded building, canyon etc., which can cause data interruption. Unfortunately, PPP is very vulnerable to GNSS outage. It may divergence after such outage and takes several minutes to re-converge, which could be disastrous for users.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig8.png?pub-status=live)
Figure 8. Velocity determination performance comparison of PPP and PPP/IMU tight integration.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig9.png?pub-status=live)
Figure 9. Positioning performance comparison of PPP and PPP/IMU positioning for outage simulation (10s). (a) PPP only (b) PPP/IMU integration.
Table 3 Position and velocity RMS of the GNSS outage simulation (in mm and mm/s)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_tab3.png?pub-status=live)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig10.png?pub-status=live)
Figure 10. Velocity determination performance comparison of PPP and PPP/IMU positioning for outage simulation (10s). (a) PPP only (b) PPP/IMU integration.
To test the sensitivity of the system to GNSS outage, we simulated an outage by removing all satellites for 10s. The data outage began at 49min and ended at 49.17min. Since this test focused on a comparison between PPP only and the PPP/IMU tight integration system, only the four-system mode and its integration with IMU was utilised. The positioning result is shown in Fig. 9, and the velocity determination result is shown in Fig. 10. The corresponding RMS value is given in Table 3. Note that just the time range from 40 to 65min is plotted.
According to these results, the PPP-only system diverged when suffering an outage, while the PPP/IMU system could maintain a stable position output. The RMS position value for the PPP-only system was 110.7, 259.2 and 887.2mm for the north, east and up direction, respectively, whereas the PPP/IMU tight integration system reduced this to 24.5, 21.4 and 23.3mm for each direction component, corresponding to a 77.9%, 91.8% and 97.4% performance improvement in the three directions, respectively. The RMS velocity value was reduced from 24.3, 41.8 and 156.3mm/s to 5.0, 5.1 and 13.0mm/s in the three directions, corresponding to a 79.6%, 87.9% and 91.7% performance improvement in the three directions, respectively. This is because the position and velocity states of PPP can be estimated and maintained through the IMU short-term accurate position, the tropospheric delay, clock error and frequency drift can be maintained by the system dynamic modelling, and only ambiguities are re-estimated after the outage.
The integration of the IMU measurements leads to position and velocity drift when the period of GNSS outage extends. To test the performance of the PPP/IMU system under a long period of GNSS outage, we further simulated 10–60s of GNSS outage in steps of 10s. The position and velocity drift with respect to the outage period are shown in Fig. 11.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig11.png?pub-status=live)
Figure 11. Position and velocity drift under different GNSS outage durations.
According to Fig. 11, the position and velocity errors increase as the outage period gets longer. The solutions drift little when the outage period is short because the PPP/IMU integration provides a high resolution of IMU biases when the GNSS measurements are sufficient. The drift becomes greater because the variances of the biases increase without correction from the GNSS information. Hence, users should bear this solution drift effect in mind in city or canyon environments where GNSS is not available for long periods. From the control perspective, the speed controller and trajectory controller cannot work without accurate velocity and position feedback. So when large drift occurs, the autopilot system of UAVs may not be reliable. However, the UAV can still land safely with a stand-alone IMU because the basic flight control system can work with only attitude feedback.
3.3 Insufficient GNSS measurement simulation
Besides outages, insufficient GNSS observation also occurs in city and canyon environments, causing the PPP-only system to fail to provide navigation solutions. It is common for satellites to be partially shadowed by tall buildings or cliffs. Hence, it is interesting to discuss the superiority of the proposed algorithm in such situations.
To test the performance of the proposed algorithm in an insufficient observation situation, we applied several azimuth masks to simulation shadowing of satellites, including
$ 240^\circ $
,
$ 300^\circ $
and
$ 360^\circ $
azimuth masks. The
$ 360^\circ $
azimuth mask is equivalent to a GNSS outage. Because the position and velocity showed little drift in the 10-s outage simulation in Section 3.2, we simulate a 30-s azimuth mask in this section to reveal the different performance in the simulations more clearly. The masks began at 49min and ended at 49.50min. The number of satellites is shown in Fig. 12. According to Section 2.1, this situation is insufficient for PPP positioning during the azimuth mask period in all of the groups. The results are shown in Figs 13 and 14. The corresponding RMS value is given in Table 4.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig12.png?pub-status=live)
Figure 12. Number of observed satellites under different azimuth masks (30s).
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig13.png?pub-status=live)
Figure 13. Positioning performance comparison of PPP/IMU positioning under different azimuth masks (30s).
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig14.png?pub-status=live)
Figure 14. Velocity performance comparison of PPP/IMU positioning under different azimuth masks (30s).
Table 4 Position and velocity RMS of the insufficient measurement simulation with different degrees of azimuth masks (in mm and mm/s)
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_tab4.png?pub-status=live)
According to Fig. 12, the number of observed satellites is 4, 2 and 0 for the
$ 240^\circ $
,
$ 300^\circ $
and
$ 360^\circ $
mask, respectively. All of these cases are insufficient for PPP-only positioning. According to Figs 13 and 14 and Table 4, the position and velocity solutions drift dramatically when the
$ 360^\circ $
mask is applied. The filter re-initialises after the 30-s mask because the position error is too large. The system performs better when the
$ 300^\circ $
mask is applied, which provides two observed satellites. Although only two satellites cannot be used in a common PPP filter, they help to shrink the drift rate of the position and velocity solutions in the proposed PPP/IMU system, reducing the RMS of position by 41.9%, 5.6% and 22.1% in the three directions, respectively, and the RMS of velocity by 56.7%, 63.5% and 44.1%, respectively. For the
$ 240^\circ $
mask case, when the number of satellites rises to four, the drift rate of the solutions is further reduced, being 93.2%, 61.2% and 93.9% for position and 97.1%, 90.2% and 86.1% for velocity, respectively.
3.4 Computational load
Computational time is an important characteristic for embedded real-time systems. To study the computation time of the proposed PPP/IMU integration system, we tested the one-, two- and four-system PPP/IMU integration on the raspberry pi 3B platform. The results are shown in Fig. 15.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20201215125343811-0717:S0001924020000809:S0001924020000809_fig15.png?pub-status=live)
Figure 15. Computation time of the proposed PPP/IMU integration algorithm.
According to Fig. 15, the computational time is stable over time steps. The average computation time is 0.55, 0.80 and 1.72ms for one-system, two-system and four-system PPP/IMU integration, respectively. This indicates that the computational load is strongly related to the number of observed satellites. Since the number of satellites influences the precision and convergence speed of the system, there is a trade-off between the computational time and the precision and convergence period. Users are free to decide the priority.
4.0 CONCLUSION
This paper introduces a real-time PPP/IMU tight integration algorithm using multiple GNSS constellations. Models of real-time multi-GNSS PPP, IMU, and their integration are introduced in detail, and experiments were carried out using a four-system GNSS receiver and a consumer-grade MEMS IMU on a UAV with an on-board chip. The results show that the positioning performance can be improved significantly by applying both four-system GNSS measurements and IMU data. The position RMS reduced from 23.8, 23.9 and 83.9mm to 7.1, 6.3 and 22.8mm, with an improvement of 70.3%, 73.8% and 72.8%, for the north, east and up component, respectively, when applying GPS+BDS+GLONASS+Gallileo PPP compared with BDS-only PPP. The RMS was further reduced to 6.8, 6.1 and 19.3mm, corresponding to an improvement of 71.4%, 74.5% and 77.0%, in the three directions respectively when using four-constellation GNSS PPP/IMU tight integration. A 10-s GNSS outage was simulated during flight. The results showed that the PPP-only processing diverged when passing a data outage, taking several minutes to re-converge. By contrast, the tightly coupled system could overcome the outage and provide a continuous position output. The RMS decreased from 110.7, 259.2 and 887.2mm to 24.5, 21.4 and 23.3mm, corresponding to an improvement of 77.9%, 91.8% and 97.4% in the three components, respectively, in this case. To further investigate the drift of the solutions under longer periods of GNSS outage, we simulated outages of 10–60s in steps of 10s. The results showed that both the velocity and position error drift over the outage period. The position error remained under 2.5m while the velocity error remainder under 0.4m/s when the outage period was less than 20s. Moreover, insufficient GNSS measurement was simulated by applying azimuth masks, revealing that a greater number of observed satellites can shrink the rate of solution drift. Finally, a computational load test illustrated that the four-constellation GNSS PPP/IMU integration takes 1.72ms per cycle on average on the raspberry pi 3B platform. The computational time could be shorter if fewer GNSS systems are used. Users are free to decide the trade-off between the computational time and the precision and convergence period.
Consequently, the real-time four-constellation GNSS PPP and consumer-grade MEMS IMU tight integration system can supply an accurate, robust and continuous navigation solution for multiple UAV applications under both open-sky and short-term GNSS-challenged environments.
ACKNOWLEDGEMENTS
This work was supported by Shanghai Jiao Tong University (SJTU) Global Strategic Partnership Fund (2019 SJTU – University of Toronto) and the National Science Foundation of China (no. 61403253). The authors would like to thank IGS centres for providing the precise GNSS correction streams and BKG centre for providing open-source BNC software.
SUPPLEMENTARY MATERIAL
To view supplementary material for this article, please visit https://doi.org/10.1017/aer.2020.80