Although Global Navigation Satellite Systems (GNSS) technology is developing rapidly, the major disadvantage of GNSS will still exist even when the European Galileo system is fully operational, that is, signal blockage due to obstructions and the low power of the signals. The combination of GNSS with a self-contained inertial navigation system (INS) provides an ideal solution, which can not only address the weakness of GNSS and but also bound the INS error that grows with the time when operating on its own. The integrated system can provide a continuous position, velocity and attitude solution at a high output rate even during a GNSS outage, albeit for a limited period. These advantages drive GNSS/INS integration in military and civil applications (Buck etal 2006, Kennedy etal 2006).

A multisensor integration platform based on a field programmable gate array (FPGA) has been developed at the Satellite Navigation and Positioning Laboratory (SNAPlab), School of Surveying & Spatial Information Systems, University of New South Wales. The biggest advantage of the FPGA-based system is that all the hardware and software components of the system are field re-programmable without any hardware changes, with even the processor of the system itself being “soft”. A “hardcopy” FPGA can be made after the system has been sufficiently tested.



An FPGA is an integrated circuit capable of implementing digital circuits by means of a configuration process. The designer can use it to implement the specified logic (Hidalgo 2003, Meyer-Baese 2001). Two major hardware description languages (HDLs) are popularly used for the FPGA design today, namely Verilog and VHDL, both of which are IEEE standards. The authors have used the Altera HDL “AHDL” for most of the design.

Figure 1 illustrates the system architecture of a typical setup of a real-time GPS/ INS integrated system. As shown in Figure 1, the GPS and INS data are fed into the FPGA system where the realtime Kalman filter estimates the INS errors that are then used to correct the INS solution. The corrected solution is sent to a field computer on which a geographic information system (GIS) runs. The INS solution can then be plotted onto a map or visualised on the GIS platform. The solution and data collected in the field is sent to a command or monitoring centre via a wireless communication link, i.e. wireless internet, or the mobile phone network. High-level commands or decisions can be made by the centre on the basis of the real-time information that is received. In comparison with postprocessing systems, real-time systems can respond to urgent events promptly, with minimum delay. This is vital in, for example, emergency service applications.<

Hardware
The real-time system is built around the Nios II soft-core on a Stratix EP1s10 device. The GPS pulse-persecond (PPS) signal is required for the time synchronisation process and is connected to the prototype device via a BNC socket. The device is currently configured with four UARTs, two of them for INS and GPS input, and another two for integration result output. The device has an LCD screen for menu and status information display and four buttons for option selection and operation control.

Custom designed logic has been developed for the FPGA to provide count stamping on the incoming serial data streams. The processor logic residing in the FPGA chip hosts the application software that interfaces with the user and controls the custom logic and Compact Flash card operations (Altera 2005). The hardware design file and the firmware are downloaded to the flash memory (AMD AM29LV065D). When power is applied to the board, a configuration controller deviceattempts to configure the FPGA with hardware configuration data stored in flash memory. Figure 2 shows the hardware box of the system.

The INS used is Boeing’s C-MIGITS II, a so-called tactical grade inertial measurement unit (IMU) that provides raw inertial data (Boeing 1997). An OmniStar- HP8200 GPS receiver is used to provide the PPS signal and the GPS navigation solution. The main specifications of the realtime system are listed in Table 1.

A specified UART has been designed for the time synchronisation of the GPS and INS data. This “time-sync UART” logic is attached to the processor as a memory-mapped peripheral with one interrupt line (Mumford etal 2006).
The UART must detect transmission, receive the data in serial format, strip off the start- and stop-bits, and store the data word in a parallel format, as well as access a free-running counter that is latched at the start bit of a serial transmission. This count is appended to the incoming byte and placed in a first-in-first-out (FIFO) buffer. The PPS signal along with GPS time data are used in an interpolation algorithm to calculate the time-of-arrival of serial data from the INS. As a result, the INS data is time-tagged with GPS time, and therefore the INS data is available for comparison with the GPS data in the GPS time frame.

Software
The embedded software is developed using a special version of the Embedded Configurable Operating System (eCos) – ‘the eCos for Nios II’, which provides support of the FAT32 file I/O for the Compact Flash (CF) card, multi-task programming, LCD display, and interrupts from UARTs and buttons (Massa 2002, Nios Community Forum 2005).

The operations of the program are depicted in Figure 3. The software consists of four threads, which are the user interface (UI), time synchronisation (TS), strapdown INS (SDINS), and Kalman filtering (KF). The system first allocates the memory for the circular buffers, and commands the GPS and INS devices to output the requested messages. The ISR of UART event notifies the UI or TS thread to drain the data from the UART FIFO buffer and performs the decoding procedure to covert the binary stream to the data messages. The TS procedure aligns the IMU data with the GPS time frame so that comparison of the IMU and GPS data is possible. The strapdown navigation solution is calculated from the timesynced IMU data. Using the GPS data, the Kalman filter further estimates the errors in the inertial solution (due to the inertial sensors). The error estimates are used to correct the inertial solution and improve the result. The corrected INS solution is sent to the external world via a UART port. Meanwhile the system stores the timesynced IMU data and GPS data together with the corrected inertial solution onto the CF card for replay or post-processing.

The corrected navigation solution is sent out in a pre-defined format to an external device, e.g. a handheld computer, where a program runs to receive the solution and send it to GoogleEarth via the internet. The “.kml” file describes the server address on the internet to which the client sends the data. By linking to the address, the position of the host platform can be monitored on any PC in the command/monitor center using the GoogleEarth viewer. Figure 4 depicts a screen copy of a test at the top of the building in which the SNAPlab is located. Using the real-time GPS/INS solution, GoogleEarth automatically zooms in to the area around the SNAPlab building.

Algorithm

Long-term testing of the real-time performance of the system has been conducted in the laboratory. The focus of testing included stability of the multithreaded firmware, real-time decoding of the GPS and INS data messages, realtime time synchronisation, multiplestage circular buffering, float-pointing calculation, stability of the Kalman filter, button interrupts and response, CF file I/O, data output through additional UARTs, and interfacing with GoogleEarth.
With the 50MHz system design, the timing resolution of the counter is 5.12µs. To compare the time derived by the FPGA device with the time of the INS output, the FPGA-based system has demonstrated timesync accuracy of better than 0.3ms. The system has potentially higher accuracy because it can reveal the C-MIGITS II’s 10µs/sec clock drift, as analysed in Li et al (2006).

Static test

Van test