Shift in map in mapping with online_async.launch.py

[KishanSawant]

Required Info:

• Operating System:
  • Ubuntu 22.04
• Installation type:
  • source
• ROS Version
  • ROS2, humble

Steps to reproduce issue

Every time the mapping is running, after certain time period this issue is observed

Expected behavior

Accurate mapping without shift in the map

Actual behavior

While mapping using online_async.launch.py, all parameters in the mapper_params_online_async.yaml is used as it is. After a while, the map shifts between two frames and this shift stays throughout as shown in the image below

[SteveMacenski]

What do you mean "shift"? That laser scan looks correctmy matched to the map to me.

[KishanSawant]

By "shift" I meant the slipping of the map frame and the jump of the map frame or the robot at an instance.

These are some of the examples:

1. Because of the constant slippage of the map, it incrementally starts to tilt

2. The robot or the map frame jumps to a new location at an instance and the map looks like this

These are the terminal outputs while running the above instance of mapping.

[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [async_slam_toolbox_node-1]: process started with pid [6935]
[async_slam_toolbox_node-1] [INFO] [1700556249.245396937] [slam_toolbox]: Node using stack size 40000000
[async_slam_toolbox_node-1] [INFO] [1700556251.729801378] [slam_toolbox]: Using solver plugin solver_plugins::CeresSolver
[async_slam_toolbox_node-1] [INFO] [1700556251.734085636] [slam_toolbox]: CeresSolver: Using SCHUR_JACOBI preconditioner.
[async_slam_toolbox_node-1] Info: clipped range threshold to be within minimum and maximum range!
[async_slam_toolbox_node-1] [WARN] [1700556252.147412210] [slam_toolbox]: maximum laser range setting (20.0 m) exceeds the capabilities of the used Lidar (5.6 m)
[async_slam_toolbox_node-1] Registering sensor: [Custom Described Lidar]
[async_slam_toolbox_node-1] WARNING: Logging before InitGoogleLogging() is written to STDERR
[async_slam_toolbox_node-1] W1121 09:48:32.690979  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:48:53.204859  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:48:54.654497  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:49:01.620555  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
l[async_slam_toolbox_node-1] W1121 09:49:34.521675  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:49:40.157598  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:49:58.218693  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:50:08.068611  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:50:23.620651  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:50:33.025841  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 09:51:44.953114  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] [INFO] [1700556727.868400574] [slam_toolbox]: Message Filter dropping message: frame 'base_laser_front_link' at time 367.904 for reason 'discarding message because the queue is full'
[async_slam_toolbox_node-1] W1121 09:52:16.187836  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:05:13.887697  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
l[async_slam_toolbox_node-1] W1121 10:06:18.323398  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:06:56.063140  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:07:11.447391  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:07:32.137095  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:08:48.601104  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:09:04.151890  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:09:19.122378  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:11:30.071465  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:11:48.033140  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.
[async_slam_toolbox_node-1] W1121 10:12:05.084300  6967 preprocessor.cc:62] Specified options.num_threads: 50 exceeds maximum available from the threading model Ceres was compiled with: 4.  Bounding to maximum number available.

The Message Filter dropping message: frame 'base_laser_front_link' at time 367.904 for reason 'discarding message because the queue is full' output was received when the map frame or the robot jumped for the first time (from the last image above).

From that point on, the map frame or robot will continue to shift or jump frequently.

[KishanSawant]

@sthoduka tested with the same bag file for mapping in ROS1 and ROS2. In the below image, the left one is by using GMapping in ROS1 and the right one is by using online_async.launch.py in ROS2

[SteveMacenski]

By "shift" I meant the slipping of the map frame and the jump of the map frame or the robot at an instance.

This is still very poorly defined. Do you mean your robot is getting delocalized? Your original image shows no signs of that.

Of course, you should tune SLAM Toolbox for your particular application. I provide pretty decent out of the box performance for professional grade lidars with relatively normal odometry (sub 3% drift).

[KishanSawant]

thank you for the feedback. After tuning the parameters based on the description in slam_karto documentation, the problem is resolved.

[SteveMacenski]

@KishanSawant for helping other people in the future, can you highlight what you changed?

[KishanSawant]

In simulation, since the odom data is almost accurate, setting the `use_scan_matching' parameter to false and using the default parameters from the slam_karto documentation gave good results. It seems like because of active scan matching the robot was getting delocalised when it encountered almost unseen regions of the environment. I still need to test it on the real robot. I will update here if further tuning is needed on the real robot.