(ref Nav2:#3230) Tb3 is out of bounds of the costmap when navigating and mapping

[lmendyk]

I have been requested to open the ticket in SLAM repo for the ticket: https://github.com/ros-planning/navigation2/issues/3230 (see the description of the issue from a user perspective) as it was diagnosed to be related more to SLAM than Navigation2.

And add details on the installation. It is the installation based on the binaries for galactic release:

Package: ros-galactic-slam-toolbox Version: 2.5.1-1focal.20220730.075909

Package: ros-galactic-navigation2 Version: 1.0.12-1focal.20220730.081413

[SteveMacenski]

What launch file, what configuration, etc? Your ticket also says a "new" lidar, does that mean this works fine with other lidars?

If you can provide a bag file of this situation that would be helpful too to reproduce.

[lmendyk]

The launch files are as defined in the tutorial https://navigation.ros.org/tutorials/docs/navigation2_with_slam.html. This means:

• ros2 launch turtlebot3_bringup robot.launch.py (at Turtlebot3 Raspberry Pi 4 with LDS-2 - this is a new model lidar - it is my first experience no previous version)

• ros2 launch nav2_bringup navigation_launch.py use_sim_time:=false ( this “use_sim_time:=false” is my only modification toward the tutorial description)

• ros2 launch slam_toolbox online_async_launch.py use_sim_time:=false ( this “use_sim_time:=false” is my only modification toward the tutorial description)

• ros2 run rviz2 rviz2 -d $(ros2 pkg prefix nav2_bringup)/share/nav2_bringup/rviz/nav2_default_view.rviz

The configuration is a default one which means: /opt/ros/galactic/share/slam_toolbox/config/mapper_params_online_async.yaml

mapper_params_online_async.yaml.txt

/opt/ros/galactic/share/nav2_bringup/params/nav2_params.yaml nav2_params.yaml.txt

As to a bag file I will try to prepare (when I learn how to do it)

[SteveMacenski]

Does this happen in simulation?

Edit; After rewatching your video, that seems to happen RIGHT when you sent it a new navigation command, is that always the case? Also, I noticed that your navigation request was not valid (e.g. in collision). What errors are on the screen? Does this happen if you just teleop the robot without Nav2?

[lmendyk]

Only recently it came to me to try with no nav2 but with teleop, the first test seemed to do the proper mapping but haven't yet finalized the test as my battery went down, so I will need to do further tests.

As to the simulation, so far I used simulation ether with no SLAM (using the world_map), or the kinetic version with and did not noticed such behavior.

I will do more test tomorrow as it's getting late to me. If you can suggest more tests variants I will try to do them my tomorrow morning will provide the results for your daytime.

[lmendyk]

I have done the test with no nav2 (just slam toobox and rviz, the commands to robot sent by a remote controller).

The result is better (the rooms has been mapped)

but finally the problem has happened

in the slam console there were such info: [async_slam_toolbox_node-1] LaserRangeScan contains 268 range readings, expected 274 [async_slam_toolbox_node-1] LaserRangeScan contains 271 range readings, expected 274 [async_slam_toolbox_node-1] LaserRangeScan contains 271 range readings, expected 274 [async_slam_toolbox_node-1] LaserRangeScan contains 271 range readings, expected 274 etc.

rviz console: [INFO] [1665132304.471581844] [rviz2]: Stereo is NOT SUPPORTED [INFO] [1665132304.471721353] [rviz2]: OpenGl version: 4.6 (GLSL 4.6) [INFO] [1665132304.553818910] [rviz2]: Stereo is NOT SUPPORTED [INFO] [1665132306.271604512] [rviz2]: Trying to create a map of size 242 x 92 using 1 swatches [ERROR] [1665132306.398779985] [rviz2]: Vertex Program:rviz/glsl120/indexed_8bit_image.vert Fragment Program:rviz/glsl120/indexed_8bit_image.frag GLSL link result : active samplers with a different type refer to the same texture image unit [INFO] [1665132327.610919498] [rviz2]: Trying to create a map of size 245 x 92 using 1 swatches [INFO] [1665132332.635917016] [rviz2]: Trying to create a map of size 252 x 92 using 1 swatches [INFO] [1665132337.628740783] [rviz2]: Trying to create a map of size 257 x 105 using 1 swatches [INFO] [1665132352.634987429] [rviz2]: Trying to create a map of size 257 x 215 using 1 swatches [INFO] [1665132357.628360614] [rviz2]: Trying to create a map of size 257 x 217 using 1 swatches [INFO] [1665132392.709708496] [rviz2]: Trying to create a map of size 3221 x 1633 using 1 swatches [INFO] [1665132412.673593356] [rviz2]: Trying to create a map of size 3237 x 1713 using 1 swatches [INFO] [1665132447.681733874] [rviz2]: Trying to create a map of size 3242 x 1713 using 1 swatches

[lmendyk]

I have manged to reproduced the problem while recording the bag: tb3_Slam_problem.tar.gz

The commands which worked for reproducing: ros2 bag play tb3_3 --clock

ros2 launch slam_toolbox online_async_launch.py use_sim_time:=True

ros2 run rviz2 rviz2 -d $(ros2 pkg prefix nav2_bringup)/share/nav2_bringup/rviz/nav2_default_view.rviz --ros-args --param use_sim_time:=True

(BTW it took me a while that instead of trying to use --qos-profile-overrides-path , it was the best to first wait for turtebot3 startup and assuring that all topics are visible on the machine where it was recorded)

[SteveMacenski]

[async_slam_toolbox_node-1] LaserRangeScan contains 268 range readings, expected 274
[async_slam_toolbox_node-1] LaserRangeScan contains 271 range readings, expected 274
[async_slam_toolbox_node-1] LaserRangeScan contains 271 range readings, expected 274
[async_slam_toolbox_node-1] LaserRangeScan contains 271 range readings, expected 274

That's problematic if your lidar sensor isn't producing the correct number of points in a scan, its critical that these are consistent for scan matching and additions to the map. It could be that is causing it, though I'm not confident about that.

Can you replicate this in simulation or with another lidar sensor? I'm trying to isolate this particular sensor / driver to see if this is an issue with the data coming into the system or the system itself. Seems almost like the scan got flipped or something around the odometric frame. Is something going on with your odom frame?

Actually, from the video, I can't tell. What frame is actually "jumping"?

[lmendyk]

IN fact it is my first adventure with the real robot - so I don't have access to other robot or other lidar :( .

I don't quite know how to verify if sth is wrong with the odom frame. Do you mean looking into the bag I recorded and have some algorithm to verify if odom frame does not behave some sudden radical change of values?

Today it took me longer to have this map problem, I even thought that I can't replicate the situation and only after moving into the third room it happened. So to me it looks to me as if some numbers has exceeded the maximum value :)

I'm not quite sure if I understand the question "What frame is actually "jumping". the "map" displayed jumps, the robot frames displayed on top of the map also, but I understood it that it is because map->odom->base link so my undestanding is that it is due to wrong map->odom done by SLAM. Do you suggest that this may be a problem of odom->base link?

[SteveMacenski]

Do you suggest that this may be a problem of odom->base link?

Yes, I am wondering about that. In rviz, you should be able to see frames (and you can add labels to them in the side panel) and when the jump happens, what transform is jumping?

[lmendyk]

OK, more experiments I will be able to do my daylight time.

Could you enlighten me:. I can observe that the initial position of the robot stays constant, so more the robot moves the odom->base link transformation is going to have an error accumulated. I thought that SLAM (it's localization role) is to reset at same points the initial position of the robot from which the odom should start calculating the position. Or am I mixing something here?

[lmendyk]

I have found the issue which looks being the case here: https://github.com/ROBOTIS-GIT/turtlebot3/issues/901

[SteveMacenski]

OK. I'd follow up there then! Glad we found the root cause!

[lmendyk]

Thanks for help and ... patience