ros-drivers / velodyne

ROS support for Velodyne 3D LIDARs
http://ros.org/wiki/velodyne
Other
649 stars 644 forks source link

timestamp latency #386

Open dewtrullac opened 3 years ago

dewtrullac commented 3 years ago

I am using two Velodyne VLP16 sensors. The driver's npackets parameter is configured to 1 (for both sensors, while they have different IP and port, and both are publishing to their own topic: vertical_laser_3d and horizontal_laser_3d). Since the npacket parameter is configured to 1 I expect, to get a pointcloud2 message each ~1.327 ms, which is mostly the case, but some messages are time-wise, further apart. I am storing these messages (sensor_msgs/PointCloud2) in a bag file, using rosbag record command.

When I loop through messages, and compare sequential timestamps (header's timestamp) majority of the timestamps are roughly 1.327 ms apart. But sometimes, it occurs, that the difference of two sequential messages timestamps is much higher, even up to 20 ms. I have checked if perhaps some packets in between this time got dropped, by plotting the points of a single rotation at the time when this timestamps difference occur, to see if there is a gap, but there is none. Meaning, that the messages are all there.

Since I am using the PointCloud2 messages in the combination with a servo (to spin the sensor) I would like to get the timestamps as accurate as possible, or to know where this error comes from, that I might be able to do some time offsets later in the post processing, to get more accurate results.

Does anybody know, why this could happen? By my understanding of how it functions, I thought the following might be possible, but I am not sure of how to test it to confirm the reason.

Perhaps, there is another reason, that any of you might know already.

Thank you, Drew

jack-oquin commented 3 years ago

Most likely your machine or operating system is getting busy doing some other activity from time to time.

You don't mention what OS you are running. Modern Linux kernels have reasonably good realtime performance right out of the box, but there are hardware and software components that do not play well with others in a realtime environment. Video cards are sometimes problematic.

Note that 1.327 ms is a rather challenging realtime goal using general-purpose hardware and software. Most developers would probably opt for a specialized realtime OS to guarantee response times that low. My personal opinion is that it can be done via the various realtime kernel options, with fair amount of effort configuring your system.