Positioning


Reconfigurable positioning platform for machine control applications

Oct 2013 | No Comment

This platform consists of multiple reconfi gurable hardware IP cores to make the platform truly reconfi gurable, in terms of hardware architecture

Qizhi Shi

Research student,Nottingham Geospatial Institute, University of Nottingham, Nottingham, UK

Xiaolin Meng

Associate Professor, Nottingham Geospatial Institute, University of Nottingham, Nottingham, UK

Yiqun Zhu

Lecturer, Department of Electrical and Electronic Engineering, University of Nottingham, Nottingham, UK

Alan Dodson

Professor of Geodesy, Nottingham Geospatial Institute, University of Nottingham, Nottingham, UK

Karl Soar

Leica Geosystems Machine Control Division, Nuneaton, UK

The Global Navigation Satellite Systems (GNSS) are playing an increasing role in positioning, navigation and autonomous machine control applications. Recently, the Global Positioning System (GPS) has been integrated into the design of bulldozers, motorgraders, drills, excavators, pavers and agricultural equipment produced by the major manufactures for mining, construction, agricultural and environmental applications [1].

The GNSS RTK positioning approach is usually adopted for machine control applications to meet the requirement of high positioning accuracy. From the viewpoint of a rover, a conventional GNSS RTK positioning system consists of the following four modules: 1. A RF frontend module, which is used to receive the GNSS radio frequency signals and then convert them into base-band signals. 2. Base-band processing module, which is used to acquire/track GNSS signals and then output raw measurements. 3. A wireless communication module, which is used to receive network RTK corrections (RTCM messages) from a base station. 4. Navigation solution module, which is responsible for decoding both the raw message and RTCM messages received from the wireless communication module, and then processing the navigation solutions using a Kalman filter with integer ambiguity resolution, such as LAMBDA.

Conventionally, the first three modules are implemented in hardware while the navigation solution module is developed using C language and run in an embedded processor, such as ARM processor, TI DSP processor and etc. The advantage of the software approach for the navigation solution module is that the navigation processing algorithms can be easily updated. When it comes to machine control applications, the processing speed is one of the most demanding factors because high-speed real-time navigation processing means the machines, such as construction machines, can be driven faster to improve the working efficiency [2]. At the moment, the GNSS RTK navigation processing is normally run on an ASIC device, which is a custom design chip for GNSS RTK navigation processing.

Such an ASIC approach offers a great deal of flexibility, which allows the navigation processing algorithms to be updated in a form of firmware [3]. However, one of the key disadvantages is that no hardware architecture can be altered in such an ASIC approach. More specifically, the level of parallel processing is fixed for an ASIC chip, which limits the further improvement of the processing speed for any advanced computationally demanding navigation processing algorithms. Furthermore, another downside of the ASIC approach is that designing and fabricating an ASIC chip is not only costly, but also requires longer time from development to commercial market.

On the other hand, FPGA (Field Programmable Gate Array) devices are reconfigurable hardware and have been developed significantly during the past decade [4]. FPGA devices were only used for GNSS base-band processing to speed up GNSS signal acquisition/tracking using FPGA parallel processing capability, but it was not quite possible to be used for navigation processing due to the limited logic gates and on-chip memory. However, modern FPGA devices have a massive number of logic gates/DSPS blocks/onchip memory and have been successfully used for computationally intensive applications, such as real-time HD video processing.Therefore, it is timely to re-consider using FPGA technology for GNSS navigation processing.

This paper presents the development of a reconfigurable positioning platform for demanding machine control applications. This platform consists of multiple reconfigurable hardware IP cores to make the platform truly reconfigurable, in terms of hardware architecture. Once the platform is implemented it will be tested through use of a GNSS simulator-Spirent GSS 8000[5] at the Nottingham Geospatial Institute (NGI) in the University of Nottingham and its performance will be fully assessed against reliability, continuity, accuracy and integrity parameters, before a series of in-situ tests.

The reconfigurable positioning platform

The reconfigurable positioning platform we are developing physically consists of a Xilinx Virtex-6 FPGA ML605 board (Figure 1), a u-blox GSM/GPRS module (Figure 2), a NovAtel OEM628 receiver module (Figure 3), a custom high-speed GNSS interface board (Figure 4) and a custom high-speed USB board (Figure 4). The multi-constellation and multifrequency NovAtel OEM628 GNSS receiver module can track the GNSS signals from GPS, GLONASS and Galileo for L1/L2/L5/E1/E5a/E5b [6] and can output the raw measurements at up to 100Hz, which are the key reasons why it has been chosen for the platform, because the raw data needs to be fed into the platform at a high rate to test the novel high-speed hardware architecture of the GNSS signal processing algorithm.

In the reconfigurable positioning platform, the Virtex-6 FPGA device is not only used to implement reconfigurable navigation processing cores, but also implement relevant control interface cores for all other modules. The corresponding block diagram of the reconfigurable positioning platform is also given in Figure 5.

Firstly, a data acquisition control core is developed to acquire/decode raw data messages from both the NovAtel OEM628 receiver module and the u-blox GSM/GPRS module.

Secondly, under the control of a DMA (Direct Memory Access) core, the decoded raw data (raw measurements and RTCM corrections) are written into DDR3 memory directly in real time.

Thirdly, again, under the control of the other DMA core, the reconfigurable navigation processing cores can read out the decoded raw data from the DDR memory directly for relevant navigation processing and then write the results back to the DDR memory in real time. Finally, a MicroBlaze processor can read out the results from the DDR memory and sends them to a PC for display through either the RS232 core (HyperTerminal) or Highspeed USB core (USB 2.0 link). In this way, both the MicroBlaze processor and the AXI bus have not been involved in any data flows above except sending the final results from the DDR memory to a PC, this not only reduces the AXI bus traffic, but also allows the MicroBlaze processor to use most time to run non time-critical data processing in the navigation algorithm. In the following, more details will be provided for both the Data Acquisition Control module and the Reconfigurable Navigation Processing Core.

Data acquisition control core

As shown in Figure 6, the data acquisition control core consists of two RS232 cores, a raw data message decoding unit and an RTCM message decoding unit and a data combiner. Basically, each of the two RS232 cores will receive the relevant raw data message from NovAtel OEM628 receiver module and the RTCM message from a base station via the u-blox GSM/GPRS module, respectively. Then, both the received messages will be decoded in individual decoding units in parallel. Finally, the decoded data will be combined together in a certain format and then sent to the DDR memory under the control of the DMA core.

Reconfigurable navigation processing core

The reconfigurable navigation processing core shown in Figure 7 has three hardware IP cores, which are reconfigurable matrix inversion IP core, reconfigurable LAMBDA IP core and reconfigurable Kalman filter IP core, because they have been identified as the most timeconsuming modules and need to be implemented in hardware for the purpose of high-speed processing. However, to further speed up the navigation processing, more hardware IP cores can be included in the reconfigurable navigation processing core. Before going further to describe the individual hardware IP cores in the reconfigurable navigation processing core, we need to clarify what ‘reconfigurable’ means here because, in the context of FPGA technology, reconfigurable usually means that the same FPGA can be reconfigured with a different design without changing the FPGA device itself. For example, an FPGA based electronic system can be easily updated with a new FPGA design without changing any hardware by re-programming the FPGA device. However, this is not what we refer reconfigurable to as in our context. For our reconfigurable navigation processing core, reconfigurable means some parameters of an FPGA design can be changed in real time without re-programming the FPGA device. For example, the size of matrix can be changed in real-time for our reconfigurable matrix inversion IP core.

Reconfigurable matrix inversion IP core

The reconfigurable matrix inversion IP core is based on the GAUSS-JORDAN elimination algorithm [7], in which the matrix size can be reconfigured from 4 to 32. The FPGA architecture of the reconfigurable matrix inversion IP core consists of four modules: 1. A matrix memory buffer of 64 x 2048 bits with dual port access; 2. Forward reduce module; 3. Backward reduce module; 4. Normalization. The matrix memory buffer is used to store both input matrix and the corresponding identity matrix for GAUSS-JORDAN elimination and hence 64 x 128 floating numbers with custom precision. With such a matrix buffer, the other three processing modules can read out/write in an entire column data (up to 2048 bits) in a single clock cycle and hence it significantly improves the I/O access, which is the speed bottleneck of the hardware-based matrix inversion [8][9][10]. However, the previous generation FPGA was not able to create an on-chip memory buffer with a data bus of up to 2048 bits [11].

The key novelties of the platform are that 1. Real-time reconfigurability, in terms of matrix size, which is required by the navigation processing algorithms, so it has to be reconfigurable in real time; 2. FPGA-based floating point processing with custom precision. It is the first FPGA architecture of matrix inversion with the capability of custom precision floating processing, which minimises the usage of FPGA hardware resource with no loss of required precision.

Reconfigurable Kalman filter IP core

Kalman filters are widely used for GNSS navigation solutions [12]. However, we do not believe it has previously been implemented on an FPGA though general Kalman filter pipeline designs have been developed for many years [11][13][14]. The size of the memory on an FPGA is the main issue for FPGA implementation of Kalman filters, because a large memory size has to be used for the required floating point number calculations.

One method is to store data into a DDR memory and then send it to an FPGA for further processing, which obviously will slow down the hardware implementation speed [14]. The reconfigurable Kalman filter IP core is built up from the reconfigurable matrix inversion IP core. More specifically, the reconfigurable Kalman filter IP core consists of one reconfigurable matrix inversion core and a number of reconfigurable matrix multiplication/addition IP cores.

Therefore, in the reconfigurable Kalman filter IP core, the key tasks are that a highspeed and efficient FPGA architecture for the reconfigurable multiplication/ addition IP core needs to be identified and then integrated with the reconfigurable matrix inversion IP core. As with the reconfigurable matrix inversion IP core, the matrix size is the only parameter that needs to be reconfigured in real time.

Reconfigurable LAMBDA IP core

LAMBDA is used for the integer ambiguity resolution which was first proposed by Teunissen in 1990 and it is believed to be the most reliable algorithm to achieve the fixed solution rapidly [15] [16][17]. A reconfigurable LAMBDA IP core is under development based on this algorithm, which mainly consists of an LD factorization unit, an LAMBDA reduction unit and an LAMBDA search unit.

Current status of the platform

Although the platform is still under development and not fully operational yet, the following development work has been completed.

Embedded C model of GPS L1/ L2 RTK navigation processing

An embedded C model of GPS L1/L2 RTK navigation processing has been developed and run on the MicroBlaze processor in the Xilinx Virtex-6 FPGA device successfully. The C model has been tested in a roof based laboratory of the Nottingham Geospatial Building, which is shown in Figure 8. A static test was set on a known point (NGB1) whereas the kinematic test was carried out on a locomotive on the roof track.

Static test

The test was set on a known point (NGB1) on the roof of NGI with an open sky for half an hour. The position was displayed on a laptop and logged into a data file in NMEA format in real time. The positions are retrieved from the NMEA data file, converted to the local coordinate with a coordinate conversion tool, Grid InQuest, and then compared with known NGB1 position in local coordinates. The two dimensional offset results and three dimensional results are shown in Figure 9 and Figure 10, respectively.

It can be seen from Figure 9 that there is an abnormal offset of an out stretch “arm”. Having examined the positioning data, we found that the results drifted out from the cluster for 27 seconds in the middle of the test, and then moved back to the cluster due to a satellite signal loss, which caused the drifting.

Figure 10 shows that the big offset happens around the 17500th epoch, which is consistent with the out stretch arm. The average offsets for both easting and northing are less than 2 centimetres. It also shows that the average offset in height is around 6 centimetres.

Kinematic test

An electrically powered locomotive was used for the kinematic test. The locomotive was run on a 120 metres long rail track in a maximum speed of 7.2 km per hour for three loops of the circuit. The test results are shown in Figure 11.

It can be seen from Figure 11 that a significant offset has appeared on the right of the plot. Having looked into the test results further, we found that this big offset lasts for 30 seconds, which coincides with loss of the fixed integer ambiguity. However, the centimetre accuracy positioning is regained after 30 seconds. The reason for losing fixed integer ambiguity may be caused by obstruction from nearby objects. From the position of the offset, it can be seen that this error is just located beside the air circulation system on the roof, which is large with a reflective metal surface. The average offset and standard deviation for position outputs are shown in Table 1.

The test results show that the C model is able to achieve 2 cm horizontal position accuracy with the fix solution.

High-speed GNSS interface module

A high-speed GNSS interface module as shown in Figure 4 has been developed and is fully functional. It has six high-speed serial ports (RS-232, 3MBPS). Although only two ports are used currently, one of which is connected to the NovAtel OEM628 GNSS receiver and the other is used for the u-blox GSM/GPRS module, the remaining four high-speed serial ports can be used for other sensors in future, which allows the platform to cover even more applications.

High-speed USB module

A high-speed USB FMC module as shown in Figure 4 provides a high-speed USB link (USB 2.0, 480MBPS) between the platform and a PC. Firstly, at the early stage of the research, for the purpose of verification of high-speed hardware GNSS signal processing, the high-speed USB link can be used to download the pre-recorded GNSS raw data from a PC to the platform for high-speed hardware GNSS signal processing and then upload the results back to the PC. Secondly, working with the high-speed GNSS interface module, the high-speed USB module can be used to acquire GNSS raw data or the data from other sensors to the PC. Finally, it can be used to display the results on the PC in real time at a later stage of the research.

Discussion

From the viewpoint of system design, the reconfigurable positioning platform under development can accommodate two main phases in the development of real time high-speed navigation solution processing for machine control applications:

Algorithm development

In this phase, the platform can act as a highspeed data acquisition system to receive raw measurements from the NovAtel OEM628 GNSS receiver and RTCM message from an RTK base station, such as SmartNet. The received data can be sent to a PC in real time via the high-speed USB board. Therefore, with the raw data received, the algorithm development can take place in the PC. Of course, more sensors can be accommodated as there are still four serial ports available.

FPGA prototyping

In the FPGA prototyping phase, the RTK navigation processing algorithms (in the form of C or Matlab code) developed in the algorithm development phase are converted into embedded C codes to run on the MicroBlaze processor. Furthermore, those most time-consuming parts of the embedded C codes will be replaced with reconfigurable matrix inversion/Kalman Filter/LAMBDA IP cores to meet the requirement of high-speed processing.

Of course, in the case of a final commercial system based on the FPGA device, the output of the FPGA prototyping phase will be a ready-to-use system prototype, whereby all modules will be integrated into a single PCB board, which not only has the required interface for machine control applications, such as CAN bus interfaces, but also has an FPGA device with the right capacity to provide a compact, comparatively low-cost positioning system.

Conclusions

In this paper, a reconfigurable positioning platform for demanding machine control applications has been proposed and is under development. In such a platform, the most time-consuming parts have been identified in the C model of the RTK navigation processing for machine control applications. These parts are being developed as reconfigurable hardware IP cores in an FPGA by making full use of FPGA parallel processing capability whereas the other parts will be running in the on-chip MicroBlaze soft processor as embedded C codes. In the proposed reconfigurable positioning platform, matrix inversion, Kalman filter and LAMBDA are being developed as a form of reconfigurable IP core. However, if further improvement is required, in terms of processing speed, the other modules can also be developed as hardware IP cores without re-designing any hardware. Therefore, compared with current commercial ASIC based GNSS RTK navigation processing system, the proposed reconfigurable positioning platform can add another dimension of flexibility, which allows completely reconfigurable hardware architecture to meet the requirements from demanding real-time machine control applications, in terms of parallel processing.

Acknowledgments

The authors would like to acknowledge the financial support provided by the UK’s Engineering and Physical Sciences Research Council (EPSRC) and Leica Geosystems.

References

[1] A. Beetz, V.S. “Integration of Controllers for Filter Algorithms for Construction Machine Guidance”. The 1st International Conference on Machine Control and Guidance. 2008.

[2] “Products and applications, 836H Landfill compactor”. http://www.uk.cat.com.

[3] Seyed Nima Sadrieh, Ali Broumandan, and Gérard Lachapelle, “Spatial/Temporal Characterization of the GNSS Multipath Fading Channels,” in the proceeding of the 23rd ION GNSS 2010 Conference, pp.393-401.

[4] H. Stewart Cobb, “FPGAOptimized GNSS Receiver Implementation Techniques,” in the proceeding of the 21st ION GNSS Conference, pp. 2326-31.

[5] Spirent GSS8000 multi-GNSS constellation simulator, http://www. spirent.com/Products/GSS8000

[6] Novetel OEM6 Develop Kit, http:// www.novatel.com/assets/Documents/ Papers/OEM6_Development_Kit.pdf.

[7] J.A.Garcia,R.P.Jacobi,C.H.Llano s,M.A.Rincon, ”A suitable FPGA implementation of floating-point matrix inversion based on GAUSS_ JORDAN elimination”, IEEE

[8] M.Karkooti,J.R.Cavallaro, “FPAG implementation of Matrix inversion using QRD_RLS algorithm”,

[9] J.Zhou, Y.Dou, J.Zhao,F.Xia,Y.Lei, Y.Tang, “A fine-grained pipelined implementation for large-scale matrix inversion on FPGA”, APPT 2009, LNCS 5737, PP.110-122.

[10] R.Duarte, H.Neto, M.Vestias,”Double-precision Gauss-Jordan algorithm with partial pivoting on FPGAs”, in the proceeding of the 12th Euromicro conference on digital system design/ architectures, methods and tools,

[11] A.Bigdeli, M.B. Abhari, Z. Salcis, Y.T.Lai, “A new pipelined systolic array based architecture for matrix inversion in FPGAs with kalman filter case study”, EURASIP journal on applied signal processing, Volume 2006, PP. 1-12.

[12] D.J.Jwo,M.Y.Chen,C.H.Tseng, T.S.Cho, “Adaptive and Nonliner kalman filtering for GPS navigation processing”, Kalman Filter: Recent advances and applications, pp.322-346, April 2009, I-Tech, Vienna, Austria

[13] R.Capua, A. Bottaro, “Implementation of the unscented kalman filter and a simple augmentation system for GNSS SDR receivers”, in the proceeding of the 25th international technical meeting of the satellite division of the Institute of Navigation, Nashville TN, September 17-21, 2012, pp. 2398-2407.

[14] C.R.Lee, Z.Salcis, “High-performance FPGA-based implementation of Kalman filter, Microprocessors and Microsystems 21, 1997 pp. 257-265.

[15] P.J.G. Teunissen, P.J. de Jonge and C.C.J.M. Tiberius, “The LAMBDAmethod for fast GPS surveying”, GPS technology applications, Bucharest, Romania, September 26-29, 1995.

[16] P.J.G. Teunissen, “The least-squares ambiguity de-correlation adjustment: a method for fast GPS integer ambiguity estimation”, Journal of Geodesy, 1995, 70, pp.65-82.

[17] J .Liu, “Implementation and analysis of GPS ambiguity resolution strategies in Single and multiple reference station scenarios”, Thesis, University of Calgary, January, 2003. The paper was presented at ENC 2013, Vienna, Austria during April 23-25, 2013

1 Star2 Stars3 Stars4 Stars5 Stars (6 votes, average: 2.33 out of 5)
Loading...


Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.