为何Velodyne的PointCloud2消息录制到rosbag时存在不一致问题

你使用的Intel Core I5-7600、I5-8365U处理器性能完全满足VLP-16激光雷达的驱动、点云处理需求，该问题和CPU性能无关，导致点云消息发布断续、Cartographer报时间重叠的可能原因如下：

• velodyne驱动npackets参数逻辑不匹配
  npackets参数定义了每次ROS点云消息发布累积的UDP数据包数量，VLP-16默认每秒输出750个UDP数据包，npackets设为1时理论点云发布频率为750Hz。但默认驱动逻辑下，单UDP包对应雷达旋转过程中1.3ms左右的扫描数据区间，当你拆分为单包发布时，驱动未正确计算每包点云对应实际扫描的起止时间戳，仅以包接收时间作为整包的时间区间边界，就会出现前一包的扫描结束时间晚于后一包的扫描开始时间的重叠问题，和你报错中最长1.2975ms的重叠时长完全匹配。
• UDP接收缓冲区不足
  npackets=1的场景下，系统每秒需要处理750个高频小包，Ubuntu默认的UDP接收缓冲区大小仅为212992字节，高频率小包场景下极易出现缓冲区溢出丢包、包接收延迟的问题，直接表现为RQT中看到的点云消息发布断断续续。
• ROS高频消息调度开销
  每秒750次点云消息发布需要重复执行ROS消息序列化、队列调度、发布的完整流程，即使单条消息体积不大，高频次的上下文切换也会带来随机调度延迟，部分消息发布晚于预期，进一步加剧时间重叠问题。

对应解决方法 #

• 调整npackets参数：无需强行匹配谷歌示例的消息频率，VLP-16默认10Hz整圈扫描对应的npackets值为75，该配置下每包点云对应完整一圈扫描数据，不会出现时间重叠问题。如果确实需要高频点云输出，可将npackets设为5~10，平衡频率和系统开销，不建议设置为1。
• 调大系统UDP接收缓冲区，执行以下命令临时生效，如需永久生效可将配置写入/etc/sysctl.conf：

sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=26214400

• 开启velodyne驱动的逐点时间戳校正功能，确保正确加载雷达校准文件、配置time_offset参数，让每包点云的起止时间戳和实际扫描区间对齐，消除逻辑层面的时间重叠。
• 若必须保留750Hz的点云输出，可改用nodelet模式运行velodyne驱动，减少消息拷贝开销，避免调度延迟。

内容的提问来源于stack exchange，提问作者Michael Kossin