Incorrect frame timestamp and duration
Description
When using ROS packages velodyne_driver
and velodyne_pointcloud
to convert raw Velodyne packets to ROS PointCloud2 msg, the points in the resulting pcl::PointCloud
have no reason to be sorted by increasing acquisition timestamp. Therefore, frame timestamp and duration should not be set arbitrarily to first point timestamp, or difference between last and first points timestamps.
This results in incorrect undistortion (if activated) computation, and incorrect trajectory poses timestamps.
Impacted lines
- l543 Slam.cxx : Frame timestamp is set with
double time = pc->points[0].time;
- l187-207 SpinningSensorKeypointExtractor.cxx : Frame duration and start time are incorrectly set with following lines, which results in wrong normalized relative advancement time in modified pointcloud.
double frameStartTime = this->pclCurrentFrame->points[0].time;
double frameDuration = this->pclCurrentFrame->points[nbPoints-1].time - frameStartTime;`
Suggestions
Frame timestamp could be set accordingly from the timestamp field included in the PCL header, for example :
double time = pc->header.stamp;
This timestamp is set by velodyne_pointcloud
to the time of the last VelodynePacket
msg of the frame. It could be modified to fit to the time of the first/last point timestamp. I don't know how this field this set when using Paraview wrapping.
Frame duration can be computed from sensor frame rate, by sorting points, or by checking min/max timestamp across all pointcloud.