Ouster Time Handling for tf and sensor msgs about ouster-ros

[Samahu]

Hi @tahir1069

You are absolutely right. It is something that was overlooked and none has thought of it to cause issue.

The TF time should follow the same clock that the IMU and Lidar are using. I don't think we had the chance to address this issue. But we have recently added a new timestamp_mode TIME_FROM_ROS_TIME that when enabled the ouster_ros driver will use the host ROS time to timestamp the generated imu and lidar messages. This way the TF, IMU and PointCloud will be of the same time reference and should solve the issue.

You can found details about the new timestamp mode in the PRs: ouster-lidar/ouster_example#420 and ouster-lidar/ouster_example#421.

Nonetheless, I still think that using ros time for the TF in other timestamp modes will still pose a problem when the sensor and host system is not properly configured to run in sync using the PTP protocol.

For that I will keep the issue open and try to fully resolve it in a future update.

[csvicbot-7]

Hi @Samahu
I have the same problem, I am using OS0-64-U and Rtabmap package (used for SLAM). Actually, in normal conditions the ouster node and Rtabmap node running without problem.

But, I have problems when I try to do a test:

1. Ouster node and Rtabmap is running
2. I disconnect Lidar sensor
3. Ouster node and Rtabmap node continue running without data
4. After 2 minutes I connect Lidar sensor

The nodes reprocess Lidar data but I have the following error:

[ WARN] [1668158414.957718441]: odometry: Could not get transform from base_link to os_sensor (stamp=1668158375.848681) after 0.500000 seconds ("wait_for_transform_duration"=0.500000)! Error="Lookup would require extrapolation 38.615832763s into the past. Requested time 1668158375.848681211 but the earliest data is at time 1668158414.464514017, when looking up transform from frame [os_sensor] to frame [base_link]. canTransform returned after 0.504406 timeout was 0.5."

The point cloud is like it:

I am using the new release ouster-lidar/ouster_example#420 and ouster-lidar/ouster_example#421. I use TIME_FROM_ROS_TIME as timestamp_mode.

[ INFO] [1668158321.969738893]: Loading nodelet /os_cloud_node/os_node of type nodelets_os/OusterSensor to manager os_nodelet_mgr with the following remappings:
[ INFO] [1668158322.006487928]: TIME_FROM_ROS_TIME timestamp mode specified. IMU and pointcloud messages will use ros time
[ INFO] [1668158322.006545446]: Will send UDP data to 192.168.xx.xx
[ WARN] [1668158322.092406129]: Sensor 192.168.xx.xx configured successfully
[ INFO] [1668158322.098314955]: Starting sensor 192.168.xx.xx initialization...
[ INFO] [1668158322.979628391]: Loading nodelet /os_cloud_node/os_cloud_node of type nodelets_os/OusterCloud to manager os_nodelet_mgr with the following remappings:
[ INFO] [1668158322.981583135]: /os_cloud_node/os_cloud_node/imu_packets -> /os_node/imu_packets
[ INFO] [1668158322.981868913]: /os_cloud_node/os_cloud_node/lidar_packets -> /os_node/lidar_packets
[ INFO] [1668158322.981979271]: /os_cloud_node/os_cloud_node/os_config -> /os_node/os_config

If I use TIME_FROM_ROS_TIME the TF time should follow the same clock that IMU and Lidar are using right?
Do you think it is necessary to set the synchronization protocol to PTP although using TIME_FROM_ROS_TIME?

Thank you in advance for your help.

[Samahu]

So the TF messages are _ CURRENTLY _ not affected by the clock. They are currently published by a static broadcaster since they don't change values over time. I do have a ticket to support updating the timestamp per selected clock but I wasn't very sure on the exact use case that needs. I think your question does highlight the underlying issue and we will have this fixed ASAP. I will update you on the fix so stay tuned.

I probably already answer you second question, currently the implementation uses a static broadcaster to published TF messages. So it does not make a difference _ CURRENTLY _ which clock do you select. But generally speaking if you don't have PTP properly configured on your system you are better off using TIME_FROM_ROS_TIME timestamp option.

[Samahu]

@tahir1069 @VictorJCS the reported issue has been resolved with PR #26 (merged)