International Global Navigation Satellite Systems Society IGNSS Symposium 2006 Holiday Inn Surfers Paradise, Australia 17 – 21 July 2006
A time-synchronisation device for tightly coupled GPS/INS integration P Mumford, Y Li, J Wang, W Ding Surveying & SIS, UNSW
[email protected] [email protected] [email protected] [email protected]
Presenter P. J. Mumford ABSTRACT To successfully integrate data from navigation devices and other sensors, reference time stamps are required in the collected data. While this can be achieved relatively easily for devices that provide timing pulses, it is more difficult in the general case when only serial data streams with no reference time stamps are available. The time-synchronization device presented in this paper is being developed as part of the Cooperative Research Centre for Spatial Information (CRC.SI 1.3) "Integrated Positioning and Georeferencing Platform" project. The device uses the precise one-second timing pulse from a GPS receiver as reference to time-stamp incoming serial data streams. The data is then logged to a compact flash card for post-processing on a computer workstation. The hardware used in the device is based around an Altera Field Programmable Gate Array (FPGA) development board, with custom logic and a Nios soft-core processor that do most of the work residing in an Altera FPGA chip. The firmware is built around the Embedded Configurable Operating System (eCos) real-time operating system, which supports compact flash access and multi-thread applications. Testing of the device with GPS and INS sensors has revealed good results and reliable performance. The test setup and results are presented in this paper. In addition, the hardware design is described and an overview of the
firmware is provided. Further development is planed to enhance functionality and the user interface and to move some of the post-processing functions onto the device. KEYWORDS: time synchronisation, tightly coupled integration, GPS, INS
1. INTRODUCTION The time synchronisation data logging device (henceforth “the device”) was conceived as a convenient way to collect INS and GPS data for post-processing (Kalman filter) software under development. Without such a device, typically a laptop computer with a multi-purpose data acquisition card would be used to collect data and provide time-synchronisation services. The possibilities of supporting other sensors such as CCD cameras, and running the Kalman filter software in real time on the device soon became apparent. With these possibilities in mind, the device was developed with provisions for hardware expansion, and with a RealTime Operating System (RTOS) that would facilitate multi-thread applications. It this paper, the design of the device will be examined from both the hardware and software aspects. Following this, a testing methodology and initial results will be presented. Finally some comments on future likely developments will be provided. 2. The time-sync data logging device
Figure 1. The prototype device 2.1 Overview
The prototype device as shown in Figure 1 consists of a metal box with a user interface on the front, serial ports, a PPS and power input on the right and a CF card slot on the left. Inside is an Altera FPGA development board and power supply regulation circuitry. The menu driven user interface allows the setting of parameters, control of initialization and data logging, and displaying of status information. Three files are generated during each data logging session, one for the PPS, one for the INS and one for the GPS data. The device has been designed to be rugged, simple to use, and to run of 12V batteries for field use. The heart of the design is the serial port logic. The ports have First-In-First-Out (FIFO),
Universal Asynchronous Receive/Transmitter (UART) logic that ensures high data rates and low data losses. The FPGA hardware image and software are stored in flash memory and are automatically loaded and run when power is connected. Two serial ports are provided, but more can be added if required. Currently only a small range of sensors is supported, but this is expected to grow. Supported sensors include the NovAtel SuperStar, CMC Allstar and Signav MG5001 GPS receivers and the Boeing C-MIGITS INS. The device proved to be reliable during initial lab testing, however field testing, evaluation and refinement are ongoing. 2.2 Time synchronisation methodology
The method used to time-synchronise the INS and GPS data is described in this section. This is a two stage process, the count-stamping/data-logging stage and the post-processing stage. Time synchronisation is achieved by utilizing a free-running counter to count-stamp the incoming data streams and PPS pulse. Details of the method are provided below: In the device (data logging process): Serial data streams from the INS and GPS are tagged with a count value as they arrive at the device The PPS signal is also tagged with a count value The count values come from one free-running counter The data is logged to a CF card In the computer workstation (post process): The count value associated with each PPS provides a time reference, as the PPS is aligned to the GPS second The time fields in GPS messages can be used to create an absolute time associated with the PPS Absolute or relative time can be calculated for count values associated with INS (and GPS) data streams Time-aligned data is fed into the Kalman filter Position solutions are provided as output 2.3 Time-synchronisation hardware
The data logging process is hosted on an FPGA development platform. This platform is based around an Altera NiosII FPGA development board, Stratix edition (Altera 2004), that includes an FPGA chip, associated support chips, a range of I/O options, CF card socket and power supply conditioning. Custom designed logic has been developed for the FPGA to provide count stamping on the incomming serial data streams. A NiosII soft-core processor (Altera 2004) residing in the FPGA chip hosts the application software that interfaces with the user and controls the custom logic and CF card operations. Figure 2 provides an overview of the hardware organisation. The logic design was developed in the Altera Hardware Description Language (AHDL), using the Altera sythesis and fit tool - ‘Quartus’. Quartus also includes the System On a Programmable Chip (SOPC) builder (Altera 2003) that is used to generate a NiosII soft-core processor.
NiosII FPGA Development Board Time-sync FIFO UART logic block
GPS
Counter Block
PPS serial
PPS logic
NiosII Soft core processor
CF card
UART
INS
Serial flash
UART
DRAM
serial Interface logic
LCD display & buttons
Figure 2. Time-sync hardware block diagram
The Time-sync FIFO UART block (henceforth the ‘UART block’) is attached to the NiosII processor as a memory mapped peripheral with one interrupt line. All parameters such as the UART’s baud rate are set using data writes, and data is retreived with data reads via the Avalon bus frabric built into the Nios core. An interrupt is generated when the PPS arrives or when one of the FIFO’s is nearly full. This interrupt signals the application software to service the UART block and collect whatever data is available. A status register provides details on the state of UART block. The details of the UART block is porvided in Figure 3. Without the FIFO’s, an interrupt would be generated every time a new byte is available in the UART. The frequent calls to the Interrupt Service Routine (ISR) places a heavy burden on the processor due to the overheads associated with the ISR call (ie suspending the task, saving context onto the stack etc.). This burden is particularly accute with high data rates on multiple UART’s. The FIFO’s aleviate this burden by bufferring the serial data bytes and only generating an interrupt when they are nearly full. During the ISR, the FIFO is drained as a block, in all a far more efficient way of getting serial data, freeing up the processor for other tasks. The counter is 32 bits wide and is clocked by the 50MHz system clock. Only the top 24 bits of the counter is used to provide the required precission. This 24 bit count is latched at the arrival of the start bit of an incomming data byte in the case of the UART. The 3 byte count is appended the data byte and placed in the top of the FIFO. In the PPS case, the 3 byte count is latched into a register and an interrupt generated. The software has a second to respond to the interrupt and collect the count before it is overwritten by a new PPS count value. With this arrangement the least significant bit of the 24 bits of the count value increments every 5.12us, and the counter rolls over every 86 seconds approximately. In theory, the counter will increment 195312.5 times every second, but in practice this depends on the system clock crystal accuracy and stability.
32 bit Counter (upper 24 bits)
PPS
Serial data stream
Pulse logic Signal sampling start & stop bit detection & control logic Latch count
Latch count Shift register
32 bit X 128 24 bits counter, 8 bits char FIFO Almost full
Interrupt logic
Address decoder & control logic
Data to & from Nios
Interrupt to Nios
Figure 3. Simplified Time-sync FIFO UART block diagram (one UART only shown) 2.4 Software development
The Altera software tool, the ‘NiosII IDE’ (Altera 2004) was used to develop the software in the C languge. A custom software library and application framework was built using the eCos configuration tool (Red Hat/eCosCentric, 2003), based on the custom NiosII processors attributes. The eCos framework provides the standard RTOS features that enable multitasking, as well as providing many optional libraries and low level services such as file handling and device drivers – in short a Hardware Abstraction Layer (HAL). The eCos framework provides CF card support using the File Allocation Table (FAT) file system with the Portable Operating System Interface (POSIX) standard. These services are used for operations on the CF card. For more information on eCos see Massa (2003). Although eCos provides multi-tasking capabilities, only one task is required to run the data logging operations. There are two states – logging and not-logging. When not-logging, the user can set parameters, initialise external sensors and view CF card file information using the menu context-sensitive buttons. When logging data, status information is displayed. The software is driven by interrupts from the four user interface buttons and by interrupts from the UART block. When a PPS interrupt occurs, the three byte count tag is written to a circular buffer and when enough bytes are available (nominally 512) the block is written to the CF card. When the FIFO in a UART’s is nearly full, an interrupt is generated. The software drains the FIFO into a circular buffer looking for a header sequence in the message. When a
header is found the count tag from the first character of the header is written to the circular buffer. When a block of bytes is ready, it is written to the CF card. The header sequences for the GPS messages and the INS messages must be known and included in the software. 2.5 Testing
Two areas of testing are discussed; the general functioning and reliability of the device and timing accuracy of the 1PPS. For the device to be useful, it must be easy to use and reliable. The best way to do this is for several users to use it in a range of different situations, and report on their experiences. In order to test the operation of the timing logic right through to file writing on the CF card, the 1PPS data can be conveniently used. The operation of the device as a whole is considered first. The develop, test and debug cycle is quite advanced and the device is stable and reliable. There have been no instances of the device locking up or failing to boot when power is applied. The user interface, whilst basic, works quite well and provides convenient access to setup and control the device. The CF card file writing functions have proven to be reliable when the correct operational procedure is followed by the user. Many small data sets and a few large sets have been successfully logged without problems. In summary, the functional performance of the device has been found to be adequate in practical testing on the test bench and in the field. As mentioned, the count stamp has a resolution of about 5 micro seconds, this sets the internal fundamental accuracy of the system as the 1PPS from a typical GPS receiver is likely to be good to around 50 nano seconds. At this count rate, 195312.5 increments per second are expected with a system clock properly operating at 50MHz, but due to the integer nature of the count, it should alternate between 195313 and 195312. To test this, the PPS file from log sessions can be examined. Figure 4 provides an example of the count interval between successive one second pulses. The count is 195313 or 195312 as predicted, with a bias towards 195313, suggesting a slightly slow system clock. 195314
PPS count
195313
195312
195311 0.0E+00 2.0E+06 4.0E+06 6.0E+06 8.0E+06 1.0E+07 1.2E+07 1.4E+07 1.6E+07 1.8E+07 GPS time (sec)
Figure 4. 1PPS stability
The time synchonisation scheme used in the device does not take into account any time lag associated with the external sensors (ie. INS device) getting their messages out of their serial ports. This time lag sets the effective system accuracy, and can be unknown unless the
manufacturer provides specifications, or testing is done. While these time lags could be problematic if excessive, the general time synchronisation requirements of around 1 millisecond are not likely to preclude many devices. For a more detailed examination of the timing accuracy issue see Yong et al. (2006). 2.6 Future Developments
As mentioned at the beginning of this paper, the idea for the device arose out of the need for a stand-alone time-synchonisation and data logging device. Possibilities for expansion occurred as the project developed. The next step is a series of field tests and evaluation into adding additional GPS receiver, INS unit and other sensor support. On completion of this testing phase, work is planed to attempt to port the Kalmin filter post-processing software currently running in a Windows environment on a computer workstation to eCos running on NiosII. This will require optimisation of the Kalmin filter algorithms in consideration of the reduced resources and library functions available under the eCos/Nios II embedded environment. In addition it will require a review of the hardware platform and the development of new user interface code in C++. Emphasis will be placed on keeping the design portable and open to facilitate the addition of sensors and the migration to other hardware platforms. Hopefully these endeavours will bring us closer to creating a portable, integrated navigation platform that can then be focussed towards a practical application. 3. CONCLUSIONS Design details, some test results and possible future developments for a time-synchronisation device for the integration of GPS and INS sensor data have been presented in this paper. Testing has confirmed the device is easy to use, performs adequately, and is reliable and robust. The plans for further development include expanding the range of sensors it can handle and moving the post-processing stage as a real-time process on board. Clearly there is much building and development to do, but the foundations are looking solid. REFERENCES Altera Corporation (2004) Nios Development Board Reference Manual, Stratix Edition, www.altera.com Altera Corporation (2003) SOPC Builder User Guide, www.altera.com Altera Corporation (2003) Avalon Bus Specification, www.altera.com Altera Corporation (2004) Nios II Processor Reference Handbook, www.altera.com Massa, A. J (2003) Embedded Software Development with eCos, Prentice Hall Red Hat/eCosCentric (2003), eCos User Guide, www.sources.redhat.com/ecos/docs-latest/ Red Hat/eCosCentric (2003), eCos Reference Manual, www.sources.redhat.com/ecos/docs-latest/ Y. Li, P. Mumford, J. wang, C. Rizos, W. Ding (2006) Time Synchronisation Analysis of an FPGA based GPS/INS Integrated System, Symposium on GPS/GNSS IGNSS 17-21 July, Surfers Paradise Australia.
