I have checked more in depth the problem of the timestamp (merged in the last PR).
It boils down to the type of timestamp defined by manufacturers in the PointCloud2 Messages.
E.g. In my case (i'm using a livox 360 lidar, with PointCloud2 messages), the messages are of type double but are expressed in nanoseconds.
That means , that a given lidar can output different timestamps e.g. for linux timestamp :
1726578368464684544.00 (double and nanoseconds (my case))
1726578368.464684544 (double, and seconds)
1726578368 (int and seconds)
1726578368464684544 (int64 and nanoseconds)
It could even by microseconds, or any other combination or datatype and time unit.
This has an impact on the way that timestamps have to be converted in the ExtractTimestampsFromMsg fucntion in RosUtils.cpp (line 55).
In this function, all timestamp are converted to a vector of double, but that does not mean that they necessarily are expressed in seconds (in my case, those are nanoseconds).
Any idea how this could be handled ? maybe a configuration file that would indicate the format of the timestamp ?
Hi,
I have checked more in depth the problem of the timestamp (merged in the last PR).
It boils down to the type of timestamp defined by manufacturers in the PointCloud2 Messages. E.g. In my case (i'm using a livox 360 lidar, with PointCloud2 messages), the messages are of type double but are expressed in nanoseconds.
That means , that a given lidar can output different timestamps e.g. for linux timestamp :
It could even by microseconds, or any other combination or datatype and time unit.
This has an impact on the way that timestamps have to be converted in the ExtractTimestampsFromMsg fucntion in RosUtils.cpp (line 55). In this function, all timestamp are converted to a vector of double, but that does not mean that they necessarily are expressed in seconds (in my case, those are nanoseconds).
Any idea how this could be handled ? maybe a configuration file that would indicate the format of the timestamp ?
Cheers :) !