Stacking map and not detection of horizontal translation

[Alphastrick]

I try to use slamming for a robot, but moving it will create some strange results.

Moving the robot vertically works fine, as lone as the robot does not move more than 5 meters at once. The transformation will be published correctly. However moving it in horizontal direction the slamming will not match the input pointclouds.

Also if the map is visualized, the map looks like all inputs are stacked.

To to resolve this, so that the scanmatcher will publish the correct transformation in horizontal direction and should the map look like this?

[shineyruan]

I got the same problem. Really looking forward to a solution.

[rsasaki0109]

Can you please provide rosbag the problem occurs?

[shineyruan]

Can you please provide rosbag the problem occurs?

Please take a look at this bag file: https://drive.google.com/drive/folders/1YhOkbZCRT3qyiIVc96_xJ-PSmSiQFvDr

[rsasaki0109]

@shineyruan

The first image shows a map made pcd by "ros2 service call /map_save std_srvs/Empty" and displayed by cloudcompare. The second image is the rviz screen. It seems that rviz is displaying something wrong. I had no problem with ros2 foxy, but I confirmed this problem with ros2 galactic. I'll try to find the cause.

Since it is a small environment, the following parameters would be better.

scan_matcher:
  ros__parameters:
    global_frame_id: "map"
    robot_frame_id: "base_link"
    registration_method: "NDT"
    ndt_resolution: 1.0
    ndt_num_threads: 4
    gicp_corr_dist_threshold: 5.0
    trans_for_mapupdate: 1.5
    vg_size_for_input: 0.5
    vg_size_for_map: 0.05
    use_min_max_filter: true
    scan_min_range: 1.0
    scan_max_range: 200.0
    scan_period: 0.2
    map_publish_period: 15.0
    num_targeted_cloud: 20
    set_initial_pose: true
    initial_pose_x: 0.0
    initial_pose_y: 0.0
    initial_pose_z: 0.0
    initial_pose_qx: 0.0
    initial_pose_qy: 0.0
    initial_pose_qz: 0.0
    initial_pose_qw: 1.0
    use_imu: false
    use_odom: true
    debug_flag: false

[Alphastrick]

@rsasaki0109

Can you confirm that it is only some visualization bug? Unfortunately, I can not provide a bag file with my specific use case.

[rsasaki0109]

@Alphastrick If the yellow path (/path ) in rviz looks OK, then it is a visualization problem. Can you confirm what the trajectory of /path is in rviz?

[rsasaki0109]

Also, the ndt parameters need to be changed, such as whether the measurement environment is indoors or outdoors, and the slam may be failing due to improper parameters. The parameters in the sample(https://github.com/rsasaki0109/lidarslam_ros2/tree/foxy/lidarslam/param) are for outdoor use. If you are indoors, you may want to try the parameters listed above. https://github.com/rsasaki0109/lidarslam_ros2/issues/32#issuecomment-1057932902

[rsasaki0109]

I will close this issue at once. Please contact me if you have any further problems.