OxTS LIO is a post-processing tool that allows you to utilise LiDAR data to enhance your navigation solution. In dense urban environments, GNSS is often unable to produce an accurate and reliable ground truthing measurement, as multipath and lack of satellites causes erratic raw position updates.
Conversely, OxTS LIO excels in these environments, as large buildings and other common features in an urban canyon provide the perfect input for our LiDAR odometry algorithm, producing high-accuracy velocity updates despite GNSS outages.
To produce a generic aiding (GAD) file using OxTS LIO, four files are required:
- OXTS raw navigation data (.RD)
- INS to LiDAR position offset (.LIP)
- INS to LiDAR rotation offset (.LIR)
- LiDAR data (.PCAP)
The RD file used will need the following feature codes present at the time it was logged:
- LiDAR Odometry
- Local co-ordinates
The LIP and LIR files describe the position and orientation of the LiDAR respectively, and are relative to the INS frame. The LIP is the x, y and z displacement from the INS measurement point to the LiDAR device, and the LIR is the relative yaw, pitch and roll displacement between the INS measurement axes and the LiDAR device axes, both are text files with the format:
1 or 0 (indicates if data has been calibrated)
To fully calibrate your LIP and LIR we highly recommend performing a boresight calibration which will significantly improve the LiDAR odometry. A guide on doing this can be found here. The accuracy of the LIR is of most importance, and so this step should of high priority.
The "Getting the best data" section in this guide covers the key parts of getting the best out of your LiDAR and INS data which will in turn result in the best LiDAR odometry possible.
The LiDAR data can be in three different formats, either raw packets in .pcap or the OxTS format LCOM. OxTS LIO utilises our own Georeferencing software to turn specific LiDAR data types into generic point clouds which is then input into the odometry algorithm. This step is done automatically, however you can skip this step if you already have the .las/.laz file from a previous processing run.
It is important there is some form of time syncing contained in the LiDAR data, either from PTP or NMEA and PPS, both of which are supported by our units.
The first tab within OxTS-LIO is where all the required files are mentioned in the previous section input.
If multiple LiDAR files are added these will be combined into a single GAD file.
In the next tab, several file options can be selected before processing.
LiDAR model and type is required for the Georeferencer part of the processing, you will also need to specify the LiDAR type in the LIO configuration file as well.
By default the configuration settings for the INS data are extracted from the RD file, however these may not be an improved configuration, which is recommended. So, either an NCOM can be input and an improved config will be calculated from this, or a separate config from another folder can be selected.
Enable file cleanup will automatically delete the raw pointcloud produced from Georeferencer, which can be quite large, as well as the input LiDAR data and any duplicate NCOM/GAD files.
The processing options tab controls the settings for both the GAD processing as well as the resulting NCOM.
GNSS recovery settings are set to -1 by default (which uses the default receiver settings), and controls the number of unexpected GNSS updates that are ignored before being forced to use them.
The Zero Velocity Updates (ZVU) is a very powerful tool that drastically reduces drift when stationary in GNSS outage, so it's recommended to enable this. The speed threshold and packets before activation can be altered, however the default values are recommended.
Advanced commands can also be added, these will affect the processed NCOMs.
Default configuration files can be found in the respective folders within the bin folder.
Georeferencer configuration file
The Georeferencer.cfg file contains the different settings used when combining the LiDAR and OxTS navigation data into a point cloud. This is then fed into the LiDAR odometry algorithm. Most of these settings can be left as the defaults, however the time offset may need to be changed as there could be a difference between the time epoch used to time sync the LiDAR data. It's important to remember the lidar_time_offset is measured in nanoseconds.
Certain values may need to be changed depending on the environment for example the "minmax" options can be varied to exclude certain features in the pointcloud, i.e. a car bonnet.
OxTS-LIO configuration file
This configuration file is specifically for producing the LiDAR odometry GAD file, and there is some overlap with the settings in the georeferencer.cfg file
The two key values to change are the "lidar" and "lidar_rpm" options, which will be specific to your own setup. LIO can technically support any LiDAR type that is supported within Georeferencer, however only the following have been added:
[*] Ouster 0 models appear to have configurable angular resolution independently of RPM. When using these models, one must specify horizontal_scanpoints as well as the lidar model.
[Implemented but untested]
If your LiDAR type is not listed above but is supported by OxTS Georeferencer then we will happily add support for it and distribute an updated version of LIO for your use.
Processing should produce a folder called lio, which will contain all outputs from the GUI. The most important file is the "output.gad" file, this is an OxTS format which contains all the LiDAR odometry and will be used along side the RD file to produce an aided NCOM.
The GUI will do this for you, and depending on the processing mode selected (simulated or combined) there will an "unaided_sim"/"unaided_cmb" and "sim"/"cmb" folder, the latter will contain the NCOM aided with the GAD file. You can then view both for of these in NAVGraph to compare the effect LIO had. To check when the NCOM is aided, you can look for "GPS Velocity mode" being in "Gen Aid (34)".
An "Analysis" folder will be produced which will contain all the report graphs such as GAD vs NCOM velocities and comparisons of forward vs backward processing of unaided and aided NCOMs.