Synchronisation of the ROS system with the scanner, as requested in https://github.com/PepperlFuchs/pf_lidar_ros_driver/issues/23, is beyond the scope of this PR.
But the attempt here is to reduce the number of approximations by stamping the data when it is parsed. This time is closer to the ideal time at which the last scan point was sampled than the publication time. Also, since the stamp of the LaserScan message (http://docs.ros.org/en/api/sensor_msgs/html/msg/LaserScan.html) is the time of the first beam captured, it makes sense to remove the scan_time from the timestamp. If we do not do this, we will have more and more delays the longer the scan time is.
At the moment the timestamp is added just before the data is published ( https://github.com/PepperlFuchs/pf_lidar_ros_driver/pull/104/files#diff-db3fd72df08186f3c4adfeb4c26aa1eb5526a4781c16d0603ff879d0fd2f2b86L81 ).
Synchronisation of the ROS system with the scanner, as requested in https://github.com/PepperlFuchs/pf_lidar_ros_driver/issues/23, is beyond the scope of this PR. But the attempt here is to reduce the number of approximations by stamping the data when it is parsed. This time is closer to the ideal time at which the last scan point was sampled than the publication time. Also, since the stamp of the LaserScan message (http://docs.ros.org/en/api/sensor_msgs/html/msg/LaserScan.html) is the time of the first beam captured, it makes sense to remove the scan_time from the timestamp. If we do not do this, we will have more and more delays the longer the scan time is.