This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).
The integration of Global Navigation Satellite Systems (GNSS) with Inertial Navigation Systems (INS) has been very actively researched for many years due to the complementary nature of the two systems. In particular, during the last few years the integration with microelectromechanical system (MEMS) inertial measurement units (IMUs) has been investigated. In fact, recent advances in MEMS technology have made possible the development of a new generation of low cost inertial sensors characterized by small size and light weight, which represents an attractive option for massmarket applications such as vehicular and pedestrian navigation. However, whereas there has been much interest in the integration of GPS with a MEMSbased INS, few research studies have been conducted on expanding this application to the revitalized GLONASS system. This paper looks at the benefits of adding GLONASS to existing GPS/INS(MEMS) systems using loose and tight integration strategies. The relative benefits of various constraints are also assessed. Results show that when satellite visibility is poor (approximately 50% solution availability) the benefits of GLONASS are only seen with tight integration algorithms. For more benign environments, a loosely coupled GPS/GLONASS/INS system offers performance comparable to that of a tightly coupled GPS/INS system, but with reduced complexity and development time.
As is well known, urban environments are critical locations for Global Navigation Satellite Systems (GNSS). In such environments, buildings block many of the signals, thus reducing satellite availability and weakening observation geometry, with the extreme case being solution unavailability. Buildings can also reflect signals, causing multipath phenomena which introducs the greatest measurement errors in these areas. Past research on this problem can be broadly classified as focusing on: (a) increasing the number of satellites, usually by including additional GNSS to an existing system, or (b) integrating GNSS with external sensors, most commonly an inertial navigation system (INS).
With a few exceptions, the U.S. Global Positioning System (GPS) has been the primary GNSS since its inception many years ago. The Russian GLONASS system saw some use in the mid to late 1990s before suffering setbacks that plagued the system until the last few years. Nevertheless, the benefits of integrating GLONASS with GPS have been fairly well documented and improvements in measurement and solution availability, accuracy and reliability of positioning, and ambiguity resolution have been shown [
Integrating GNSS with INS has been very actively researched for many years due to the complementary nature of the two systems. In challenging GNSS environments like urban canyons and under foliage, the goal of the INS is to provide a navigation solution during GPS outages. Moreover the integration of GNSS with an inertial navigation system can deliver more robust and reliable systems than either of the individual systems alone [
To this end, use of highend INS is generally limited to high accuracy applications only, owing to their price and size [
The integration of combined GPS/GLONASS with INS was already tested several years ago (e.g., by Lechner
For vehicular navigation in particular, constraints on the vehicle's velocity—known as nonholonomic constraints—can be applied to further improve INS performance [
The primary objective of this paper is to expand the previous work in order to investigate the benefits, if any, of adding GLONASS to GPS/INS (MEMS) systems, specifically for vehicular navigation applications. As part of this, the paper assesses the performance of loose and tight integration algorithms (
With this in mind, the main contributions of the paper are as follows: first, by adding GLONASS to existing GPS/INS systems, the role of the improved satellite availability on system accuracy is assessed in an urban environment. Second, the relative performance of loose and tight integration algorithms is assessed with and without GLONASS. In so doing, it is shown that in some cases the loose integration approach with GLONASS can yield similar performance to the GPSonly case with a tight integration. This information is useful to system designers since loose integration algorithms are generally easier to implement than their tight integration counterparts. Third, the benefit of nonholonomic constraints, GNSSderived yaw aiding, and height constraints are also assessed in the presence of GLONASS to assess their benefits relative to the GPSonly case. Finally, it is worth noting that although the focus is on the role of GLONASS for operational reasons, the results presented should also apply to other upcoming GNSS such as Galileo and/or Compass.
The rest of the paper is organized as follows: first, the relevant theories in the context of this paper are briefly reviewed with focus given to the different integration algorithms (loose
This section gives a brief overview of GPS and GLONASS as well as the inertial sensors used in the final integrated system.
GPS and GLONASS are the main GNSS systems in use today and they are similar in many respects, but with some essential differences. Both systems are able to provide various number of air, marine, and any other type of users with allweather threedimensional positioning, velocity and timing, anywhere in the World or nearEarth space. Both navigation systems are based on the concept of “oneway ranging”, in which the unknown user position is obtained measuring the time of flight of signals broadcasted by satellites at known positions and epochs [
The main difference between the two systems is that GPS and GLONASS operate with different time references and with different coordinate frames [
The great advances in MEMS have made possible the development of a new generation of low cost inertial sensors. MEMS inertial measurement units (IMU), that is, the actual sensor assembly, are characterized by small size, light weight, low cost and low power consumption with respect to higherend inertial sensors. These features make MEMS sensors an attractive option for applications such as vehicular navigation. However, MEMS sensors are also characterized by poorer performance, so they cannot be used in autonomous mode for extended periods although they are well suited for integrated navigation systems (usually coupled with GPS systems) where external measurements can limit their error growth. An IMU usually consists of a triad of accelerometers and gyros, whose measurement equation can be expressed as:
More detailed measurement equations can be found in [
The sensor bias is defined as the average of the output, obtained during a specific period with fixed operational conditions when the input is null. The bias generally consists of two parts: a deterministic part called bias offset or turnon bias and a stochastic part called bias drift or inrun bias. The turnon bias is essentially the offset in the measurement and is constant over a single mission; it has deterministic nature and so can be determined by calibration procedure (or it can be also modeled statistically as a random constant process). The bias drift is the change in the sensor with time; the bias drift has random nature and so must be modeled as a stochastic process. The scale factor error is the ratio between the change in the output signal of the sensor to the change in the measured physical quantity. In ideal conditions the scale factor should be unity. This error has a deterministic nature but generally is modeled as a random process. The inertial sensor errors can be expressed in terms of angular random walk (ARW) and velocity random walk (VRW). The ARW parameter describes the average deviation or error that will occur from integrating the noise on gyro output signal. Similarly the VRW parameter definition is based on the same concept for the accelerometers.
Typical MEMS sensor performance is summarized in the
Before looking at the GNSS/INS integration algorithms, GNSSonly processing is briefly reviewed. To this end, in this work, the GNSS measurements are processed in single point mode, so no differential corrections are applied and the deployment of a reference station is unnecessary. Only pseudorange and Doppler (phase rate) observables are used.
To account for the fact that satellite measurements at low elevation angles are generally noisier [
The GNSS solution is obtained using the WLS (Weighted Least Squares) method, whose equation is:
The states are position, velocity and clock errors. If a single GNSS system is considered (e.g., GPS or GLONASS only) the clock error is modeled by two states: a bias and a drift. If two GNSS are combined (e.g., GPS/GLONASS case) a further state, representing the intersystems time offset, must be included.
GNSS/INS integration is very common because the systems are complementary in many aspects. In particular, INS is more accurate in the short term, it can supply data with very high rate and it can also provide attitude information. On the other hand, GNSS is more accurate in the long term and the error is effectively time invariant. The following sections describe the two most common approaches to integrating GNSS and inertial data, namely loose and tight coupling.
The loose coupling (LC) strategy is also referred to as “decentralized” and includes a Kalman Filter (KF) to combine INS and GNSS parameters. Another KF or a LS estimator is used to compute the GNSS navigation solution. The LC scheme is showed in
To compute the GNSS fix, a LS estimator is preferred herein to simplify a direct LC/TC comparison. Specifically, by using leastsquares for LC, the results will be the same as in the TC case so long as enough satellites are available to compute a solution.
The inertial solution is obtained by applying the mechanization equations for a strapdown configuration to the accelerations and angular rates from the IMU. For this work, the INS mechanization is implemented in the local EastNorthUp (ENU) frame. Details of the mechanization equations are widely available in the literature (e.g., [
The difference between the INS and weighted leastsquares (WLS) GNSS position and velocity are used as input measurements to the KF. The WLS covariance matrix is used as measurements covariance matrix
Implicit in the above is that only the submatrices corresponding to the states being used in the update are extracted from the WLS covariance matrix (details follow shortly).
The state vector of the combined GNSS/INS KF in LC architecture is:
The INS error model (for position, velocity and attitude) is typical of what is widely available in the literature (e.g., [
The tight coupling (TC) strategy is also referred to as “centralized”, because there is only one central KF processing both the GNSS observations and INS data. The TC scheme is showed in
In contrast to the LC case, the difference between the measured and INSpredicted pseudorange and Doppler observables is used as input measurements to KF. The associated measurement covariance matrix is defined taking into account the inherent accuracies of GNSS measurements and the elevationdependent accuracy as in the LC case (see
The TC KF state vector has the same 21 states as for the LC case (see
Both loose and tight strategies are herein implemented in closed loop configuration meaning the navigation, bias and scale factor error states output from the KF are used to correct INS inputs. The closed loop configuration is necessary when low performance INS is used to reduce the inertial error growth [
This section briefly looks at the details of using GNSSderived heading, as well as pseudoobservations of vehicle velocity and height to help improve the overall solution.
A GNSSderived aiding can be used to improve the heading estimation. To incorporate heading measurements into the measurement model of the GNSS/INS filter, an equation relating the heading errors with the system error states is required [
The expression of the azimuth as function of the elements of the matrix
The relationship between estimated and actual rotation matrix from body to ENU frame is
With this in mind the
Computing the differential of the previous equation, the heading error equation is obtained as:
In
The external heading equation can be embedded in the measurement model of the GNSS/INS KF and is used when the horizontal speed of the vehicle is sufficiently high. For this work, this measurement is only used when the vehicle's speed exceeds 5 m/s, as this gave reasonable results. Other thresholds were not investigated, and this is left as future work.
In vehicular navigation one possible approach to mitigate INS error accumulation is to apply constraints based on the motion of the vehicle. In other words, it is possible to generate constraint equations reflecting the behavior of the vehicle during navigation [
In the context of this paper, it is assumed that the vehicle does not slip sideways or jump/bounce such that the motion is essentially in the vehicle's longitudinal direction. The above assumptions constitute the so called nonholonomic constraints and are described mathematically as:
A second constraint equation can be generated considering the fact that the height does not change significantly in land navigation over short time periods. Hence during GNSS outages the height can be considered constant and equal to a reference value
Although this may seem equivalent to the second equation in
Both the nonholonomic constraints and the pseudomeasurements of height can be used as measurement models of a complementary Kalman filter during GNSS outages as shown in
A data collection experiment was carried out in a vehicle in downtown Calgary, Canada on 22 July 2010 in the afternoon around 2:00 pm local time. Downtown Calgary is a typical urban scenario, characterized by skyscrapers and so it is a difficult environment for satellite navigation because of blocking and multipath problems. The total duration of the test is about 23 min; the speed of the vehicle varied from 0–50 km/h with frequent stops due to the traffic lights and the total distance travelled is about 10 km.
The test equipment consists of a satellite receiver and a MEMS IMU (whose specifications are in
The reference solution is obtained using the NovAtel SPAN (Synchronized Position Attitude Navigation), an integrated system consisting of the OEM4 NovAtel receiver and the HG1700 tactical grade IMU. The SPAN data are processed by NovAtel's Inertial Explorer software using phase and Doppler measurements in double difference mode. The baseline separation (relative to a base station located on the University of Calgary campus) varied between 6–7 km. The reference solution accuracy in these conditions is summarized in
To facilitate the data analysis, three segments of the trajectory, representing different operational scenarios, are considered and examined separately. The visibility and GDOP behavior is shown in
The main features of the GNSS coverage during all segments are summarized in
The segment 1 started in a parking lot where the satellite visibility was good and the operational conditions can be considered semiopen sky (4–10 visible GPS satellites). The second part of the segment 1 was in a demanding urban canyon with poor satellite coverage (0–6 available GPS satellites). The satellite visibility in the GPSonly and GPS/GLONASS cases is shown in
Segment 2 represents a very difficult scenario. The number of visible GPS satellites on the trajectory is presented in
Segment 3 represents a more benign scenario where the number of visible GPS satellites during the trajectory is presented in
As mentioned before, the primary objective of this work was to compare the performance of GPS and GPS/GLONASS integrated with low cost INS with a particular focus on assessing the benefits of including GLONASS. Both loose and tight integration strategies are tested to determine if the type of integration plays a significant role. The pseudomeasurements based on assumptions about the typical vehicular behavior are included in both integration architectures to assess the effectiveness in this context, as are GNSSderived yaw observations.
To this purpose, several processing configurations are considered. The baseline configuration in the loose and tight integration cases are based on GPS alone and are respectively denoted as “LC GPS/INS” and “TC GPS/INS”. Similarly, the inclusion of GLONASS is denoted as “LC GG/INS” and “TC GG/INS”. The use of constraints are denoted by appending a Y (GNSSderived yaw), V (velocity pseudomeasurement) and H (height pseudomeasurement). For example, LC GG/INS YVH represents the loosely couple GPS/GLONASS solution with all three constraints applied.
In
The contribution of various combinations of constraints to the position solution is summarized in
In
In
The performance of different TC configurations, in terms of RMS and maximum position errors, is summarized in
The trajectories obtained with the different TC approaches for this scenario are shown in
The trajectories obtained with the different TC approaches for this scenario are presented in
This section compares the loose and tight solutions for the different segments of the test.
To better perform a comparison among the analyzed configurations with LC and TC architectures, the RMS errors of position, velocity and attitude are presented in
in the baseline GPS/INS integration, TC architecture provides significantly better horizontal solution and similar altitude result than LC, as expected and as shown in previous work;
including GLONASS observations provides meaningful performance improvements for both LC and TC architectures in terms of position, velocity and azimuth estimation;
in case of GPS/GLONASS without other aiding, the TC architecture provides only slightly better solution relative to the LC case;
the loosely coupled GPS/GLONASS and tight coupled GPSonly configurations (no other aiding) provide very similar performance;
including GNSSderided azimuth aiding and velocity/height constraints produces significant improvements for both the LC and TC cases in terms of position, velocity and azimuth;
the results obtained with using loose and tight integration for the GG/INS YVH configurations are very similar.
The practical consequences of the above considerations are twofold. First, in this type of environment, the loosely coupled GPS/GLONASS configuration could replace the tightly coupled GPSonly configuration without performance degradation. Such an approach is simpler to implement thus saving development costs. Furthermore, the GNSSonly solution (
The RMS errors of LC and TC architectures for segment 2 are presented in
The LC architecture does not provide satisfying performance for each tested configuration (with GPS and GLONASS or with motion constraints), showing large errors during GNSS outages;
The TC architecture shows better performance relative to LC architecture for each tested configuration;
Including GLONASS observations provides slight performance improvements for TC architecture in terms of position, velocity and azimuth estimation;
Including the GNSSderived yaw aiding and velocity and height constraints in the TC GG/INS configuration improves the position, velocity and azimuth estimation.
From these results, unlike in segment 1, it is clear that a tight integration is still preferred since it offers significantly better performance overall.
The RMS errors of LC and TC architectures for this segment are shown in
In this relatively benign scenario the position performance of all the considered configurations are very similar;
Including GLONASS observations for both LC and TC architectures provides slight improvements in terms of position and velocity;
Including GNSSderived yaw aiding and velocity/height constraints yields the reduction of velocity and azimuth errors, but no benefits in position RMS errors.
As with segment 1, these findings suggest that using a GPS/GLONASS receiver in a LC system should yield results similar to the TC case, but with a simpler system and reduced development time.
To assess the overall performance of the considered configurations, the RMS errors for the three segments are shown in
This work looks at the benefit of including GLONASS in integrated GPS/INS systems, especially in urban canyon environments. The effect of using different vehicle motion constraints was also considered. Data was collected in downtown Calgary and processed using various configurations. For the data analyzed herein, the main conclusions are as follows:
In environments where satellite visibility is insufficient for standalone GNSS positioning approximately 50% of the time, the benefits of GLONASS are minimal in a loosely coupled implementation. However, in a tightly coupled implementation, GLONASS provides considerable improvements. In this respect, these results are similar to previous results obtained with GPS/INS systems.
In environments when standalone GNSS positioning is possible 70% of time or more, inclusion of GLONASS in a loose integration provides similar performance to the GPSonly tight coupling system. This suggests that a simpler system is possible without sacrificing navigation performance simply by adding GLONASS measurements. In turn, this has direct benefits to system development time and cost.
In benign environments where GNSS solutions are available most of the time, including GLONASS provides little benefit since the system is already dominated by the GNSS errors since freeinertial navigation is unnecessary.
Including the GNSSderived azimuth aiding and the velocity/height pseudoobservations produces significant performance improvements regardless of the integration strategy. Furthermore, results are quite similar between the loose and tight integrations in this case, thus further blurring the benefits of the tight integration approach.
Based on these results, inclusion of GLONASS observations does offer some significant advantages over GPSonly integrated systems. Although not quantified here, similar results would also be expected by including data from other GNSS as well (e.g., Galileo).
Loosely coupled scheme.
Tightly coupled scheme.
Velocity/height constraints aiding scheme.
Equipment.
Test trajectory (from Google Earth).
Visibility and GDOP during the test.
GNSS visibility on the Segment 1 trajectory.
GNSS visibility on the Segment 2 trajectory.
GNSS visibility on the Segment 3 trajectory.
Trajectories obtained with the loose coupling approach (Segment 1).
Trajectories obtained with the loose coupling approach (Segment 2).
Trajectories obtained with the loose coupling approach (Segment 3).
Trajectories obtained with the tight coupling approach (Segment 1).
Trajectories obtained with the tight coupling approach (Segment 2).
Trajectories obtained with the tight coupling approach (Segment 3).
Comparison between LC and TC architectures in terms of position, velocity and attitude RMS errors (Segment 1).
Comparison between LC and TC architectures in terms of position, velocity and attitude RMS errors (Segment 2).
Comparison between LC and TC architectures in terms of position, velocity and attitude RMS errors (Segment 3).
Summary of IMU characteristics for different grades of sensors (from [
 

InRun Bias (mg)  0.025  1  2.5 
TurnOn Bias (mg)      30 
Scale Factor (PPM)  100  300  10,000 
VRW (g/√Hz)    2.16e−06  370e−06 
 
InRun Bias (°/h)  0.0022  1  <1,040 
TurnOn Bias (°/h)      5,400 
Scale Factor (PPM)  5  150  10,000 
ARW (°/h/√Hz)  6.92  7.5  226.8 
Approx. Cost  >$90,000  >$20,000  <$2,000 
Crista IMU random noise spectral density and GaussMarkov parameters.
 


 
0.0077  270  10,000  18,000  300e−6  192  350  10,000  18,000  220 
Reference solution accuracy.
Position  dm level 
Velocity  cm/s level 
Attitude  <1 deg 
GNSS availability and outage duration.
1  GPS  73%  60 s 
GPS/GLONASS  81%  30 s  
2  GPS  53%  60 s 
GPS/GLONASS  55%  60 s  
3  GPS  81%  10 s 
GPS/GLONASS  86%  8 s 
Position error obtained with LC configurations.
 

 
LC GPS/INS  48.4  48.7  16.3  347.0  341.2  48.0 
LC GG/INS  20.2  15.0  8.0  109.6  51.2  34.4 
LC GG/INS Y  15.0  12.9  7.6  80.1  48.2  33.1 
LC GG/INS YV  8.1  6.6  3.8  41.9  40.0  8.8 
LC GG/INS YVH  7.9  5.6  3.9  33.9  20.5  6.3 
Position error obtained with TC configurations.
 

 
TC GPS/INS  14.1  20.4  13.3  61.4  70.1  55.7 
TC GG/INS  8.2  12.9  13.0  61.1  69.7  46.4 
TC GG/INS YVH  4.8  9.5  4.0  18.4  30.5  6.4 
Performance comparison between LC and TC configurations for the three segments.
 

 
LC GPS/INS  37.8  72.2  20.8  3.30  4.06  0.68  1.9  2.5  41.2 
LC GG/INS  36.6  41.0  17.3  2.24  2.41  0.63  1.8  2.5  33.8 
LC GG/INS YVH  37.1  42.5  3.2  2.14  2.41  0.10  1.1  1.1  16.0 
TC GPS/INS  11.8  18.4  15.8  1.08  1.44  0.57  2.2  1.5  33.9 
TC GG/INS  8.6  13.8  14.1  0.84  1.03  0.47  1.6  1.8  27.8 
TC GG/INS YVH  6.2  13.5  4.1  0.41  0.87  0.11  1.0  1.0  8.4 