Open Jenanaputra opened 7 months ago
You may debug if topics are correctly published with ros2 topic hz
. For example, I think /rtabmap/rgbd_image
may not be published because depthai doesn't publish rgb and depth topics with exactly the same stamp. You have to use approx_rgbd_sync:=true
.
Make sure the camera topics are actually published and that you publish /odom
at a similar rate (or faster) than /rtabmap/rgbd_image
.
@matlabbe thanks for your reply, I will try this out
@matlabbe , I tried to use approx_rgbd_sync:=true ros2 launch rtabmap_launch rtabmap.launch.py visual_odometry:=false frame_id:=base_footprint subscribe_scan:=false approx_sync:=true approx_rgbd_sync:=true odom_topic:=/odom args:="-d --RGBD/NeighborLinkRefining true --Reg/Strategy 1 --Reg/Force3DoF true --Grid/RangeMin 0.2" use_sim_time:=true rgbd_sync:=true rgb_topic:=/camera/image_raw depth_topic:=/camera/depth/image_raw camera_info_topic:=/camera/camera_info qos:=2
but i got the same issue. I also noticed there is warning coming out on my terminal [rgbd_sync-1] [WARN] [1709716048.898040509] [rtabmap.rgbd_sync]: The time difference between rgb and depth frames is high (diff=0.100908s, rgb=1709716048.695479s, depth=1709716048.594570s). You may want to set approx_sync_max_interval lower than 0.01s to reject spurious bad synchronizations or use approx_sync=false if streams have all the exact same timestamp
Actually I publish the depth and rgb with the same time stamp. Do you have any thought about this ?
If depth and rgb topics have same stamp, set approx_rgbd_sync:=false
. Keep approx_sync:=true
to sync /odom
with the image topic.
Are you launching rtabmap on same computer than the camera? the 100 ms time difference is quite high, it should be at most 15 ms for images published at 30 Hz.
@matlabbe still got the same issue. I even made sure the rgb data and the depth image data are published with the same time stamp by creating the new code to make sure it.
Regarding to the time difference , I launch the rtabmap in my computer, and accessed the oakd camera wireless (I dont know this can be tha cause of high time difference).
Do you have any another suggestion to try ? Is it possible because of the size of the image quite high ?
@matlabbe is that possible that the issue is caused because I only use odom data, camera info data, rgb camera data, depth camera data and imu data as the input for the rtabmap package ?
If you are subscribing on image topics on WIFI, check if your bandwidth is limited (that could explain large sync delay, as some images may not be received). I would also suggest to subscribe to compressed topics instead of the raw images with compressed:=true
if you use rtabmap.launch.py
.
For bandwidth issues, you can use ros2 topic hz
on the topics from the remote computer and compare with actual frame rate if you do it on the camera's computer.
@matlabbe could you tell me the command line to launch the rtabmap package with compressed image data ? I have no idea about that.
ros2 launch rtabmap_launch rtabmap.launch.py compressed:=true ...
By default for RGB/stereo images, compressed
suffix is used, for depth image, it is compressedDepth
. You can change which image_transport
plugin you want to use with rgb_image_transport
and depth_image_transport
arguments respectively.
Hi Guys ....
I am using ROS2 Humble. I am trying to get the 3d map using rtabmap package that is provided in ros2, but without using scan data , and statically set the odom to 0,0,0 as the program runs. The scenarios of my testing are :
ros2 launch rtabmap_launch rtabmap.launch.py visual_odometry:=false frame_id:=base_footprint subscribe_scan:=false approx_sync:=true approx_rgbd_sync:=false odom_topic:=/odom args:="-d --RGBD/NeighborLinkRefining true --Reg/Strategy 1 --Reg/Force3DoF true --Grid/RangeMin 0.2" use_sim_time:=true rgbd_sync:=true rgb_topic:=/camera/image_raw depth_topic:=/camera/depth/image_raw camera_info_topic:=/camera/camera_info qos:=2
After I run those steps above, nothing came up but I got the logging on my terminal :
I also attached you the screenshot of my rqt_graph, therefore you can help me analyze what wrong with my testing.
I got stuck with this problem, Anyone maybe has their thought about this problem ?