Timestamping laser scan message

[stribor14]

in the LaserScan message, it is written that the timestamp in the header should be a time at which first reading was made.

Currently, in the code (and in the other driver), this field is populated by ros::Time::now() just before publishing message, which is by default wrong timestamp.

In the documentation, it says that there exists synchronized timestamp, but it still isn't implemented and only raw can be used (which calculates time from zero at the moment of turning on the sensor). Is there any news on a firmware updates to solve this?

If not, in the meantime, probably it would be more accurate at the initialization of driver to get a few raw timestamp reading and to time round trip time, and then average it to get approximate offset which could then be applied to the timestamp in the header of laser reading data to populate header in ROS message.

[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?