Guidance on Combining Wheel and RGB-D Odometry in RTAB-Map (ROS2 Humble)

[CGV_Kwak]

I am a beginner in this field and currently developing an indoor autonomous navigation robot using RTAB-Map.
When we run our execution script, the odometry (odom) values are published in an unstable manner.

We are considering two approaches to improve this:

Method1. RGB-D Odom only

Method2. RTAB-Map RGB-D Odom

Method3. Using RGB-D odometry as the default and switching to wheel odometry when a loss occurs

Given the script we currently use (shared below), how should we modify it to achieve this behavior?
Also, could you kindly review our script to see if there are any parts that need to be revised or improved?

For context, we are using a Realsense D455 camera, an Omorobot R1V2, Nav2 platform, and ROS2 Humble on Ubuntu 22.04.

Thank you very much for your kind support and guidance.


run_map.sh

run_local_test.sh

[matlabbe]

Is your wheel odometry relatively good? You may consider skipping visual odometry and just feed your wheel odometry to rtabmap node (set "visual_odometry:=false" when launching from rtabmap.launch.py). You may then compare with "Turtlebot3 Nav2 and RGB-D SLAM" demo.

Otherwise, you may consider adding wheel odometry TF as guess transform for visual odometry. It can be done by setting odom_guess_frame_id argument of rtabmap.launch.py. Set also vo_frame_id to a different name than odom, like "vo". The TF tree will then look like map->vo->odom->base_link. To automatically reset visual odometry based on latest wheel odometry, you could then add `--Odom/ResetCountdown 10` to odom_args argument. Note that when odometry is lost (unless parameter publish_null_when_lost is false), it will publish NULL odometry topic. The TF vo -> odom will still be published with latest visual odometry correction when vo is lost.

cheers,
Mathieu