Open joanvallve opened 2 months ago
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
Yes, it is in SLAM with a simulated turtlebot4 initialized with yaw=0.0, not autogenerated or loaded.
Please provide something reproducible
Sorry, do you mean a video or instructions to reproduce the error?
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
Is it enough if I record a rosbag or do you want to simulate?
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
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.
Required Info:
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.