OxTS Georeferencer Full Guide

This section is a brief guide to setting up your equipment to perform a LiDAR survey. For hardware integrations please see the articles linked above or look on our main website for integration guides for Velodyne, Ouster and Hesai LiDAR. OxTS offers multiple cable types for the xNAV550 only with LiDAR adapter interfaces for use with Velodyne LiDAR, these can be seen in the manual.

You will need to place the INS and LiDAR device on or in your vehicle with the LiDAR having an appropriate view. It is very important at this stage that you make sure both devices are secure and do not move during the survey. It is okay if the LiDAR is viewing some of the vehicle, this can be removed in processing later. The next step is to measure the positional and angular offset. 

Relative measurements: When you set up your configuration you will need to measure the relative distance between the INS measurement point and the LiDAR optical centre. Make sure to do this accurately and that you measure from the measurement point of each device not just the centre of their housings. These measurements include the XYZ linear displacement and also their relative roll, pitch and yaw. This is in addition to the INS-vehicle configuration measurements that NAVconfig requires. These measurements won't be needed during set up but note them down for Georeferencer later. If you want centimetre accuracy you will have to ensure the XYZ displacement is accurate to better than a centimetre and your angles to points of a degree unless you are boresighting which will take of this for you.

Pay close attention to the instructions later on for inputting the correct angle and displacement values.

It is particularly convenient to use a fixed mounting if you want to take many surveys and to be more accurate in your measurements. If you have a standard, repeatable configuration your life will be much easier as you only need to take configuration measurements once and the setup only needs to be boresighted once. CAD files of the LiDAR will be available from the manufacturer and of the INS from OxTS. However, with our boresighting calibration you can work much more flexibly if required.

A mount that OxTS uses internally. It has a fixed relative position and orientation and holds both devices securely to the vehicle. On the right is a view of the setup that can be seen in Georeferencer 1.2.

There are many different ways of setting up your cable connections depending on your preferences. Below, on the left, is a diagram of the setup for taking data using a Velodyne LiDAR. On the right is a selection of choices for viewing data. These are discussed more thoroughly in the next section. You can choose setup 1 or 2 to view both streams of data in real time or setup 3 to see only one stream of data or to setup the INS. Your computer may require USB-ethernet adapters. Bear in mind that if you are using PTP for time-syncing the switch also should be PTP-compatible.

Diagram of a device setup. On the left, the setup of cables to run the devices and log data. On the right, setup for viewing data in real time.

IP configuration: If you are viewing data in real time you will likely need to configure your laptop's IP addresses for the incoming INS and LiDAR data. If you have streams of data coming in from multiple devices you will have to make sure your PC is configured to be on the correct IP range as each one. This can easily be done by right-clicking on the internet icon in the lower right on the taskbar for a Windows 10 PC and choosing 'Open Network and Internet Settings' then 'Change adapter options'. Right click on the ethernet connection bringing data in and choose 'Properties'. Click on 'Internet Protocol Version 4 (TCP/IPv4)' and then click 'Properties'. Choose 'Use the following IP address' and input an IP address on the correct range of one of the devices. For example for an xNAV550 with IP address 192.168.0.100 you can choose 192.168.0.52. Then click on 'Advanced' and add further IP addresses on the same ranges as other devices for example for a LiDAR with IP address 192.0.0.201 you can use 192.0.0.52. Having done this your PC will be able to handle viewing the INS in NAVconfig/NAVdisplay and the LiDAR in whichever software/web interface it uses. 

NAVconfig: You will have to put in all the necessary measurements into NAVconfig > Hardware Setup. In NAVconfig > Hardware Setup > LiDAR Scanner, select your scanner type and, if using onboard LiDAR logging, tick the boxes for logging data and logging telemetry. For onboard logging, you must first have the feature code for this enabled and second you must ensure that the data rate from the LiDAR you are using does not saturate the CPU; typically this applies for LiDAR with over 16 lasers. Version 3 OxTS INS devices can store up to 32GB of raw data (INS + LiDAR). Files logged onboard are saved as LCOM format. You then have a choice of sending your NMEA data over ethernet or over serial (see Figure 3). NMEA data can be sent over an ethernet connection using a connector, a switch or a network bridge. The default ports should not need to be altered and are correct for the VLP16. If you are sending data over ethernet you will need to put the IP address of the LiDAR device in, alternatively you can use the broadcast IP address 255.255.255.255 but this may unnecessarily saturate your network. Alternatively PPS and NMEA can be configured in the Interfaces tab of NAVconfig.

Selecting how NMEA data is transferred from the xNAV to the VLP (right highlighted box). Selected scanner type, inputting IP address and data logging settings (left box).

In NAVconfig > Environment you will need to select ‘Enable local coordinates’ and choose your origin (see Figure 4). This can be done in post-processing in NAVsolve > Process > Local coordinates or by creating an LRF file manually. Doing it before your survey will simplify the processing later.

Enabling local coordinates in NAVconfig, you can then choose your origin. 

If you are not using NAVsuite 2.8 and you choose ‘Send NMEA over serial 1’ as an option you will need to then go to NAVconfig > Interfaces > Serial 1 Output and ensure that GPGGA and GPHDT are switched off. 

Please note:

If you are using NAVsuite 3.2 (a release prior to November 2021) then there is a bug in the software of NAVconfig that prevents NMEA over serial being configured properly for the xNAV650. You can solve this by downloading the latest version of NAVsuite from the website or with this simple change:

When you select to use NMEA over serial you will have two lines in the configuration file that need a small change. The configuration file is stored on the device as ‘mobile.cfg’. You will have to change the two lines:

-output1_nmeagga_1.000 and

-output1_nmeamode_standard

to

-output_nmeagga_1.000  

-output_nmeamode_standard

Essentially, you just remove the ‘1’.

PTP: To use PTP you will have to follow the instructions given in the PTP quick start guide. You will also need to make sure the PTP messages are in the correct epoch. This can be done in the setting up stage in NAVconfig or in post-processing with Georeferencer. If using NAVconfig, go to the Advanced Tools and then Commands tab and add in a command to give the correct offset. For example, if you are using a Hesai LiDAR, you can check the manual for the relevant epoch which is UTC and apply the command that transforms the default GPS epoch to the UTC epoch which is '-ptp_custom_offset_315964782'. The same transformation can be done in post-processing in Georeferencer. Georeferencer uses nanosecond transformations instead of seconds so 9 zeros have to be added to the time. For this same offset, use the advanced command 'lidar_time_offset=315964782000000000'.

NAVsuite 3.3 (November 2021) will have the PTP options displayed in the GUI in the interfaces section.

An important point is that some LiDAR will be using the PTP for timing, not just synchronisation, for example the Livox which does not receive NMEA messages. IF using PTP, it is best practice to ensure the INS is booted up and sending PTP messages before the LiDAR. The reason for this is that the LiDAR may start its timing and when it receives PTP messages it will synchronise its clock but not change its time. The correct time is needed for correct georeferencing. 

PPS and NMEA: Now is also a good time to ensure that the hardware is working as expected. Particularly you should check that the LiDAR and INS are powered on as expected and data is sensible. Another good sanity check often is to probe the LiDAR to check if it is receiving PPS and NMEA messages. This can often be done in a web interface by typing the LiDAR IP address into a web browser or in the case of the Ouster using TCP commands (get_time_info). For example, if using a Velodyne product, you can use the Velodyne web interface to make some checks. Putting the IP address of the VLP into a web browser will bring up the web interface (see Figure 5), you can check there that the PPS is locked and that there is a real time GPS position (the LiDAR is receiving NMEA data). Additionally, you can open VeloView to see the LiDAR data in real time.

The Velodyne web user interface is accessed by typing the IP address into a web browser tab. Check that PPS is 'Locked' and the GPS Position is updating in real time (and so the LiDAR is receiving NMEA).

Data can always be viewed coming in with software such as WireShark and this is another good sanity check and troubleshooter to see that the correct data from the correct IP addresses is being received.

TCP commands: With a number of LiDAR you have to use TCP commands to interact with them. These might be used to retrieve a JSON file from an Ouster unit or a calibration file from a Hesai unit for example. The JSON file is essential for processing with Ouster and the calibration file improves pointcloud accuracy. You can send TCP commands by downloading 'NMAP software and then in Powershell typing the command. For Ouster this can be done by: 'ncat <IP address of unit> <port number mentioned in manual>' and then the command that is mentioned in the manual. For example, a useful command for checking that NMEA messages are being received correctly is 'get_time_info'. 'get_beam_intrinsics' will retrieve the azimuths and elevations that are needed in a JSON format to process with. Importantly, you cannot access the LiDAR on any other interface such as WireShark or OusterStudio when sending commands.

It is encouraged that you check that the correct data is being logged and to have a trial before starting your survey. It is also recommended that you have folders set up for putting data into as it comes in.

Initialisation

It is important that your INS is initialised while it is taking data, this is because initialisation is used as part of the synchronisation check between the LiDAR and NCOM data, NMEA messages also have a validity flag that is disabled for uninitialised data. Initialisation is when your INS device locks onto its location and heading. You are able to view in NAVdisplay if your system is initialised or is ready for initialisation. You do not have to begin your survey initialised but at least one third of the time your data file is recording you should be initialised. In NAVconfig > Environment you can set your initialisation settings to use static (requires dual antenna) or dynamic initialisation. For UAV use you will likely need static whereas for mobile use it is recommended that you select dynamic and ensure that you can drive in a straight line to initialise the device.

In the bottom right of the default template the 'NCOM Navigation Status' indicates if the system has been initialised. 

Warm up

It is most important that a suitable warmup is performed to get the device into spec. This takes about 10 minutes following initialisation and consists of doing a variety of manoeuvers to get the device's Kalman filter warmed up. To get the best output from your unit you can read here. Ideally you would want a long, exhaustive warmup and to make sure your setup is known as tightly as possible for the very best possible survey data. You can follow NAVdisplay to monitor the accuracies the INS is reporting.

Only use the improve configuration feature if you have RTK corrections. Meaning that if you are relying on rinex files from base stations in post-processing, don't use the improve configuration feature in real time but rather use it in post-processing. 

LCOM logging

LCOM is essentially PCAP data recorded directly onto the INS, this is possible for 16 laser LiDARs or less due to the data rate. While taking your data, you may wish to break up your survey into multiple runs. This can be done easily using NAVdisplay. If you are viewing your INS data in real time then you can click in the command box at the bottom of NAVdisplay and type "!log log on" and "!log log off" and then click send to stop and start data logging if using onboard logging. The RD file will continue to log as it runs in a separate process of the firmware but the LCOM will stop, you can view this happening by using an FTP connection and seeing that the file size does not grow after refreshing. You can use the same RD file for multiple surveys later. LCOM files are identical to PCAP except that ethernet headers are not saved. 

PCAP logging

WireShark is particularly useful for recording data. If using WireShark, select the incoming stream of data (e.g. Ethernet 2) and you can view the LiDAR and INS data coming in. Right click the IP address of the LiDAR and then choose filter on selected to see only the LiDAR data. Stop and start the data stream as you wish to survey and save these as PCAP files (WireShark's default file type is PCAPNG). 

• • We recommend that you use WireShark for Velodyne so that all packets including the NMEA are included.
  • If using Ouster LiDAR, packets that come into WireShark need to be reconstructed. This can be done but takes much effort and so it is recommended that OusterStudio is used for recording Ouster data.
  • For Hesai LiDAR we recommend PandarView for recording data.
  • For Livox LiDAR, you will need to open Livox Viewer and press 'play' so that packets are coming through. You will then be able to see packets coming through on WireShark which you can record a PCAP on.

A single RD file is usually sufficient for the whole surveying day with multiple surveying files taken at suitable times due to relative file sizes.

Typical files

A typical data collection will contain one RD file and two LiDAR PCAP files containing:

The RD file logs continuously throughout all of this (alternatively a separate warmup RD can be logged). The navigation data file starts with an initialisation by driving in a straight line. This is followed by 5 minutes of warmup manoeuvres. Next a boresight calibration takes place and a PCAP file is saved for it separately but the RD file does not stop. After this the survey can be completed for which the second PCAP is recorded. A short warm-down is completed followed by a reverse-initialisation (come to a stop in a straight line from your initialisation speed eg 5m/s). 

• RD file containing all movement (alternatively save your warmup separately)
• PCAP for boresight (alternatively can be part of the survey PCAP but data files can get very large)
• PCAP for survey

If you open OxTS Georeferencer you will see that you require 4 files in the Files tab in Georeferencer 2.0 (5 files in previous version). These are an NCOM file, a LiDAR and an LIP and LIR (and VAT file). All of these files are simple to obtain after completing your survey, they can also be available during your survey. You can simply drag your files from File Explorer into Georeferencer. Before processing you will then have to select from the drop-down box which LiDAR it was you used.

If you are using Georeferencer 2.0 you will see that only 4 files are required and the NCOM journey on Bing maps. 

NCOM

You will need information about your vehicle trajectory in order to georeference. This will be in an NCOM file. To obtain your NCOM file you will need to retrieve your raw data file from the INS and then process it into an NCOM. You can FTP to the INS via an ethernet connection and download any files you need, this can be done with File Explorer or Filezilla and you can then download the files to your computer. In File Explorer type ftp://192.168.1.xxx where the x's are the IP address of the INS (see Figure 8). The time that the data log started is recorded in the name of the file. When you have the RD file you will need to process it, this is done using our NAVsolve software and you can find a guide for processing your RD file here.

Ensure when processing the RD into an NCOM that local coordinates are enabled. This can be done in NAVconfig or in NAVsolve in Process > Local Coordinates. Check in NAVgraph that the data appears as it should, you can check the pitch and position accuracies to see if the device was in spec. Ensure also that your local coordinates are sensible and are representative of where you surveyed, it is possible that 0, 0, 0 has been selected which will not give the best results. 

Using an FTP connection (ftp://192.168.1.13) to the INS to retrieve the two most recent files in its data. You can use an FTP connection in real time to check that the INS is logging the RD and LCOM file by refreshing the File Explorer window and viewing the file size. The highlighted RD file was created on the 12th February 2020 (20/02/12) at 15:24 as seen in its filename.

You might find that you want to use a cropped NCOM file to make the workflow easier. This can be done easily in NAVgraph.

1. Open the NCOM file in NAVgraph
2. Press 'R' and select the region of the NCOM you wish to crop out. The region will be opened in another tab.
3. In this tab, right-click and select 'Export' and then save it as a binary file format. This will save an NCOM file of only the region you selected.

LiDAR

The second file you need is a LiDAR file, this can be LCOM or PCAP. An LCOM file can be found on the INS via an FTP connection if you set up your devices for this. If you didn't setup your devices to record LCOM then you will have recorded a PCAP during the survey run via some software like Wireshark or Veloview. You will need to take this file from where you saved it and drag it into OxTS Georeferencer. 

The first check that OxTS Georeferencer makes is that the LiDAR data is PPS synchronized and has NMEA data, this will depend on if you have set up the device connections correctly. If the data passes this check you should see a tick. If the file fails synchronization, consider your setup again and check any connections and network configurations you have, you should be able to do this in real time (see above sections). Remember that the INS must be initialised for the LiDAR log to have the required synchronisation. To be able to process your pointcloud the NCOM and LiDAR data must align in time as well. Opening an NCOM in OxTS Georeferencer will show your journey route overlaid on Bing maps to help you check which survey the NCOM corresponds to. A pointcloud will be created for the time that the LiDAR and INS data overlap.

VAT

In OxTS Georeferencer 2.0 the VAT file no longer needs to uploaded as the angles are taken straight from the NCOM file.

The VAT file is the angular configuration of the INS with respect to the vehicle frame. You must put in some preliminary measurements for this when setting up in NAVconfig but the system will intelligently improve the angles throughout the journey. You therefore do not have to make a VAT file yourself. After processing your raw data file the VAT file will be available in the "Process_..." folder or the "ConfigurationFromRawData" folder created by NAVsolve. The VAT file is a simple text file with a .vat extension.

When you input your initial measurements for the VAT in NAVconfig, you will likely be measuring to the nearest 5°. However, these angles are very important for high precision pointclouds and therefore need to be known to points of a degree. The INS will intelligently improve the angles to this degree but you must ensure you use the improved measurements.

VAT angles can be included in the orientation of the hardware setup in the Hardware tab. A black arrow shows the direction of the vehicle. These can be turned off so only the LiDAR orientation with respect to the INS is shown.

LIP and LIR

The LIP file is the positional configuration of the LiDAR with respect to the INS frame. This is the x, y and z displacement from the INS measurement point to the LiDAR device, each of these measurements is on their own respective line in a simple text file with an .lip extension. You can create an LIP file by clicking on the LIP plus icon in Georeferencer and then input the numbers in the Hardware Configuration tab. You should have measured these while setting up and they should be as accurate as possible. A feature of the boresight calibration that is in beta is the LIP calibration. This will calibrate the LIP values. We recommend that you calibrate the LIR values and then the LIP values if using this feature. The format of the file is:

x (yaw) measurement

y (pitch) measurement 

z (roll) measurement 

1 or 0 (indicates if data has been calibrated)

Screenshot of Georeferencer's Hardware Configuration tab.

Make sure that the displacements are measured form the measurement point of the IMU (this is shown on the INS exterior) and not simply the centre of the device. 

LIR

It is very important that this file is correct.

The LIR file is the angular configuration of the LiDAR with respect to the INS frame. This is the relative yaw, pitch and roll displacement between the INS measurement axes and the LiDAR device axes (x, y, z), each of these measurements is on their own respective line in a simple text file with an .lir extension. You can create an LIR file by clicking on the LIR plus icon in Georeferencer just like the LIP.

Measure the angles as best you can between the orthogonal axes of the LiDAR and the INS. The INS axes are printed on the device and shown in Georeferencer. The axes for the LiDAR device will be shown in the user manual and they are typically different for each LiDAR. Ideally take photographs of your setup to troubleshoot this process especially if you want support from OxTS. If you are using any LiDAR in Georeferencer 1.4 then you will be able to see a 3D model of your LiDAR with the correctly oriented axes in the viewer. Simply check that the angles are correct and if they are they are off by some degrees you can use the boresight calibration to fix the configuration. You can also view the INS and LiDAR configuration as it is oriented on the vehicle you are using.

If you happen to be using a LiDAR that is not supported by a 3D model in Georeferencer (e.g Livox) then you can use a blue cube model that shows the INS axes on it. Simply rotate the axes to where they are in relation to the INS by checking how they are oriented in the LiDAR manual. For example:

Screenshots from the Hesai 40P and Livox Avia manuals.

The best way to do this is to make the angles between INS and LiDAR multiples of 90 or close to it. You can then make sure that the axes in the hardware tab on the LiDAR are where they should be. You will likely have to work out the correct combinations of rotations to get the correct setup, do this by performing each rotation one after the other: yaw, pitch and roll. 

Example of determining the LIR for a Livox setup using the blue cube model.

1. Check the manual for the LiDAR unit axes and visualise how these relate to the INS axes. For example, the y axis of the VLP16 points the opposite direction of the cable and the z axis points up. 
2. Work out the correct combination of rotation to rotate the axes of the cube into the correct LiDAR axes. To begin with a 0, 0, 0 LIR corresponds to having the same axes as the INS but we need to rotate the axes to reproduce the image on the right above.
3. This can be done by applying first a 180 yaw rotation followed a 90 pitch rotation and a 90 roll rotation so an LIR of 180, 90, 90 is used in Georeferencer.

You can make estimations for the correct axes beforehand and then edit them in the Hardware tab of Georeferencer where you can view the configuration. In addition, if you have done a boresighting run, make sure you use the boresighted LIR values. A boresighted LIR file will have a flag value of '1' on a fourth line to signify it is optimised.

Example LIR, LIP and VAT files are available at the bottom of the page.

In the Files tab you can create the LIP and LIR files by clicking the plus icon. The files are then edited and viewed using the Hardware Configuration tab.

The hardware tab allows you to view your configuration and make alterations to the LIP and LIR files. The above compares the view from previous versions of Georeferencer to the new version (bottom) for the same setup.

JSON/calibration file

If using an Ouster LiDAR then you will need to input a JSON file that you've taken from the unit. This can be done easily using OusterStudio and choosing the second icon down on the left. Save the JSON file in the same folder as the PCAP with the same name. Alternatively, use the TCP command get_beam_intrinsics and put the the output into a JSON file format.

If you are using a Hesai LiDAR, you might have a calibration that you would like to include in the data processing. This can be uploaded.

In previous versions of Georeferencer, the JSON file needed to be included in the same folder as the PCAP with the same name but a different file extension. In Georeferencer 2.0 the file can be uploaded to Georeferencer in the processing options tab. 

Boresighting is OxTS’s in-built calibration method. When you make your angular offset measurements they can be quite difficult to make accurately. A small angular error can make a large difference to a pointcloud and significantly lower the quality of your survey. We recommend you boresight your configuration before carrying out a survey; but once a setup is boresighted it will not need to be boresighted again. Boresighting will make your LIR and LIP file much more accurate and prevent blurred images or ‘double vision’ that may occur. A guide for boresighting can be viewed here.

Boresighting Reflectivity: The reflectivity threshold ought to be set to a value that will include only the boresighting targets and no other points. For most LiDAR this is calibrated to be around 100. This can safely be increased to say 150 should you see too many non-target points. To see what values of reflectivity points have, georeference your pointcloud and check the 'Intensity' field. Most ordinary points will not have intensities over 40.

In Georeferencer 2.0 you have the option to use the dimensions of the targets to further optimise the boresighting algorithm and the correct reflectivity based on the LiDAR will be chosen by default. A filter can also be used to only boresight using the most accurate points so inaccurate points do not spoil the calibration.

Boresighting Options where you can select calibration type.

In the Boresight Options within the Processing Options section of Georeferencer you can choose LIR optimization, LIP optimization or both. LIR calibration will calibrate the angles in your setup and is very robust. LIP calibration is in beta mode and will be improved in following versions of Georeferencer. LIP calibration works very well in some cases and in some cases it does not work depending on the quality of the georeferenced data. We recommend that you calibrate the LIR only to begin with and if necessary then you the LIP only calibration. 

Example comparison of an unboresighted (left) and boresighted (right) LIR and LIP (orientation) file. The calibration is able to refine the orientation much finer than it is possible to do by sight.

Example of a pointcloud before (left) and after (right) boresighting.

An article on using advanced commands in Georeferencer can be viewed here. To quickly view advanced commands in Georeferencer you can upload some files and then type in an invalid advanced command and click 'Run Georeferencing'. This has not yet been updated for Georeferencer 2.0.

Coordinate Options

Local Local coordinates uses a local coordinate origin that is set in NAVconfig or NAVsolve when creating your NCOM. Make sure this is done before using Georeferencer. The easiest way is to set this in real time from the unit using NAVconfig in the environment tab. The trajectory of the INS will then be mapped to x and y coordinates relative to the origin you choose. The pointcloud file will be given in local coordinates and can be viewed in software like CloudCompare.

ECEF (WGS84) ECEF (Earth Centred Earth Fixed) coordinates is a global coordinate system that can be used instead of LLA or local coordinates. A LAS file in ECEF is not viewable in some software such as CloudCompare.

LLA (WGS84) LLA (Latitude, Longitude, Altitude) coordinates are global position coordinates taken from the INS data which will typically be in WGS84. A LAS file in LLA is not viewable in some software such as CloudCompare.

Metadata It can be useful to have the coordinate datum used stored in the metadata of your pointcloud file. This can be interpreted by other programs and used for viewing the pointcloud in the correct way or converting to other systems. No change is made to the point data values. 

Ensure that your pointcloud viewing software can correctly interpret the coordinates you choose (see more in the section below Viewing and analysing data). For more options on using a pointcloud with global coordinates, please see this article Global coordinates with Georeferencer. 

Percentage of points: Requires Georeferencer 2.0. This is a very simple random filtering of the points to include only a specified percentage of the total points in the pointcloud. This is useful for creating low resolution files for troubleshooting or data handling.

Voxel filtering: Requires Georeferencer 2.0. This is an advanced filtering option. Selecting this option will filter the pointcloud so that only the most accurate point within a cell of the specified size remains. This is particularly useful so that accurate and inaccurate points are not both included which amount to a noisy pointcloud. For example, selecting 0.05 means that for each 5cm^3 cell of the pointcloud, the point that remains is the most 'accurate' based on the error estimation formula. This will give you much smaller files with better quality control.

Note that this option uses a large amount of RAM especially at small cell sizes. 

Range: A useful feature for different applications is the ability to choose the distance range of points that OxTS Georeferencer will turn into a pointcloud. This is done by changing the minimum and maximum parameters under 'Range Between which points will be written (m):' section in Files > Processing Options. If you want to only see a road for example and not surroundings far away then you can restrict the range to 0-10m. If you wanted to only see over a certain range, in some geographical application for example, you can set the range to 10-100m. If the LiDAR had some part of the vehicle visible in its field of view then put a minimum distance of two meters so the vehicle is not seen throughout the pointcloud.

Elevation: Requires Georeferencer 2.0. The elevation angle is in the vertical plane of the LiDAR. Typically the 0 is the horizontal plane and angles span some positive and minus deviation from this as shown below for the Hesai XT32.

Azimuth: Requires Georeferencer 2.0. The azimuth angle is in the horizontal plane of the LiDAR. For mechanical rotating LiDAR it is the plane in which the laser channels spin. Please check your LiDAR's manual for where the 0 point is of the plane. For example, Ouster has the 0 on the connector as shown below, therefore if I only wanted the half-view opposite to the connector I would select 90-270 for the azimuth angles.

Speed: Requires Georeferencer 2.0. A useful filter can be the speed of the vehicle when the points are surveyed. The default filter is 0-500m/s but if you select a lower end of 0.1m/s then you remove points from times when the vehicle is stationary and thus less accurate (INS performance varies and is roughly 50% less accurate when stationary).

Please note that this feature does not work if you are using survey NCOM. Meaning that if you have not purchased full NCOM this filter cannot be used.

Output point normals: Requires Georeferencer 2.0. This option will allow point normals to be reconstructed from each point. This is the vector direction of the LiDAR to the point when it is surveyed. Three scalar fields are used, one for each axis, to specify the normal vector. This allows map construction or meshing to be done by using the direction the point is surveyed from to specify a surface. Georeferencer does not do this construction but does provide the point normal data in the LAS file for anyone who wants to pursue surface reconstruction.  

This option only works for LAS/LAZ output.

Images from CloudCompare showing the scalar field options on the left and the pointcloud image on the right for a road survey.

Output trajectory cloud: This option will produce a second small LAS file in the same output folder. This LAS file includes points of the NCOM position. Therefore for a road survey you will see a line of points simply going along the road. This will show the position if the INS at every instance (100Hz).

If you would like to see the position of the LiDAR not the INS you can reprocess the NCOM using the 'displace output' option in NAVconfig (using the LIP values). Note that you will have to use the NCOM without a displaced output to create the LiDAR pointcloud and then the second NCOM just for the LiDAR trajectory.

Use only valid NMEA: This toggle option allows you to choose between processing only valid NMEA messages or all NMEA messages regardless of their flagged validity. You may unclick this box if you forgot to do an initialisation at the start of your dataset but want to process the data anyway.

Start and end times: Georeferencer shows an overlap of the LiDAR and NCOM data times. You can choose a section of this to process and the trajectory between those times will be shown on the Bing map. Simply drag the bars to border your desired section. 

Reflectivity: A useful option is changing the reflectivity threshold and the number of iterations that the boresight procedure goes through. If boresighting does not appear to work or it only works in one or two axes then increasing the number of iterations the software makes on the data can often fix the problem. The reflectivity threshold is perfect for troubleshooting if you do a boresight run and want to know why something isn't correct. Increasing this to 100 for a Velodyne for example will give only the targets in a pointcloud only a few hundred kilobytes (see below). 

Livox LiDAR must use 150 for the reflectivity threshold for boresighting. 

Many of the advanced settings are achievable in pointcloud post-processing software but due to the large file size it is often more useful to do it during the creation of the pointcloud. 

PTP Time Offset: A time offset might have to be applied to the LiDAR time packet data to work with the navigation data when using PTP. This is added by an advanced command. Use the 'lidar_time_offset=x' advanced command to add x seconds to the time packets of the LiDAR data.  This can be used if the correct PTP setting is not used. The INS and LiDAR may use a different epoch, for example the INS on GPS time and an Ouster LiDAR on UNIX time. 

PTP settings can be configured in a variety of ways. See the quick start guide for PTP here. You will need to ensure that the settings you choose are what is required by the LiDAR, to do this check the LiDAR manual for the time standard that s used. Failure to do this will result in an error when georeferencing is attempted that can look like "Reached end of LCOM stream". 

Ouster will require the fourth option from the table. Unix to UTC time is an offset of lidar_time_offset=3159648180000000000 (10 years).

For use with Hesai data for example use 'lidar_time_offset=315964804000000000' (10 years and 18 seconds). This brings UNIX time to match GPS time. 

In Georeferencer 2.0 these PTP options are all in the GUI and are easily configured:

Error threshold: The 'Error threshold' option will allow you to only process data into the pointcloud that is above a certain threshold of uncertainty. If you wish for all points in your pointcloud to be above say 8cm accurate then entering 8 into the Error threshold will give a good estimation of this. This error data is shown in the 'UserData' scalar field that is viewable in pointcloud viewing software such as CloudCompare so you can see the uncertainties of each point in a section of a survey based on the navigation data.

A default filter of 10cm is applied in Georeferencer. If you wish to turn off the filter then increase the value to 1000 for example.

A survey along a road. In red, data can be seen where the surveyor lost RTK accuracy, this section can be removed using the Error threshold option or in pointcloud viewing software to give only the most accurate data.

The error estimation uses a sophisticated formula that combines LiDAR uncertainty and NCOM uncertainty to estimate the absolute uncertainty of point positions surveyed by the LiDAR. NCOM uncertainties are themselves estimates that the INS Kalman Filter outputs. These uncertainties can be viewed in real time in NAVdisplay and are based on simulations. A lot of work goes into tuning the Kalman Filter to estimate the uncertainty to which values are known. Contributions from boresight misalignment are not considered and the values are modelled on the accuracy of a VLP16 LiDAR; other LiDAR units might be more or less accurate in their range but they will likely be similar and the main contributions from the IMU.

The highest uncertainty estimate, which will appear as dark red as standard in software such as CloudCompare, is set to 50cm which is representative of going into SPS mode (no base station corrections). 

NCOM outputs accuracy diagnostics as calculated uncertainties in all conditions in real time and these are used to estimate the uncertainty in the points' positions. These outputs include estimations of the uncertainty in heading, pitch and roll, North and East position and altitude and all of these are combined in the formula.

The following tables give the translation between the UserData field value between 0-255 and the cm position uncertainty of the points given by the formula. Also included are the ranges at which these uncertainties are achieved for a unit that is working at specification in good GNSS conditions (open sky and no obstructions):

xNAV

Survey+

With your 4 compatible files (5 including the VAT if you are using a version before 2.0) you will be able to click Run Georeferencing. This will create a folder in the directory that the NCOM data is in or where you specify in the Files tab; the folder will contain your pointcloud, the LIP, LIR and VAT used and 2 processing logs.

Ouster

Remember that for Ouster LiDAR you need to include the JSON file of Azimuths and Elevations in the same folder as the PCAP and under the same name. For example, for a PCAP named OusterSurvey.pcap include OusterSurvey.json in the same folder. In Georeferencer 2.0 you can direct the software to the JSON file in the processing options calibration file option. Also remember that the PTP options must be correct. Ensure you have used Unix time for PTP and you might have to apply an offset of -18s (the advanced command for this is 'lidar_time_offset=-18000000000').

Hesai

For Hesai LiDAR, remember to include the calibration file. A spreadsheet of elevations and azimuths for your LiDAR is available either on an included USB stick or retrievable from the unit. Include this in your processing by Clicking on 'Processing Options' and 'Calibration file' and navigating to your file. Also remember that the PTP options must be correct. Ensure you have used UTC time for PTP and you might have to apply an offset of -3.16s (the advanced command for this is 'lidar_time_offset=3159648040').

Georeferencer can create pointclouds in LAS, LAZ (compressed) or PCD formats. This is chosen in the Files > Processing Options tab. The default is an LAZ file.

You will now be able to view your pointcloud in your choice of pointcloud viewing software (eg CloudCompare, QT reader or others).

If you would like example sets of data please get in touch or download straight from the website. We also appreciate you sharing your data with us.

Example of cloud being viewed in CloudCompare after being processed in OxTS Georeferencer.

You can view your LAS file in a number of different third party software applications. OxTS does not support or offer any of these. 

If you are looking to use global coordinates (ECEF or LLA) then ensure that the viewing application can interpret these. CloudCompare for example will only read local coordinates. Global Mapper will display LLA coordinates correctly. 

An LLA pointcloud overlaid on satellite imagery using Global Mapper. 

ECEF Cartesian coordinates work in the following frame:

1. whose centre is at the Earth’s centre of mass;
2. The x axis points towards the intersection between the equator and the Greenwich Meridian (in the Atlantic, a few hundred miles west of Equatorial Guinea).
3. The z axis points towards the geographic North Pole (i.e. latitude of 90).
4. The y axis points towards the intersection between the equator and longitude 90.

Therefore you might expect to see an angle equal to the latitude of the horizontal plane of the pointcloud with respect to the local coordinates. There could also be a 90degrees rotation. 

• 40P PTP: An issue is known with the Hesai 40P that has firmware from at latest July 2020. A +3.16 second offset must be applied to the data if using PTP to synchronise your devices. This can be done in real time suing the PTP commands or in Georeferencer with an advanced command of 'lidar_time_offset=315964804000000000'. We assume that this would apply to other Hesai LiDAR with previous firmware, it does not occur for the Hesai XT. 
• Gimble lock boresighting: There is an issue that can come up when boresighting a hardware setup where the INS and LiDAR are at 90°. When this is so, a situation known as 'gimble lock' can occur where changes to roll and pitch are treated identically in the algorithm and the angles do not converge. We hope this will be fixed in Georeferencer 2.0.
• Foreign keyboard errors: If you have your keyboard set in a different language than English then there may be errors in output.
• VLS128 Alpha Prime: There are undiagnosed issues with processing data from the Alpha Prime. 

Please let us know if you are concerned that you have found an issue or a bug with our software and we will log it and endeavour to fix it. 

This section will cover some problems that one can encounter while using Georeferencer and some potential solutions.

• Empty pointcloud: It can happen that you georeference your pointcloud and the LAS file that is generated is empty or 1kB. There can be several reasons for this:
  • Check that the processing was actually completed. Opening the folder and file before the processing is completed will show an incomplete or empty pointcloud file.
  • Check the filters. It is likely that one or more filters are removing all points from the LAS file. 
    • • Error threshold: The default value of the error threshold is 10cm. If you have not used base station correction then the absolute (not relative) accuracy of your system will be higher than 10cm (around 35cm) and therefore all points will be filtered out. Change this to 1000cm to be sure. 
      • Speed: If you have a unit with survey NCOM and not full NCOM then your unit does not output speed as a measurement and the speed filter does not work. If you have a minimum speed that is anything except 0 then it will filter out all points. Set this to 0 if you have survey NCOM. 
• Other objects during boresighting: If your LiDAR unit is not calibrated to have retroreflective objects at a registered reflectivity of 100 (out of 255) then the default boresight calibration might not work. If this is the case then you can select 'processing options' before calibrating and change the 'reflectivity threshold' on under 'boresight options' to a higher number e.g. 150. It might also be the case that the LiDAR is picking up part of the vehicle, this can be removed by using a minimum range.
  
  Example clusterplot with the default reflectivity threshold of 100 using a VLP32. Instead of just the targets many objects show up.
• Target smearing: If your setup or navigation data is poorly configured then the targets may be too smeared out to correctly boresight. When choosing the locations of the targets on the clusterplot page you must ensure that the blue circle encompasses all of the points that correspond to a target and also that no other retroreflective points are encompassed in the circle. If you can't make this happen you may have to manually measure your setup better until it is good enough to boresight. Also, try removing the first part of your survey where the INS may still be warming up.
  
  If there is major smearing in your pointcloud or boresight clusterplot then this will be one of two issues: an incorrect LIR or a time offset between the navigation and LiDAR data. Triple check the LIR of your setup using the LiDAR manual to view the correct orientation axes. If you are using PTP as your time synchronisation method then a time offset might be present depending on how time epochs have been implemented on the receiving device. For example, if using an Ouster LiDAR you might have to apply a -18s offset. In 2.0 this can be easily done by selecting Unix and a -18s offset. In previous versions of Georeferencer you can use the command 'lidar_time_offset=-18000000000’.
• Pointcloud 'lite': A common technique for troubleshooting boresighting is to produce a light pointcloud by setting reflectivity to 100 and running georeferencing.
• Time overlap: If the navigation (NCOM) and LiDAR (PCAP) files that you have chosen do not overlap in time Georeferencer will not be able to produce a pointcloud. You should doublecheck therefore that the files you are trying to use are the correct ones. If they are then you might have a more fundamental problem on the hardware level. You should receive an error message when you attempt to process that indicates your files were not taken at the same time. You might receive an error looking like "Reached end of LCOM stream at time: 1285502583250000000
  FAT:G.1.3: Failed before attempting georeferencing". 
• PCAP recording: When recording your PCAP there are several things to consider. If you have used software such as WireShark then you will need to ensure that you save the data as PCAP (not PCAPNG) and that only the LiDAR data and LiDAR NMEA packets are present. This can be done after recording by using a filter for the LiDAR IP address.
  Ensure that if you are using a LiDAR that requires NMEA you record the PCAP and the NCOM starting within the same clock hour as the hour is not outputted in the LiDAR data.
  WireShark or similar software is not suitable for recording Ouster data as the packets will not be organised in the correct order that OusterStudio puts them into. Veloview can not be suitable for Velodyne data as it may not record the NMEA data in the PCAP file.
• Poor definition in pointcloud: The two main causes of a poor pointcloud will be poor navigation data or poor setup calibration. To view how well your navigation data has performed, open the NCOM file in NAVgraph. Right-click the graph and click 'Configure graph' and then 'Add measurements'. Select 'position accuracy North' and 'heading accuracy' and 'pitch accuracy' for a good sample. Next ensure that different units are set to different axes.
  
  Next you can view the accuracies. Recall that the specification of the xNAV is 2cm position, 0.1° heading accuracy and 0.05° pitch/roll accuracy. In good data you will find the performance exceeds the specification.
  
  If the navigation data is good then the likely problem is the setup calibration. Ensure that you have followed the steps in the boresight calibration guide. You can check the performance of the calibration by using the calibrated LIP and LIR files and producing a pointcloud at a reflectivity of 120 (in the processing options). You should see a pointcloud with two crisp rectangles that represent the targets used and they should not be smeared.
  
  
• Vibration issues: It is fairly common to have issues with vibration when working with LiDAR. It is important that the LiDAR and INS are rigidly mounted together and the closer the more precise the LIP and LIR files can be. However this presents the obvious issue of vibration as many mechanical LiDAR can have substantial vibrations particularly at high RPM. The INS is sensitive to vibration and any persistent vibrations will limit the INS' ability to differentiate true movement and vibration making it less precise. This issue is best sorted at the source by damping any vibrations getting to the INS. A different way of setting the INS and LiDAR on the vehicle may help also.
    However, there are some ways to improve performance if vibrations are present. One would be to do the initialisation and warmup and configuration improvement with the LiDAR switched off. A second is to use the vibration settings in NAVconfig so the INS knows to expect vibrations and can filter them out. This is not ideal as precision will be limited but it can help to improve data when vibrations are present. RPM of the LiDAR can be reduced also. 
    A way to check vibrations is looking at the accelerations the unit is measuring when it is supposedly stationary. This can be done in real time with NAVdisplay or in PP with NAVgraph. Viewing the lateral vibrations with the LiDAR turned on and off is a good way to check.
• Double vision: Double vision can be caused by a number of factors. This is the phenomenon where objects surveyed at different times or from different perspectives do not appear in the same place.
    The most common cause of double vision would be a poor calibration which can be solved with the boresight calibration tool.
    Another common problem is a lever arm offset. This is where the input measurements, for example the location of the antennas, is incorrect. This could be due to one of two things: The initial measurement (for example the secondary antenna being 1m behind the primary) is not quite correct or there are significant orientation differences. Alternatively, the measurement is too 'tight', this means that the search radius the INS is looking in for the true value of the measurement does not include the true value. For example if you have input 1m as your measurement and the tolerance is set to 5cm but the true value is 1.06m. This will cause the INS to get this measurement wrong and other measurements also to compensate. You can change tolerances in the Advanced>Accuracies tab. We recommend you use the default tolerances. These tolerances will be automatically tightened after you use the 'improve configuration' tool.
    The third most common cause of this issue is a poor initialisation. If satellite conditions are not perfect or the initialisation is done not ideally (for example a dynamic initialisation using a trajectory that is not straight) or if antenna placement is not ideal then initialisation can be off. If this is the case then there will be a permanent error in the heading which can cause drift and double vision after turning. You might get poor initialisation settings also if your config is not correct or the tolerances are too loose. Make sure to initialise in as good GNSS conditions as possible. Receiving RTK corrections in real time can improve the initialisation.

This section will cover some some points that will help you get the maximal clarity in your pointcloud. In general, the performance will depend on three things: the accuracy of the navigation data, the consistency of the navigation data and the calibration of the hardware setup. Of course there will be other errors, for example from the LiDAR accuracy but they cannot be improved. You may be seeing blurring or double vision in your pointcloud which you want to remove, if so, follow the steps below:

A classic example of double vision where the same object appears in a different location at different times (for example up and then down a road).

Quality of navigation data: 

• Antennas: If there is any movement in the antennas whether from vibrations or flexing in their mounting then there can be issues in collecting signals but more importantly error in where the INS thinks the antenna is. Different antennas perform differently in different vibrational environments. Place the antennas as far from each other as possible without compromising on rigidity or accuracy is displacement measurements.
• Warmup: Ensure that your warmup is adequate. For the Survey+ this should be 15 minutes, for the xNAV this should be 5 minutes. However, you can view NAVdisplay in real time to know when you are hitting the specification or exceeding it. For example, keep an eye on heading and pitch accuracy. After a good warmup these should be better than 0.1° and 0.05° respectively on an xNAV. If you are not meeting the specification it might be that your original measurements were not accurate enough. Either correct the measurements or if you cannot, go to NAVconfig>Advanced tools>Accuracies and increase the tolerances on inaccurate measurements. Do the warmup in good GNSS conditions. 

Consistency of navigation data: As well as a maximum quality to get out your INS device you need to consider the consistency of that data. For a pointcloud survey you want the highest accuracy for as long as possible. See in the previous section ways to view performance throughout a survey.

• Antennas: The antennas that you use will affect the performance of the navigation data. If you are in poor GNSS conditions or challenging conditions for example a town, forest, city, anywhere where GNSS signals could be blocked or reflected off of objects then the data will be affected by the antenna used. Higher grade antennas will deal with multipath and capture signals better than lower grade antennas.
• Rigidity: It is very important for all components of your hardware setup to not move relative to each other. The INS will use a fixed measurement for the position of itself relative to vehicle axes and antennas. If these are moving even slightly then significant errors could occur. There might be a resonance on your vehicle that causes vibrations 

Boresight calibration: You will have to make sure that the angles in your setup are as precise as possible. If there are any vibrations or lack of rigidity between the LiDAR and INS the calibration will only be precise to the extent that extent. Very fine accuracies are required. A 0.1° inaccuracy will translate into 0.1x(2pi/360)xRange error in the position accuracy which is about 10cm error at 15m away which is a lot by pointcloud standards. Therefore, the boresight is crucial and it is crucial that it is done in the best conditions. Run georeferencing at a reflectivity threshold of 130 to view a pointcloud that should contain only the targets.

• Rigidity: Vibrations and any looseness in the connection between INS and LiDAR ought to be kept to absolute minimum.
• Displacement: The further apart the LiDAR and INS are the greater the intrinsic additional position error will be due to an orientation error between the two. Keep the two devices as close together as possible. 
• Navigation data: The navigation data ought to be as high spec as possible for the best calibration. Make sure GNSS conditions are perfect (open sky), lever arms are as accurate as possible and a good warmup has been performed. 
• Boards: Ensure that the boards are as flat as possible and reflective enough to differentiate them from any points in their vicinity. Also ensure that the boards are rigid and do not move at all during the calibration survey.
• VAT: The VAT file is very important also. When you put in your orientation (yaw, pitch and roll) measurements into NAVconfig the angles will be to about 1 degree of accuracy and the INS will improve this while it is being used. Ensure that you are using the updated VAT file and not the one you first entered. If you do a warmup then choose 'improve configuration' on NAVconfig the updated VAT file will be saved to the device.