Map drifting after moving robot in gazebo ignition with slam_toolbox and rtabmap_ros

[Marcelomm103]

• Operating System: Ubuntu 20.04

• Installation type: Binaries

• ROS Version ROS2 Foxy

• Laser unit: GPU 3D Laser from ignition gazebo plugin

Steps to reproduce issue

I'm trying to do SLAM with an ackermann prius model in ignition gazebo. I'm bridging all the topics required to ros 2 with ros_ign_bridge, like clock, pointcloud, odometry, imu, etc... I'm using robot_localization to generate the odom -> base_link transform, and following this tutorial to do the slam: (https://navigation.ros.org/tutorials/docs/navigation2_with_slam.html). I'm pretty sure i have all params yaml configured right because if i try with a diff drive robot and 2D laser i can do the slam. Does anyone know or have an idea why this drift as shown in images below is happening?? I thought it was a problem of using pointcloud to laserscan conversion but the same happens with rtabmap which is a 3D slam.

I can send echos of topics, log files and config files if anyone care to help. I'll appreciate all contributions. Thank you.

[SteveMacenski]

Probably because your map is super unrealistic / sparse, there's not enough features to match against. But also could be issues with your odometry / state estimates. You should make a real world you really want to localize within

[Marcelomm103]

Thanks for the reply. I think it may be something with the odometry, but it's self generated by ackermann plugin in gazebo ignition. I thought it was something with the robot localization and went to program a odom -> base_link tf myself but it wasn't. I'm using sonoma map from open robotics and it still drifting so i may not be lack of features as seen from the img:

The strange thing is if i use a diff drive robot i can map perfectly, even using pointcloud_to_laserscan package to simulate 2D laser from 3D lidar.

[SteveMacenski]

I think then this is a ticket to file with the ackermann drive plugin?

[Marcelomm103]

I noticed something, the map to odom shouldn't be in the same coordinates? because mine map tf is driving away from odom tf as the robot goes.

[SteveMacenski]

It should drift over time, though it shouldn't be something you can watch and see it actively moving from frame to frame as you move. Its more about accounting for error (unless you don't have a global localizer set up)

[Marcelomm103]

Thank you for your fast replies, no i dont have any gnss in my model. So the problem may be the odometry generated by the ackermann plugin ? Because i looked in to it with echo and it seems pretty good by the way the robot moves, if it moves in one ax or circles it account for it nicely. Could be something with the nav2 bringup ? I can use it well with diff drive robots

[Marcelomm103]

If i use rtabmap for mapping it shows me the direction of the robot, and it's moving 90 degrees displaced. Do you know how i can change the direction of the mapping? or it should be in the odom frame? I dont know where i should be making changes.

[SteveMacenski]

Unfortunately I don't have extra cycles to be able to dig into your system for you :/ If you don't have anything updating the map - odom transform for global localization, that should be staying static and you should only be seeing base link move. I can't tell you what's wrong specifically with your system, but I suspect something is not set up correctly

[Marcelomm103]

No worries. I don't have anything updating map-odom besides the slam node. I will dig in trying to see if my model is somehow rotated 90 degrees. Thank you for all your help.

[Marcelomm103]

Actually i managed to get it right now with a rotated lidar, the slam toolbox works fine now. Thank you for your insights.