GPSTk
From GumstixDocsWiki
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Customers using Gumstix OpenEmbedded should go to gumstix.net and the related user wiki
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For customers using buildroot:
Contents |
Abstract
This article shows how the combination of the GPS Toolkit (GPSTk) and the Gumstix computers allows rapid development, implementation and testing of advanced embedded GNSS data processing applications in a flexible way.
Introduction
The GPS Toolkit [1] is an open source project initiated by the Applied Research Laboratories (University of Texas) and aiming to provide a world class, open GNSS library computing suite. It supplies several GNSS algorithms and models, supports RINEX and SP3 formats, and has several categories of functions and routines such as GNSS time conversion, ephemeris computations, atmospheric delay models, data extraction, weighting algorithms, positioning solutions, etc.
The GPSTk is a highly platform-independent software code base thanks to its use of the ANSI C++ programming language. It is reported to run on Linux, Windows, Solaris, and AIX operating systems, and may be compiled using several versions of free and commercial compilers, both in 32 bits and 64 bits platforms. Also, it is profusely documented using the Doxygen documentation system and it is heavily based on object-oriented programming principles, ensuring a modular, extensible and maintainable code.
Additionally, the GPSTk is released under the GNU LGPL license, allowing freedom to develop both commercial and non-commercial software, and it is actively maintained by developers around the world.
Porting the GPSTk to the Gumstix
The GPSTk is a very portable software suite thanks to the use of ANSI C++ coding standards. Apart from the most common 32 and 64 bits platforms, it is reported to run, with minimal modifications, in such disparate platforms as the Nokia 770 Internet Tablet and the Gumstix line. In this work the lowest-end board was used: The Basix 200, running at 200 MHz with 64MB SDRAM, 4MB Strataflash and a RS-MMC (Reduced Size Multi Media Card) slot.
Installing the cross-compiling tools
In order to compile software for the Gumstix boards, a buildroot needs to be installed. Buildroot consists of several “Makefiles” and patches used to generate cross-compilation tools and the root filesystem to be installed in the embedded system [2]. The cross-compilation tools are critical in this sense, because they allow compiling software for a different type of processor (called “target”) from the one acting as “host” system. In this work, the host system is a common-brand AMD Athlon XP 2400+ laptop with Linux as operating system, and the target processor is the Intel PXA-255 installed in the Gumstix board.
The buildroot used for the Gumstix is designed for use in Linux and is described in Buildroot. The buildroot generated in with the information there corresponds to the last available version. This implies that, in order to use it, the corresponding Gumstix board must be re-flashed to match the new buildroot version. This process may be avoided if the exact version number corresponding to the Gumstix board is downloaded. This version number may be checked out at the /etc/gumstix-release file residing at the Gumstix board.
The Gumstix board used in this work was flashed with buildroot version 773. Hence, in order to download this specific version we may issue the following command:
svn co -r773 http://svn.gumstix.com/gumstix-buildroot/trunk gumstix-buildroot
Please see Buildroot on why you might need/want to do this, as well as to find out what revision number you have on your gumstix.
Building the C++ library and compiler
The next step is to build the buildroot, but the C++ library and compiler must be enabled before (they are disabled by default). How to do this depends on the buildroot version. For revision 775 and later, the process is described in C++ Hello World. In our case (version 773), the process is simple and implies to get into the downloaded “gumstix-buildroot” directory and modify the “Makefile” file there. In that file, the variable INSTALL_LIBSTDCPP must be set to true. After enabling C++, the buildroot is generated issuing the command make. This is a lengthy process involving downloading several software packages from the Internet.
After this process is finished, the new C++ library is found in the directory build_arm_nofpu/root/lib and is called libstdc++.so.6.0.2. If you don’t want to re-flash your Gumstix, you must copy this file to the directory /lib in the Gumstix board. There are several ways to achieve this (see Connecting_via_Serial_-_Linux and Setting_up_USBnet), but the most simple way is to introduce the RS-MMC card in your host system, copy the library there, and then transfer it to the target board. Pay attention to the symbolic links needed by the library, they must also be added in the /lib directory:
/lib/libstdc++.so -> /lib/libstdc++.so.6.0.2 /lib/libstdc++.so.6 -> /lib/libstdc++.so.6.0.2
Once this process is finished, the Gumstix board is ready to run C++ software. No further repetitions of this process are needed, unless you want to change your Gumstix buildroot version.
Compiling the GPTSk for the Gumstix
In order to cross-compile the GPSTk, the first step is to download it using the same subversion client mentioned above. Create an appropriate directory, get into it, and issue the following command:
svn checkout https://svn.sourceforge.net/svnroot/gpstk
This will download all the files related to the GPSTk in the gpstk directory. There, the subdirectories ref (where an user guide is been written) and dev (where all the GPSTk software resides) may be found. Change to gpstk/dev.
Before any further action, you must be sure that the cross-compile tools (specifically, the arm-linux-g++ compiler) are in your “PATH”. They may be found in the subdirectory gumstix-buildroot/build_arm_nofpu/staging_dir/bin. Please be sure to add the full path to this directory to your current “PATH” variable (The process to achieve this varies according to the Linux shell used in your host system).
Please note that the GPSTk is a complex software suite that uses the “GNU build” system [3] to ease compilation. This implies that the following tools must be installed in your host system: aclocal, autoconf, automake and make.
Then, the next step is to modify the file configure.ac in order to disable some characteristics that cause problems in the Gumstix PXA-255 processor. Please find the lines AC_FUNC_MALLOC and AC_FUNC_REALLOC and delete or disable them.
Once the former steps are complete, we may proceed to prepare the GPSTk for cross-compilation issuing the following commands in the gpstk/dev directory:
aclocal autoconf automake -a ./configure --host=arm-linux
The former process creates a complex Makefile with all the instructions needed to cross-compile the GPSTk library object files, applications and examples. In order to proceed with the real compilation, use the command make.
This compilation is a long process. Please be aware that you are dealing with a development version and, from time to time, some errors may appear, in particular in the companion applications. If that happens, try to re-issue the make command and, if it doesn’t work, disable the problematic application in the corresponding Makefile.am file and rerun the process from the automake -a command.
Once the compilation is finished, all the library object files must be collected into a single dynamic library. Change to the gpstk/dev/src subdirectory and issue the following command:
arm-linux-ar -rs libgpstk.so *.o
The GPSTk library and applications are ready to be transferred to the Gumstix board.
Generating the GPSTk library documentation
You may want to generate the GPSTk library reference documentation to ease the development of your own GNSS applications. This reference documentation is generated using the Doxygen documentation system [4], so a Doxygen client is needed. If your host system has it installed, just change to the gpstk/dev subdirectory and issue the command:
doxygen
A subdirectory called doc will be generated with all the appropriate documentation in HTML format.
Transfering the GPSTk to the Gumstix board
Given the limited size (4 MB) of the Gumstix Basix 200 strataflash memory, it is too small to hold the GPSTk library. The simplest way to overcome this limitation is to copy the file libgpstk.so (and some examples and applications, if you wish) to the RS-MMC card and create in the Gumstix board a symbolic link from the /lib directory to the corresponding file in the RS-MMC card:
/lib/libgpstk.so -> /mnt/mmc/libgpstk.so
Other solutions are possible, but given their complexity the will not be discussed here.
Compiling and running GPSTk-based applications
Once the cross-compilation tools are installed in the host system, and the C++ and GPSTk libraries have been transferred to the Gumstix board, we are ready to start developing GPSTk-based applications.
One of the great advantages of the GPSTk is its flexibility and ease of use. In this section, such flexibility will be emphasized by taking an example application that comes included and adapting it, with very little effort, to do several kinds of GNSS pseudorange processing.
Apart from the library, the GPSTk suite comes with a wealth of GNSS applications ready to run, explore and include in your own developments. Full applications may be found in the gpstk/dev/apps subdirectory, and interesting and easy-to-follow examples of use are located at gpstk/dev/examples. As previously stated, we will take an example (example5.cpp) and will quickly modify it to get several different GNSS pseudorange processing strategies. Three new examples will be developed:
- example-a.cpp: This program will process C1 pseudoranges applying an standard ionospheric model (Klobuchar), a simple tropospheric model (called GCAT and described in [5]), and the solution will be found using a standard Least-Mean-Squares algorithm.
- example-b.cpp: An improvement with respect to the former one, it will process C1 pseudoranges and apply Klobuchar inospheric model, but the tropospheric model will be the one described in the RTCA/DO-229C document (called the Minimum Operational Performance Standards or MOPS). The solution will be found using the Weighted-Least-Mean-Squares algorithm also described in the aforementioned document. It is worth noting that the MOPS algorithms are used in SBAS systems receivers such as EGNOS ones.
- example-c.cpp: Very similar to example-b.cpp, in this case the PC observables are used, and therefore the ionospheric model is dropped. Tropospheric and solver algorithms remain the same (MOPS).
All these programs will read the observables and ephemeris data from corresponding RINEX files. Broadcast ephemeris will be used (although simple changes allow for SP3 ephemeris) and the output will be epoch (in seconds of day) and deviations in latitude, longitude and height (in meters) from a nominal position. The full source code for these examples may be found at [6].
A typical use of the GPSTk follows: In the following lines you will find the code added to example5.cpp in order to allow example-a.cpp, example-b.cpp and example-c.cpp output the data in the format explained above:
Position nominalPos(4833520.2269, 41537.00768, 4147461.489); // Object holding nominal position Position diffPos; // Object to hold difference in position diffPos = solPos - nominalPos; // Get the difference between epoch solution and nominal position double azimuth = nominalPos.azimuthGeodetic(solPos); // Azimuth of solution with respect to nominal double elev = nominalPos.elevationGeodetic(solPos); // Elevation of solution with respect to nominal double magnitude = RSS(diffPos.X(), diffPos.Y(), diffPos.Z() // Compute RSS // Print results cout << rData.time.DOYsecond() << " "; // Epoch in seconds of day cout << magnitude*sin(azimuth*DEG_TO_RAD)*cos(elev*DEG_TO_RAD) << " "; // Longitude change cout << magnitude*cos(azimuth*DEG_TO_RAD)*cos(elev*DEG_TO_RAD) << " "; // Latitude change cout << magnitude*sin(elev*DEG_TO_RAD) << " "; // Altitude change
As can be seen in the former lines, GPSTk’s objects encapsulate much of the functionality needed to do common tasks in GNSS data processing. Note, for instance, how the substraction (“-“) operator is overloaded in the Position objects in order to allow them to be easily handled (diffPos = solPos - nominalPos). Other methods such as azimuthGeodetic() and elevationGeodetic() are also handy. There are plenty of features like these in the GPSTk.
Other small modifications remain in order to allow the original example example-5.cpp to fulfill the requisites stated above for example-a.cpp:
- Declaring an object gcatTM of class GCATTropModel (tropospheric modelling).
- Declare object solver belonging to class SolverLMS (standard Least-Mean-Squares algorithm)
In the other hand, the main modifications to convert example-a.cpp into example-b.cpp include:
- Tropospheric modelling will be carried out by object mopsTM of class MOPSTropModel.
- solver object now must belong to class SolverWMS (Weighted-Least-Mean-Squares algorithm)
- A new object, mopsWeights belonging to MOPSWeight class, must be added to compute weights.
Some minor details remain (for example, mopsTM needs to be initialized and solver invocation must include a vector of weights supplied by mopsWeights.weightsVector), but it is very easy to change from a processing strategy to another thanks to GPSTk encapsulation of important algorithms.
Finally, the change from example-b.cpp to example-c.cpp involves mainly three simple modifications:
- Object obsC1, originally belonging to class ExtractC1, must be declared as belonging to ExtractPC.
- Given that the Total Group Delay is not applicable when using PC observables, the object in charge of modeling the pseudoranges (modelPR, of class ModeledPR) will be configured to ignore the TGD (modelPR.useTGD = false).
- All references to Klobuchar ionospheric modelling are now useless and should be deleted.
The source code files for these new programs were stored in a new subdirectory: gpstk/dev/tmp. In order to cross-compile them for the Gumstix board, change to that directory and issue commands as the following:
arm-linux-g++ -ansi -pedantic example-a.cpp -o example-a -I../src/ -L../src/ -lgpstk
Final remarks
The combination of the GPSTk flexibility with Gumstix's power and small footprint opens a cornucopia of possibilities for embedded GNSS data processing.
In this sense, the accessory board GPSstix could be very useful. However, the use of the GPSstix with the GPSTk has not been tried yet.
Please note that the examples shown so far are using data coming from RINEX files. On the other hand, the GPSstix provides the already-computed position in a NMEA format, and not the GNSS raw observables required by the GPSTk. Some u-blox GPS chips are able to provide these raw observables, but whether the chip installed in the GPSstix is able to provide them is yet to be confirmed.
In case the GPSstix provides these raw observables, it still remains the problem of processing the binary UBX protocol. Currently the GPSTk provides little specific support for raw binary data measurements from commercial receivers, but it provides the appropriate classes to develop this support (class FFBinaryStream and related).
