Open hiroshi-automind opened 2 weeks ago
Make sure TF for wheel odometry and visual odometry are not published, robot_localization will publish it. For VO, add publish_tf_odom:=false
to rtabmap.launch.py
command to disable it. For wheel odometry, this is specific to your robot to how to disable it.
odom_guess_frame_id
could be the TF of robot_localization, or not set if you want to disjoint wheel odometry from visual odometry. Setting odom_guess_frame_id
makes vo publishing the TF correction (vo frame to wheel frame), but the published topic is still vo->base_link (like wheel odometry topic). But if publish_tf_odom:=false
, then only the topic is published.
If you set odom_topic
, by default vo_frame_id
will be set to same value. Explicitly set vo_frame_id
if you don't want the same value in odom_topic
and vo_frame_id
.
odom_frame_id
should be set to TF frame of robot_localization. rtabmap won't subscribe to odom topic published by vo but use TF odom from robot_localization.
Hi matlabbe,
Thank you very much for the response! It seems like I need to take more care in what messages to pass through TFs. I might not be able to disable the robot from publishing wheel odometry (I'm using turtlebot 4). In that case, is it possible to completely disable the usage of TF in rtabmap? If not then I'll need to find a workaround.
Hi, sorry for the onslaught of questions. Is rtabmap-ros different from rtabmap standalone? The standalone version seems to only rely on the input from a rgbd/stereo camera, but the ros version seems to depend more on wheel odometry.
We rely on TF to get more accurate odometry corresponding on input data stamps (image or lidar). If the odometry topic is linked to rtabmap node, then just the covariance is actually used from that topic. There is a way to ignore using TF if it doesn't exist, set wait_for_transform
to 0 to avoid rtabmap waiting for that TF. It will then use the stamp from odometry topic instead of the data as reference.
To avoid publishing any TF, set publish_tf
to false for rtabmap's odometry nodes and rtabmap node. To do this, you may not be able to use rtabmap.launch.py
, but would have to use the nodes directly (here are some examples using the nodes directly in a custom launch file).
For turtlebot4, I am currently working on an example with nav2 (replacing slam_toolbox), though I have still some issues I don't understand with the simulator before I officially release the example. You may try this:
ros2 launch rtabmap_launch rtabmap.launch.py \
rtabmap_viz:=true \
subscribe_scan:=true \
rgbd_sync:=true \
depth_topic:=/oak/stereo/image_raw \
camera_info_topic:=/oak/rgb/camera_info \
rgb_topic:=/oak/rgb/image_raw \
visual_odometry:=false \
approx_sync:=true \
approx_rgbd_sync:=false \
guess_odom_frame_id:=odom \
icp_odometry:=true \
odom_topic:="icp_odom" \
namespace:="/" \
qos:=2 \
odom_log_level:=warn \
rtabmap_args:="--delete_db_on_start --Reg/Strategy 1 --Reg/Force3DoF true"
If you don't have the lidar, you may do this instead:
ros2 launch rtabmap_launch rtabmap.launch.py \
rtabmap_viz:=true \
rgbd_sync:=true \
depth_topic:=/oak/stereo/image_raw \
camera_info_topic:=/oak/rgb/camera_info \
rgb_topic:=/oak/rgb/image_raw \
visual_odometry:=true \
approx_sync:=false \
approx_rgbd_sync:=false \
guess_odom_frame_id:=odom \
odom_topic:="vo" \
namespace:="/" \
qos:=2 \
odom_log_level:=warn \
rtabmap_args:="--delete_db_on_start --Reg/Force3DoF true"
I am not sure about the qos
value for the real robot, you can remove it to use default.
You can use rtabmap without wheel odometry in ROS, though most robots have already wheel odometry or something equivalent that is useful to use. When we set guess_frame_id
for rtabmap's odometry nodes (from rtabmap.launch.py
, use guess_odom_frame_id
), if rtabmap's odometry gets lost, it will redirect wheel odometry output instead so that the robot has always valid odometry (though less accurate till rtabmap's odometry can work again). Using wheel odometry as guess frame is also used as prediction when doing feature matching or lidar registration. And I think the most useful part is that sometime robot's odometry cannot be easily disabled, so when using it as guess, rtabmap will publish its odom TF in a way that not breaks the TF tree. For example, after basic bringup the robot (without any mapping nodes), the TF tree would look like this:
odom -> base_link -> camera_link -> camera_optical_link...
Doing the second example above, the TF tree will look like this:
map -> vo -> odom -> base_link -> camera_link -> camera_optical_link...
where vo->odom is the visual odometry correction of the wheel odometry.
Rtabmap standalone doesn't have odometry input because it is mostly used as handled scanning and not on a robot.
Hello!
I'm trying to do something like #398 where I want to fuse wheel odometry and rgbd odometry to get a more accurate odometry before feeding it to rtabmap.
However I can't seem to get these nodes to communicate with each other properly. Currently I am using this command to launch rtabmap (use_sim_time is true because I'm using ros2 bag playback on a separate development machine):
and the following for robot_localization (use_sim_time = True is injected into this launch script):
This is not currently working, and the mapping results are worse than if I only launched rtabmap without robot_localization. It seems like some transforms or topics are not properly configured, as
and
It seems like rtabmap is receiving something from robot_localization but not through the intended
rqt_graph
gives meros2 run tf2_tools view_frames
gives me/odometry/filered
topic.Given the above context, I had a few questions, and please feel free to just redirect me to another resource if it solves my problem and I just didn't find it earlier.
odom_topic
correct? What does this argument do?rgb_topic
,depth_topic
, etc all seems intuitive as those are just set to the topic name of where the data comes from. But forodom_topic
, it seems to affect the odom input topic, rgbd_odom output topic, and the frame_id of the output transform. Usingodom_topic:=/odom
messed up a lot of things whileodom_topic:=odom
seems fine. I don't quite understand how this argument works.odom->base_link
andvo->base_link
and separately publish odometry messages, and THEN we fuse them. However when I followed #398 it (as expected) just publishedvo->odom->base_link
, and I couldn't figure out how the odometry messages were being passed between the nodes.Thank you very much for your time!