Real-Time Point Clouds and MTA Disambiguation

Users can see real-time LiDAR point clouds with SpatialExplorer, so long as a few conditions are met:

  • A reliable UDP connection is established with the LiDAR system (either via WIFI, ethernet, or a 4G cellular connection)

  • The navigation system has determined it's initial azimuth.

  • The LiDAR is set to ACT, meaning that it will stream real-time points. In SLT mode (silent mode), the LiDAR will only log to storage.

A complete lack of real-time points is typically caused by one of the above conditions not being met. If real-time points appear but are nonsensical, this could be caused by incorrect MTA disambiguation. Users can control how MTA ambiguities are resolved by configuring the MTA range gate or by uploading heightmaps to be used for MTA disambiguation.

The following section regarding MTA disambiguation applies only to the real-time visualization of point clouds and will not affect any RXP files that are collected. For MTA disambiguation during post processing, which should always be performed with Riegl scanners, see SDCX conversion documentation.

MTA Disambiguation in Real-Time

MTA (Multiple Time Around) ambiguities can distort real-time point clouds, making them mostly useless to the operator. MTA ambiguities arise when more than one LiDAR pulse is in transit at a time, and the receiver must determine which of the multiple pulses is in fact returning to the receptor. There are several methods that can be used to improve proper real-time geolocation of points when MTA ambiguities are a concern.

MTA Range Gate

The MTA range gate specifies the start and stop of MTA zone 1. The end (or max) of MTA zone 1 is predetermined by the measurement program pulse repition rate, however the start (or min) of the MTA range gate can be specified by the user. This is useful to prevent points, which truly belong in MTA zone 2, 3, etc., from incorrectly being placed in MTA zone 1 - this can appear as an "MTA tent", where points accumulate near the scanner, when in reality they should be georeferenced much further away from the scanner.

Set the minimum range of the range gate to a reasonable value based on the scanner's distance to scanning targets (e.g., for an aerial acquisition at 120 m, the scanner is unlikely to get any returns within the first 40 m, so 40 m would be set as the min, and the max will automatically be computed).

Heightmaps

In rover's logs directory there is a folder specifically for storing heightmaps:

Heightmaps used for MTA disambiguation can be uploaded to this directory. The heightmaps are used by rover in real-time to aid in placing points in the correct MTA zone. Heightmaps must reference WGS84 as the datum and use ellipsoidal heights. Height maps can be downloaded from https://grids.phoenixlidar.com.

Filter by grid type to only show SRTM 3 arc second grids, which are preconfigured to the correct datum and height type. Download the SRTM grid that corresponds to your scanning location and place the grid in rover's heightmaps folder.

Once rover starts up, it will check if a heightmap is available in the heightmaps directory. If a heightmap is available, and if the scanning area is contained within the heightmap's bounds, rover will automatically use the heightmap to for MTA disambiguation. Otherwise, rover will use the MTA range gate settings.

Last updated