AESM Paper

ABSTRACT

This paper addresses the question: "Why aren’t tightly-coupled GPS/INS systems everywhere, on aircraft, ships and land vehicles?" Two barriers to the widespread use are cited. One is the high cost of the INS, and the other is the cost and complexity of tightly-coupled GPS/INS integration. One of those two barriers has recently been diminished drastically with the development of a standardized software package for tightly-coupled integration. In the past, only the largest corporations have been able to pay the initial development cost for tightly-coupled GPS/INS integration. Using the new software package, integration and van test can be accomplished in a matter of days, and this has been demonstrated with field trials. The package is intended primarily for small companies that otherwise would not be able to build tightly-coupled GPS/INS systems at all. What would have been a prohibitive 3- or 4-man year development effort is reduced to a few man weeks. To accomplish an integration, the system integrator has to find a way, through serial interfaces or by some other means, to get the INS measurements of acceleration (accumulated velocity change DV) and attitude rate (accumulated angle change Dq ) into a processor, along with the raw data of a GPS receiver. He or she also has to find a way to time tag the INS DV, Dq with GPS time. The rest of tightly-coupled GPS/INS integration is predominately accomplished in the standardized software package. That leaves the cost of the INS as the only remaining barrier to the very widespread use of GPS/INS, and invites new development of low cost inertial sensors. The focus of this paper is on the software package, and how it achieves standardization and ease of use while retaining the flexibility to produce optimal results with a variety of INS and GPS receiver types.

INTRODUCTION

It has been recognized for decades [1] that tightly-coupled GPS/INS (TCGI) performance is superior to loosely-coupled, but for years the challenge of integrating components was found to be so difficult that, today, most GPS/INS systems are loosely-coupled simply because they are easier to build. The tightly-coupled systems combine the disparate raw data of GPS and INS sensors in a single, optimum Kalman filter, rather than cascading two filters, one for each sensor. Also, in some TCGI systems the inertial information is fed back into the receiver so that the receiver can track through increased noise and dynamics. Owing to greater synergism of elements, the tightly-coupled systems are significantly more accurate, robust, jam-resistant, and less costly, [2] but tend to be complex, inflexible, and hard to build. That difficulty, combined with the high cost of an inertial navigation system (INS) or inertial measurement unit (IMU), has dampened the widespread use of TCGI systems.

To address that problem the author worked out an approach to speeding up and simplifying the integration, [3] and presented the approach at the IEEE Position Location and Navigation Symposium in 1992. The following year a TCGI prototype was built using the idea, and then van tested. The resulting proof of concept was reported [4,5] at the Institute of Navigation and the Central Inertial Guidance Test Facility in 1993. In September 1995, a software package called GINI was introduced that implements the approach, and makes it easy for systems integrators to build TCGI systems. GINI consists of an object library of C-language functions that can be built into GPS/INS products and data-processing utilities. The library offers standardization of the TCGI integration process, ease of use, rapid turnaround, flexibility, and optimal performance. Several applications using GINI have been developed, although, a demonstration involving receiver aiding has not been done yet, and none is in progress as of this writing. The rest of this paper describes the GINI approach to integration, reviews the proof-of-concept demonstration, describes the GINI library, and explains what a system integrator has to do to use it. The essence of the approach is finding practical ways to introduce modularity into systems that seemed either hopelessly interwoven or else impossible to integrate at all.

PURPOSE AND APPROACH

The reasons for modularity are compelling. If it were possible to develop a TCGI system by mixing and matching modules, as if choosing receivers, inertial systems, and navigation algorithms from a menu, the task of integration would be drastically simplified. Once a system was built it could be changed by substituting other modules. The system integration would be simplified by dividing technical challenges into smaller pieces that are easier to manage, by hiding information within modules so that the way a module does its job is transparent to the rest of the system, and by localizing the effects of mode transitions so that a state change in one subsystem does not cause a transient in another. Finally, it would reduce the cost of integration both directly by shortening the time required to get a product to market, and indirectly by allowing an evolutionary approach to system development.

The goals of modularity and tight coupling are in conflict. Modularity is generally facilitated if the exchanges between subsystems can be boiled down to a few simple connections, where a low data rate can be used, where round-off errors and small timing errors are acceptable, and where the data are allowed to be half a second stale going across an interface. Those are the advantages of loose coupling. Tight coupling requires precise, high-rate data exchanges, and exacting synchronization of subsystems.

Nevertheless, it was concluded [3] in 1992 that modularity was possible within families of products that adhere to a shared interface protocol. Since that time, the concept has been broadened and generalized. Instead of "families of products," the concept is more nearly described by a set of requirements placed on the sensors to be compatible. Those requirements are:

GPS receiver

Able to navigate autonomously.
Measure the ranges and carrier phase simultaneously at regular epochs, typically 1 Hz.
Output ranges, carrier phase, raw ephemeris, position, velocity, accuracy statistics, and status.
Time tag the receiver’s data, and support time tagging of INS data, with GPS time.
Allow the receiver clock to float.
If the receiver will be INS-aided, then make provision for applying GINI-computed signal Doppler, and for adjusting receiver bandwidth to accommodate INS error.

INS or IMU

Self-moding and control after application of power.
Generate and output conventional DV, Dq . (delta-Velocity, delta-Angle)
Sample DV, Dq simultaneously at regular epochs, typically 100 Hz or higher.
Compensate DV, Dq as necessary to achieve the advertised accuracy.
Support time tagging of DV, Dq accumulation intervals with GPS time, generally to within a small fraction of a millisecond.

Additionally, if a navigation-grade INS is used:

Provide attitude output.
Navigate autonomously.

As originally conceived, the INS DV, Dq accumulation intervals were to be controlled from the GPS receiver’s clock, so that the INS divides a receiver one-second interval into a hundred 10 msec intervals. That remains a preferred option, but the concept has been generalized to allow the two sensors to be asynchronous, as long as INS DV, Dq accumulation intervals can be accurately tagged with GPS time.

The figure (below) shows a functional block diagram of the TCGI system, with inertial, GPS, and software elements. Notice that the figure is a functional diagram, meaning that nothing constrains where or how the functions are implemented. The GPS receiver might be embedded in the INS physical housing, and GINI might very well be hosted in either the receiver or INS processor.

The approach is not a panacea. Drawbacks of the approach are: reduced fault tolerance, requirements placed on sensors to be compatible, and adaptation.

Fault tolerance

Tightly-coupled systems are inherently less fault tolerant than loosely coupled, because the tight coupling means that a failure in one element is more likely to affect other elements. To address that concern, the receiver and INS are required to function as autonomous navigators, and then their raw data are optimally combined in a third navigation solution by GINI. There is then no single-point failure that can hobble all three navigation solutions, although, an INS failure would leave the receiver unaided. The requirement to navigate autonomously also means that the sensor manufacturers can apply a great deal of testing independently of any integration, and can release a product that is well understood within their own realm of expertise. A receiver that can navigate autonomously is obviously working and doing most of the things needed to support a TCGI integration.

Requirements placed on sensors

The toughest requirements involve timing and making the sensors’ raw data available for output. Clearly, it is not possible to connect just any INS with just any receiver, especially among older sensors that were only intended to operate as stand-alone elements of federated systems, or present-day inexpensive sensors that simply lack the outputs. If the GPS receiver’s raw data are decrypted and can’t be allowed outside the receiver’s processor, then GINI moves into the receiver’s processor, (where it remains functionally distinct from receiver software.) Memory and throughput requirements are described below.

The requirement for the receiver’s clock to float, rather than be driven toward GPS time, enables the navigation Kalman filter to predict the clock’s behavior. That predictability is key to a major TCGI performance advantage; It is possible [6] for the TCGI to operate in a poor signal environment where GPS signals are only momentarily and infrequently available, and yet perform almost as well as in an environment where the signals are fully and continuously available.

As for adaptation, the aspects of TCGI that are most resistant to modularity are: achieving optimal performance with varying INS and IMU types, and adjusting the finite state logic.

Optimal performance

There can be a wide diversity among receiver types, but to GINI the differences all boil down to data volume and statistics of performance. That makes it easy to achieve commonality among receiver types. Achieving commonality among INS and IMU types, though, is not as easy. One approach would be to dump enough (modeled) process noise into the navigation filter that the distinction between sensor types would be blurred. That would achieve commonality at the expense of performance. The optimal approach used by GINI is to take the same INS or IMU error model that would be used in a Monte Carlo simulation, and then probe that model so that GINI designs its own Kalman Q algorithm during a startup procedure. It is much easier for a user to supply an error model than to tune a Kalman filter. Historically, the biggest problem that has been encountered in maintaining filter software has been that the filter has to be re-tuned for each new application. With GINI’s approach, it is only necessary to provide a new sensor error model, and the filter tunes itself.

Finite state logic

If one system requires transfer alignment and another doesn’t, then something has to be different between those two systems, and there is no point around which to form commonality. The GINI solution is to provide a library of functions, and allow users to build systems by plugging functions together according to need. That means that the face put on the system is primarily up to the system integrator. For example, the integrator may develop some special augmentation techniques, work out a way to resolve carrier cycle ambiguities in real-time, and blend that with an integrity monitoring algorithm, resulting in an overall system that exhibits a new level of synergism and unique, distinguishing characteristics. But as far as GINI is concerned, the range measurements simply became more accurate. GINI doesn’t need to know how that improvement was achieved. In keeping with modularity, GINI is itself a module.

PROOF OF CONCEPT

Van testing of an early GINI prototype was accomplished in a collaboration with Allen Osborne Associates in Westlake Village, Calif., and Inertial Science, Inc., in Newbury Park, Calif. An INS and a receiver were placed inside a van, and then driven onto rural highways. A single wire was all that was necessary to connect the receiver and INS, demonstrating the simplicity of the GINI integration approach. Contributors to the proof of concept each spent a few days on the effort, demonstrating the reduction in TCGI development time. GPS and INS data were recorded on floppy disks, and then post processed. It was determined [4,5] that the equipment and integration software worked perfectly through tests of functionality, open-loop tests, tests of measurement residuals, tests of filter corrections to the INS, and tests of convergence of the GPS data on the TCGI solution. All the tests passed as expected.

GINI DESCRIPTION

Major GINI functions are: strapdown navigation, satellite orbital calculations, Kalman filtering, and receiver aiding. GINI will interface with a strapdown inertial system, but not a gimbaled. Gyro quality can be anything from 0.001° /hr to 30° /hr; GINI forms the optimal solution with whatever sensors it has to work with.

High speed navigation

The TCGI solution for position, velocity, and attitude can be accessed at rates up to the INS DV, Dq rate. Output formats include latitude/longitude, earth-centered coordinates, range XYZ, speed/track/climb, east/north/up velocity, roll/pitch/heading, and attitude direction cosines. All output data can be made available at the last data capture event, receiver measurement, or INS DV, Dq. The navigation solution can be referenced to any point on the vehicle. The equations of motion use the exact, ellipsoidal, rotating earth model of the World Geodetic System, 1984. A wander-azimuth mechanization is used for numerical accuracy. Sculling compensation is applied if not already done in the INS, and an 8th-order Bortz attitude formulation is used.

Kalman filter

Nominally, the filter tracks 20 states, (or elements of error,) in position, velocity, attitude, gyro drift, accelerometer bias, clock effects, and lever arm. The filter can process the pseudorange and carrier phase data of up to 12 satellites at once, using a Bierman factorization for numerical stability. The filter adapts to processor load, meaning that if the processor hasn’t finished with the previous filter cycle by the time a new cycle would normally begin, then the filter can hold off for another second or two. A full state transition model is used to describe the evolution of navigation effects, including the Schuler 84-minute loop, Coriolis terms, earth 24-hour loop, and higher-order effects. GINI is tolerant of non-linearities and poor a-priori assumptions, and will converge under dynamics with initial roll, pitch, and azimuth errors of up to 60° . Additional sensors, such as barometric altimeters and Doppler radars are not present in GINI, as of this writing, but the hooks are present for quickly adding them.

Satellite orbital calculations

GINI computes satellite positions and ranges. The range computations include satellite clock error, equipment group delay, relativistic effects, and tropospheric delay. GINI maintains a library of packed ephemeris, both the current and preceding issue, for all 24 satellites. Unpacked ephemeris is maintained for up to 12 satellites at once. Satellite ephemeris is provided to GINI in the form of packed data obtained directly from receiver demodulation of satellite broadcasts, with parity and checksum bits removed. GINI will accept the information in binary or ASCII, with 8 or 10 words per subframe, and in natural or permuted byte order. In van testing, (accomplished just before SA/AS was turned on,) the differences between calculated and measured ranges were 23 cm RMS for (augmented P-code) pseudoranges, and 1.5 mm for differenced carrier phase, [4] with a base-station separation of 10 miles, validating the satellite orbital software.

Receiver aiding

One of the primary goals of modularity is to isolate the effect of mode transitions, so that a state change in one subsystem does not cause a hiccup in another. The GINI approach to receiver aiding achieves that goal by mapping INS DV, Dq to receiver frequency increments, DD (delta-Doppler). All the receiver then has to do is add up a long string of DD to have GPS signal Doppler at any given time. The mapping is insensitive to system events, so in keeping with modularity, the receiver doesn’t even notice the cutover to a new issue of ephemeris. The computed range, range rate, and DD, for up to 12 satellites at once and with multiple GPS antennas, are all provided to the receiver, typically at 100 Hz. When required, the receiver can use the aiding information to continue tracking the GPS code signal under conditions that are too noisy to track the GPS carrier signal, or to know exactly where to look in phase and frequency for a signal that has temporarily vanished.

Written in C

GINI is a number cruncher without complicated system requirements. It is written in a subset of plain C. When configured as a static library, the GINI executable requires about 130 Kb of computer memory. Throughput varies, but a typical configuration with a 20-state Kalman filter requires less than 1% of computing capacity of a current IBM-style PC.

WHAT THE USER HAS TO DO

Briefly, the user has to bring GPS and INS data into a processor where GINI will reside, assemble the information into data structures defined in GINI header files, and then call GINI functions in a time-ordered sequence. A 100-page users manual is provided. [7] The user then calls other GINI functions to access the TCGI navigation results, and to monitor performance. Receiver measurements of range and carrier phase have to be edited to remove erroneous information, and GINI functions are provided to support the user’s editing policy.

Probably the toughest single challenge the system integrator will face is time tagging INS DV, Dq accumulation intervals with GPS time, accurate to a small fraction of a millisecond. The receiver can easily time tag its own data to microsecond accuracy. If a camera or geographic data collection system is involved, then the data capture events have to be tagged with GPS time and flagged in GINI input buffers. If a full real-time system is envisioned, then a real-time executive is required that allocates up to two simultaneous task levels to GINI, typically 100 Hz and 0.5 Hz. The inertial information, and data capture times and flags, have to be moved to GINI input buffers within milliseconds, although, half-second delays are acceptable in getting receiver data to GINI. If a near-real-time or post-processing mode will be used instead, then a real-time executive is not required, GINI functions all merge into a single task level, and latency requirements are relaxed.

Most users will not need receiver aiding, but if it is needed, then the receiver has to be modified to apply the aiding information. The system integrator will be involved with the data transport, receiver moding, receiver bandwidth selection, and system stability issues.

CONCLUSION

The significance of this work is that tightly-coupled GPS/INS systems are becoming much easier to design, assemble, test, and modify. An approach that speeds up the integration has been worked through, published, proved in field trials, and made generally available to systems integrators in the form of a software library.

REFERENCES

[1] D. B. Cox, Jr., "Integration of GPS with Inertial Navigation Systems," Navigation, Journal of the Institute of Navigation, 1978.

[2] Z. H. Lewantowicz, "Architectures and GPS/INS Integration: Impact on Mission Accomplishment," Proceedings of IEEE PLANS, Position Location and Navigation Symposium, 1992, pp. 284-289.

[3] D. T. Knight, "Achieving Modularity with Tightly-Coupled GPS/INS", Proceedings of IEEE PLANS, Position Location and Navigation Symposium, 1992, pp. 426-432.

[4] D. T. Knight, A. W. Osborne, R. W. Snow, and D. G. Kim, "Demonstration of a New Tightly-Coupled GPS/INS," Proceedings of the Sixth International Technical Meeting, Institute of Navigation, Salt Lake City, Utah, September 22-24, 1993, pp. 205-214.

[5] D. T. Knight, A. W. Osborne, R. W. Snow, and D. G. Kim, "Test and Evaluation of a New Tightly-Coupled GPS/INS," AFDTC-TR-93-06 Vol. I, Sixteenth Biennial Guidance Test Symposium, Central Inertial Guidance Test Facility, Guidance Test Division, Holloman AFB, New Mexico, Oct. 5-7, 1993 pp. 159-166.

[6] Z. H. Lewantowicz, and D. W. Keen, "Graceful Degradation of GPS/INS Performance With Fewer than Four Satellites," Proceedings, Institute of Navigation, National Technical Meeting, January 1991.

[7] D. T. Knight, GINI Version 2.1User Manual, September 8, 1998.

[ Home | GPS/INS Integration | Products & Services | Contents | Contact ]