't' (timestamp for point) field is all zero

[inwoong32]

Describe the bug
I am currently using the os2 128ch.
Before running the driver, perform the PTP operation and run the driver using driver.launch.py.

After that, I'm going to use the t-field to correct the distortion caused sensor movement during 1 scan.(I use lidar in High speed Autonomous driving)
But when I checked, all the values of the t-field are output as 0.0, so it's impossible to use.
header.stamp value of topic is valid as corrected by ptp, but t value is not valid, just zero value

Also, I also checked the os1-64ch, and the same problem occurred.
Even changing the time stamp mode does not solve the problem
(TIME_FROM_INTERNAL_OSC , TIME_FROM_ROS_TIME)

What kind of problem do you think it is?
I'll let you know if need more information.

Screenshots

• topic : pointcloud msg header.stamp

• first_point : The first(first point) t-field value when using sensor_msgs::PointCloud2ConstIterator (time_stamp_field)time_stamp_field_name_

• point : Next point t-field value

Platform (please complete the following information):

• Model : OS2-128ch / OS1-64ch
• Ouster Firmware Version : ousteros-image-prod-aries-v2.5.2+20230714195410
• ROS version : humble
• Operating System : Linux
• Machine Architecture : x86
• git commit hash : 8cc3781(ros2-implement_lock_free_ring_buffer_with_throttling)

param file

ouster/os_driver:
 ros__parameters:
   sensor_hostname: '192.168.1.3'
   udp_dest: '192.168.1.77'
   mtp_dest: ''
   mtp_main: false

   lidar_mode: '1024x10'

   timestamp_mode: 'TIME_FROM_PTP_1588'
   ptp_utc_tai_offset: -37.0
   udp_profile_lidar: ''
   metadata: ''

   lidar_port: 7502
   imu_port: 7503

   sensor_frame: os_sensor
   lidar_frame: lidar
   imu_frame: os_imu
   point_cloud_frame: lidar 

   proc_mask: PCL
   scan_ring: 0
   use_system_default_qos: false
   point_type: original

[Samahu]

potentially related to #350

[Samahu]

@inwoong32 we have recently implemented a fix related to assigned timestamp values for the points. The 't' values of each point should be relative to the PointCloud message timestamp. Before the fix the values were not properly aligned so the values made no sense, can you upgrade to the latest version 0.13.3 and let me know whether it helps produce the correct timestamps.

Note that as I have mentioned in the comment on #350 issue you can still have zero timestamps but these should only occur when the xyz values are not NaNs i.e when there is no valid returns from the sensor and you should skip processing these points in your pipeline or choose non-organized point cloud.

Please update to the latest version and let me know if you are still experiencing this problem.

[Samahu]

@inwoong32 I haven't heard back from you, I am going to mark this issue as resolved with the recent changes. If you still experience the problem after update to 0.13.3 and you are certain it isn't a configuration problem on your side and not due to invalid returns as noted in previous comment then feel free to re-open the issue or start a new one.