ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

rtabmap TF tree issue with navigation stack

asked 2020-12-03 13:41:11 -0600

apawlica gravatar image

updated 2020-12-08 14:41:14 -0600


I am using a Clearpath Husky robot platform along with an Ouster OS1-16 LiDAR, along with rtabmap and the navigation stack for mapping and navigation. I have been successful in mapping with the OS1, and the navigation stack for the Husky works well without a map. However, when I run both the mapping and navigation, there isn't a typical transform tree set up between the lidar and base (i.e. map > odom > base_link > os1_sensor). Instead, the odom frame has two child frames: base_link and os1_sensor_stabilized. Because of this, the Husky platform is not correctly oriented on the map (which is aligned with the OS1 sensor). I have tried starting a static tf publisher node to publish a transform between the base_link frame and the os1_sensor_stabilized, which results in the the other LIDAR frames not having a transform to the odom frame. It is not clear to me how to set up the transforms in the configuration that I want, with everything leading back to base_link. I think the issue might be a result of rtabmap using the OS1 IMU for odometry, and the Husky also having its own odometry, but I am not sure.

I cannot upload images (per karma requirement), but I will try to provide any additional information for troubleshooting; I am just not sure where to begin. I am using the husky_navigation package ( and rtabmap ( on ROS Melodic on Ubuntu 18.04. Please let me know if there is any additional information I can provide.

I am running melodic on Ubuntu 18.04.

Update 12/08/20: I was able to disable the transform from os1_sensor_stabilized to the odom frame by modifying the launch parameters in the launch file below. My static transform publisher was then able to publish a transform from base_link to the sensor frame without issue. However, the child frames of the sensor frame os1_sensor_stabilized are not able to have a TF to the odom frame (as required for rtabmap). From inspection of the TF tree (linked just below), I notice that this is because the transforms being published for the child frames are running on a different time than the rest of the transforms, so there isn't a current transform to use. How can I go about tracking down why these transforms are running on a different time?

updated TF tree

Requested info (12/04/20):

rtabmap test_ouster.launch file:


Hand-held 3D lidar mapping example using only a Ouster OS-1 (no camera).
Prerequisities: rtabmap should be built with libpointmatcher
 $ roslaunch rtabmap_ros test_ouster.launch os1_hostname:=os1-XXXXXXXXXXXX.local os1_udp_dest:=192.168.1.XXX
 $ rosrun rviz rviz -f map
 $ Show TF and /rtabmap/cloud_map topics
ISSUE: You may have to reset odometry after receiving the first cloud if the map looks tilted. The problem seems 
       coming from the first cloud sent by os1_cloud_node, which may be poorly synchronized with IMU data.

<!-- Required: -->
<arg name ...
edit retag flag offensive close merge delete



it would help if you posted ros-blessed's ascii rendering of the TF tree here (which includes publisher names), both when things are working (without rtabmap) and when not. Also, if you could post the launch files you are using that would help, too.

chfritz gravatar image chfritz  ( 2020-12-03 21:47:52 -0600 )edit

Hi chfritz, I've added some of the info you requested, unfortunately ros-blessed messed up something with my workspace build, so I can't run rtabmap to show the TF tree until I work out the issue. I'll comment again when I have all the info posted.

apawlica gravatar image apawlica  ( 2020-12-04 13:04:58 -0600 )edit

that's odd. ros-blessed usually installs in a system wide folder that has nothing to do with your workspace. If you installed it locally by accident (not using sudo and -g) then you can just delete the node_modules folder in the directory where you installed it.

chfritz gravatar image chfritz  ( 2020-12-04 15:44:44 -0600 )edit

I installed with sudo and -g, not sure where it went wrong but I keep a backup drive images so I just restored to before I installed it. I've added links to the TF trees at the bottom of my post.

apawlica gravatar image apawlica  ( 2020-12-04 16:18:09 -0600 )edit

I've updated my post above, I was able to work out part of the issue thanks to help from a friend, but there is still some timing issue with some of the transforms that is causing problems (described in the edit to my post). Do you have any tips or ideas for tracking down the source of the problem?

apawlica gravatar image apawlica  ( 2020-12-08 14:43:04 -0600 )edit

Did you finally made this work? I have the same concept to face with rtabmap /melodic/ouster lidar os1-32 and a jackal from clearpath. If you can post the final modifications you made on os_sensor to sync the clocks with robot's PC and the success launch for navigation it would be really helpfull.

antonis_kara gravatar image antonis_kara  ( 2022-06-23 10:04:44 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-12-08 16:25:27 -0600

apawlica gravatar image

After some more digging I found the Ouster LIDAR has a few different timestamp modes, and it was running in the mode using the internal clock source, leading to the time discrepancy. By configuring the sensor to run off a PTP master and setting up the master on the host machine, the timestamp should be synchronized. This is described in the answers to a similar question:

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2020-12-03 13:41:11 -0600

Seen: 363 times

Last updated: Dec 08 '20