Timestamping laser scan message about pf_lidar_ros_driver

[hsd-dev]

Synchronized time or any other time sent by the device is completely different from ROS time. If you want to access the device's timestamp for any reason, I am publishing it on a topic /r2x00_header. There you can view the entire header sent by the device.

According to the comment in the LaserScan message, maybe a better suited place to use ros::Time::now() would be here

[stribor14]

I agree that they are completely different timekeeping services and not only can they be offset, they can also drift apart. But still, if an algorithm is relying on precise timestamps (and for this reason fields like time_increment and scan_time exist), such usage of ros::time::Now() can be detrimental.

An example of this, imagine the sensor traveling at a higher speed in a straight line, how much distance does it cover between acquiring first and last laser ray? Furthermore, how much additional distance did it travel until ros::time::Now() was called and was assigned to the first ray? Sure, it depends on sensor velocity and scan frequency, but its effects are noticeable in some applications. (Edit: reasoning here is that you can later reliably deduce exact place and time along the trajectory at which each individual laser ray was measured at)

This is why I asked about a firmware update for a synchronized timestamp or some ROS side raw timestamp synchronization.

EDIT (real example): if you use cartographer SLAM with this driver (or other driver that also uses ros::Time::now()), there is a lot of dropped points (hundreds) for every scan because of timestamp inaccuracy

[bxc237]

EDIT (real example): if you use cartographer SLAM with this driver (or other driver that also uses ros::Time::now()), there is a lot of dropped points (hundreds) for every scan because of timestamp inaccuracy

Hi, @stribor14 ,if you reduce the scan frequency, does the problem still there?