Bad obstacle mapping in the map limits

[joanvallve]

Required Info:

• Operating System: Ubuntu 22.04
• Installation type: binaries
• ROS Version: Humble
• Version or commit hash: 2.6.8-1jammy.20240217.104951
• Laser unit: RPLIDAR A1M8 (turtlebot4 simulated)

Steps to reproduce issue

Launch turtlebot4 simulation in an environment with orthogonal walls starting with zero orientation.

Expected behavior

Map the walls on the map limits properly, like all the other walls.

Actual behavior

It seems that the walls close to the map limits are not properly mapped and often are mapped as free area.

Additional information

When simulating the robot starting with a different orientation, the walls are properly mapped. To me it seems like a problem of ray casting related with the lack of unknown cells behind. It would be easily fixed adding some extra rows and cols when resizing the map.

[SteveMacenski]

How is that map generated? The flat stop of the map really isn’t how lidar data works for the map to have an abrupt end like that. Is this in typical slam operation mode or are you localizing on something else? That map also looks really suspiciously perfect like it’s autogenerated and not from slam

[joanvallve]

Yes, it is in SLAM with a simulated turtlebot4 initialized with yaw=0.0, not autogenerated or loaded.

[SteveMacenski]

Please provide something reproducible

[joanvallve]

Sorry, do you mean a video or instructions to reproduce the error?

[SteveMacenski]

Instructions, maps, simulation files, etc so I can easily reproduce this myself to look into it. Probably a new github repo for it with instructions in the readme about how to launch and test so I can take a look

[joanvallve]

Is it enough if I record a rosbag or do you want to simulate?

[joanvallve]

Ok so I added a readme to the package I use for this simulation: upc_mrn

There you have the dependencies and an example of how to launch the simulation of the turtlebot4 with slam_toolbox. The pictures I uploaded were taken simulating with world small and with default starting pose or changing the initial orientation, respectively. Tell me if you have any problems with this and if you prefer a rosbag. Thanks

[SteveMacenski]

Does the robot localize well when in this situation (i.e. doesn't get lost)? What I expect is happening here is not a bug in the core SLAM / sensor matching but in the occupancy grid generation which happens periodically to serve to the user (which isn't used internally).

If the robot doesn't get delocalized or anything, then that is the most likely situation and that happens here: https://github.com/SteveMacenski/slam_toolbox/blob/ros2/lib/karto_sdk/include/karto_sdk/Karto.h#L5893 There's alot going on in that file, but from my glance, you shouldn't need to look at anything but that, Grid and perhaps the Math.h file for how certain validation checks are performed. You can safely not bother yourself with the rest which would be alot to take in. Those objects are pretty straight forward

Given what you see is on the right side of the map, that is at the width maximum value, so there may be an off by 1 error in some validation check if on the grid, we stop raycasting a little early, or round down some bounding box dimension one unit shy. Its hard for me to say which, but let me know if anything in that object or the Grid object sticks out to you.