Map broken when use ros2_control

[AnhHazz]

I'm following the demo with turtlebot3 model and my model. Both work fine when using libgazebo_ros_diff_drive.so

The rqt_graph show

But when i change to gazebo ros2_control plugin, it the map look really bad

The rqt_graph for this

I see that the only difference between those two plugins is the odom so maybe the problem is in there. But i haven't find out how to fix.
Edit: the hz of depth camera also decrease so much when running rtabmap, from 20hz to 5hz but this also happen with the demo
It also show warnings: [ WARN] (2024-11-23 23:06:05.325) Rtabmap.cpp:3036::process() Rejected loop closure 73 -> 102: Not enough inliers 14/20 (matches=24) between 73 and 102

Tks for reading and i hope you guys help me solve this problem

[matlabbe]

Which example are you using? The one with wheel odometry and RGB-D image requires relatively good odometry. If the new plugin gives very bad odometry, it won't work as expected. The rejected loop closure is because there is not enough visual features.

[AnhHazz]

Hi @matlabbe , i'm using turtlebot3_rgbd launch file which mean it's using differential_drive plugin. Everything in this example work perfectly with odometry and RGBD camera.

With the ros2_control plugin i use robot_localization to fusion plugin's odom and imu. It show in the under rqt_graph and the final odom looks quiet good. But the problem still the same

Should i change to another map with more feature? But in your example there still enough features to loop closure so i think it's not cause by map

[matlabbe]

Switching to a map with more visual features won't fix the odometry drifting issue. Note that odometry is looking fine with ros2_control, maybe I didn't see if there was a bad loop closure. Can you share the database with the wrong result? Maybe the covariance in the resulting odometry topic is too large.

[AnhHazz]

Switching to a map with more visual features won't fix the odometry drifting issue. Note that odometry is looking fine with ros2_control, maybe I didn't see if there was a bad loop closure. Can you share the database with the wrong result? Maybe the covariance in the resulting odometry topic is too large.

https://drive.google.com/file/d/12Rz1XZm0XG331Y1bCgEiyz2lvRp2JcPD/view?usp=drive_link
Here is the link to .db file. Is that the database you mentioned? If not please tell me what to do. I'm new to this

[matlabbe]

I think it looks normal. The odometry is slowly drifting, which is expected on any robots. There are no loop closures because the environment is mainly featureless. That kind of environment is however pretty good for lidar proximity detections. If you cannot use lidar, you may try with turtlebot3 "house" world.

[AnhHazz]

Thanks for your help. The turtlebot3_house world works as expected