The lidar point cloud of NAV2 shifted significantly after being stationary for 5 minutes.

[miku54]

Bug report

After using cartographer to build the map normally, run NAV2 bringup_launch and wait for 5 minutes. The single-line lidar point cloud obviously does not match the map. What may be the reason for this?

• Operating System:
  Ubuntu22.04
• ROS2 Version:
  Humble

Steps to reproduce issue

ros2 launch cartographer_ros cartographer.launch.py
ros2 launch my sensors (include imu,odom and  single-line lidar)
ros2 launch nav2_bringup bringup_launch.py map:=my_map.yaml open_rviz:=true

Expected behavior

LiDAR point cloud will not shift when stationary

Actual behavior

Additional information

If more information is needed, I can add it right away. Please can you help me analyze the reason?

[SteveMacenski]

That has nothing to do with Nav2, that's cartographer or your state estimation system. Nav2 does not provide state estimation to be updating the map->odom or odom->base_link transforms when you're using SLAM. If the robot drifts, that's due to your localization or odometry systems (or both).

[miku54]

That has nothing to do with Nav2, that's cartographer or your state estimation system. Nav2 does not provide state estimation to be updating the map->odom or odom->base_link transforms when you're using SLAM. If the robot drifts, that's due to your localization or odometry systems (or both).

Sorry, I didn't describe it clearly. What I want to express is that I used the carto algorithm to build the map and then opened nav2. Carto was not used when starting nav2. The actual steps are:
#build the map
ros2 launch cartographer_ros cartographer.launch.py
ros2 run nav2_map_server map_saver_cli -f ~/map
#run nav2
ros2 launch my sensors (include imu,odom and single-line lidar)
ros2 launch nav2_bringup bringup_launch.py map:=my_map.yaml open_rviz:=true

[SteveMacenski]

I think I understand - but see my comment above. Cartographer / your odometry is what would update TF, not Nav2. Both of those are outside of this project 😄

I'm guessing your odometry has some significant drift (using lidar odometry or a crappy IMU?)

[miku54]

I think I understand - but see my comment above. Cartographer / your odometry is what would update TF, not Nav2. Both of those are outside of this project 😄

I'm guessing your odometry has some significant drift (using lidar odometry or a crappy IMU?)

In fact, I did not run nav2_bringup and Cartographer at the same time. When running nav2, the Cartographer node has been shut down by me. When NAV2 is working, the odom->base_link conversion is provided by ekf_filter_node. Maybe my imu has some drift, should I doubt the configuration parameter of robot_localization?

[SteveMacenski]

Your issue is with your state estimation system, whether map->odom or odom->base_link. The odometry is what I'd look into first, but yes you should analyze that. AMCL doesn't update when not in motion so its not that. Its either Cartographer, your odometry, or other map->odom providers.

To check which, you can view in rviz in the odom and map frames (or watch the frames in another frame to see what's moving) to see what the drift is respect to. That should tell you pretty clearly if its map->odom or odom->base_link to then investigate further :-)

I hope that helps!