Odometry latency issue in large-scale scenarios

[Tony-tpc]

Hi, thank you for your great work on Adaptive-LIO.

I am currently testing Adaptive-LIO in different indoor environments and noticed an odometry latency issue in large-scale open scenes.

The algorithm performs very well in small indoor environments, with stable and real-time odometry output. However, in spacious environments such as gymnasiums, the scan matching / registration step seems to take significantly longer. This causes incoming point cloud messages to accumulate in the processing buffer, and eventually leads to delayed odometry output.

In my case, the latency appears to be related to the increased matching time in large and less-structured environments.

I would like to ask:

1. Are there any recommended parameter settings for large-scale open environments?
2. Should I increase the voxel filter size or reduce the number of input points?
3. Is there a recommended strategy to prevent point cloud buffer accumulation?
4. Is frame dropping acceptable when the odometry processing cannot keep up with the LiDAR frequency?
5. Are there any specific modules in Adaptive-LIO that should be tuned to improve real-time performance in such scenes?

Thank you very much for your help and suggestions.

[chengwei0427]

  icpmodel: CT_POINT_TO_PLANE # Options: [CT_POINT_TO_PLANE, POINT_TO_PLANE]
  size_voxel_map: 0.5 # The voxel size of in the voxel map


  sampling_rate: 1.5
  max_num_residuals: 1200
  min_num_residuals: 50
  motion_compensation: CONSTANT_VELOCITY #NONE, CONSTANT_VELOCITY, ITERATIVE, CONTINUOUS

In outdoor environments, size_voxel_map can be appropriately increased to around 1 m. The motion_compensation option can be set to CONSTANT_VELOCITY, and the icpmodel can be configured as POINT_TO_PLANE.
In addition, increasing the sampling_rate and reducing max_num_residuals can also help improve processing speed. However, these adjustments may affect accuracy, so they should be tuned based on actual runtime performance.
Furthermore, having a more powerful CPU is also important for maintaining real-time performance.
At present, the algorithm pipeline does not support frame dropping.

[Tony-tpc]

Thank you very much for your suggestions.

After adjusting the parameters, the computational efficiency improved significantly, while the robustness was still acceptable in my tests. The current configuration is approximately:

icpmodel: CT_POINT_TO_PLANE
size_voxel_map: 0.5
sampling_rate: 1.0
max_num_residuals: 600
min_num_residuals: 50
motion_compensation: CONSTANT_VELOCITY

However, I also noticed a possible issue in RadiusSearchInPlace() for large open environments. In sparse scenes such as gyms or halls, many valid voxels may contain only a few points. The following condition may discard these useful but sparse neighbors:

Adaptive-LIO/src/common/map.cpp

Line 170 in dcba96f

if (voxel_block.NumPoints() < threshold_voxel_capacity)

This may cause neighborhood.size() to become too small, which can affect point-to-plane matching and odometry stability.

A possible improvement may be to lower threshold_voxel_capacity in sparse environments. Another option is to expand the voxel search range adaptively when too few neighbors are found.

Thanks again for your help. The parameter changes have already improved the real-time performance significantly!