pf_lidar_ros_driver
pf_lidar_ros_driver copied to clipboard
PepperlFuchs
feat: add time_offset parameter
Hi,
I sent a pull request #36 to add a new parameter time_offset in case there is latency.
Regards, Jad
Though time offset is an issue, but the solution is not acceptable. It does not make sense to add a user-defined time offset.
@ipa-hsd I see your point but if you looked at other drivers of other sensors you would see that they also have this parameter for solving latency. This is an example of the sick driver https://github.com/SICKAG/sick_safetyscanners/blob/cfa456e78af42b82c1031354864837a798add4a7/config/SickSafetyscannersConfiguration.cfg#L20
Yes I have seen that and realized that was the basis of this PR. But does not necessarily mean it is a good solution.
Also ROS time is completely different from the device time. A ROS system is made up not just of laser scanner, but might involve many hardware and software components. Imagine if every hardware and software component modifies ROS time as per it's own clock.
The packet header is being published on /r2x00_header topic which has the same sequence number as in the PointCloud2 message. Probably you can use message_filters to filter messages from both topics as per the sequence number.
@ipa-hsd dealing with latency is a bit tricky but a parameter for fine tuning should be possible. Would you be open for re opening my PR ?
@ipa-hsd , just to clarify: Nobody is altering the ros::Time. The ros::Time is determined by the system clock if /use_sim_time parameter in the global namespace is false. If true, the ros::Time is determined by a ClockPublisher that publishes on the /clock topic. This additional time_offset parameter is only required for manually adjusting the timestamps of the incoming sensor readings. If ros::Time::now() is used, it means that the sensor reading was created at the current time. However, this is ofcourse not the case since the message was created x seconds ago due to a acquisition and communication delay. The time_offset in sensor drivers is often introduces to cope for these "unmeasurable" delays. Hope this clears things up.
