Z-drift in Custom Dataset + Loop Closures

[nathanredmond123]

First of all, thank you so much for this amazing project. It has been a lot of fun to read through the paper and experiment on our custom datasets. That being said, I am new to SLAM with neural implicit representations (and SLAM in general) and am struggling with some configurations..

I am currently running in the Docker container if this helps.

First question:

Our dataset consists of approximately 1000 kilometers of forward motion in a relatively featureless environment (think about a runway). There aren't many distinct vertical features in many regions, and at many times the only planar surface is the ground plane. When running PIN_SLAM on this data with Ouster 128 beam LiDAR, we notice that while we do not lose SLAM, there is a significant amount of z-drift that appears to accumulate somewhat linearly. We have experienced this with many other open-source SLAM software (even with IMU integration).

Second question:

After traveling forward for approximately 1000 km, the robot turns around and retraces its steps... With the motions involved in this we should expect a loop closure with default pgo settings in run.yaml, but we do not see this. In fact, we often times see faulty loop closures that completely destroy the structure of the map (forces a ~90 degree global rotation in the middle of the map) and localization is completely wrong afterwards.. We are wondering if there is any way around these faulty loop closure issues we are seeing while enforcing the loop closures that are accurate.. When we remove loop closure from the pipeline entirely, the map remains intact and looks good except for the large z-drift and of course typical odometry drift in XY directions.

Here is our config:

setting:
name: "test_pin"
output_root: "./experiments"
deskew: True
process:
max_range_m: 120.0 # maximum distance filter for each frame
min_range_m: 5.0
min_z_m: -10.0
max_z_m: 10.0
decoder:
mlp_hidden_dim: 128
sampler:
surface_sample_range_m: 0.25
neuralpoints:
voxel_size_m: 0.4
search_alpha: 0.7 # increase when you want to be more robust to agressive motions
continual:
batch_size_new_sample: 1000
pool_capacity: 1e7
pool_filter_freq: 10
tracker:
source_vox_down_m: 0.6
iter_n: 50
valid_nn_k: 5

pgo:
map_context: True
context_cosdist: 0.3
pgo_freq: 30.0
min_loop_travel_ratio: 4.0

optimizer: # mapper
batch_size: 10000
adaptive_iters: True
eval:
wandb_vis_on: False # log to wandb or not

Faulty Loop Closure Image:

Running PIN_SLAM without support for loop closures:

The above image shows a roughly anticipated SLAM trajectory (of course, there is slight odometry drift, but this is just used to visualize what happens without faulty loop closure). As can be seen, there are between 2 and 4 candidates for loop closure here.. But when these loop closures are encountered when min_loop_travel_ratio is small, we get false global map updates.. To remove loop closure entirely, we set this min_loop_travel_ratio to a very high value.

Image showing z-drift/warping

Note that in this image the bottom yellow line lies within the XY-plane of the map frame. Do you think that this is caused by poor initial alignment? Maybe IMU preintegration would help with this? On that note are there any plans to include IMU/GNSS in the future to help with cases such as this?

Thank you so much for taking the time to read and help with this. Please let me know if you would like to access my dataset to better understand our issues.