3. 时间同步机制：ROS时间戳、系统时间、时间同步策略
做轨迹评估，最怕什么？
我最怕数据对不上。明明传感器采集的是同一时刻的数据，回放时却发现轨迹和图像差了半秒。这种问题，十有八九是时间同步没做好。
今天我们就来聊聊时间同步这件事。说白了，就是让不同来源的数据，在时间轴上能对齐。
3.1 ROS时间戳：数据的“身份证”
ROS里的每条消息，都自带一个时间戳。你可以把它理解成数据的“出生证明”。
我个人习惯，在发布消息时，一定手动打时间戳。别偷懒用默认值。
// 正确做法：手动打时间戳
sensor_msgs::Imu imu_msg;
imu_msg.header.stamp = ros::Time::now();
// 错误做法：依赖自动填充
// 有些驱动会自动填，但不可靠
我在项目中遇到过，某款激光雷达驱动，时间戳默认填的是0。结果回放时，所有点云都堆在起点。排查了两天才发现是这个问题。
注意：ROS时间戳的单位是秒，但内部存储是秒+纳秒。别直接用浮点数比较，精度会丢。
3.2 系统时间：ROS时间戳的“靠山”
ROS时间戳，本质上是从系统时间来的。但这里有个坑：系统时间可能不准。
你想想看，如果电脑的时钟漂移了，ROS时间戳自然也跟着漂。所以，我建议所有做数据采集的机器，都配好NTP服务。
| 时间源 | 精度 | 适用场景 |
|---|---|---|
| 系统时间 | 毫秒级 | 普通数据采集 |
| NTP同步 | 亚毫秒级 | 多机协同 |
| PTP（IEEE 1588） | 微秒级 | 高精度传感器 |
嗯，这里要注意：如果你用笔记本采集数据，合上盖子再打开，系统时间可能跳变。我吃过这个亏，后来都改成台式机或者工控机了。
3.3 时间同步策略：近似同步 vs 精确同步
时间同步，说白了就两种思路：
- 近似同步：找时间戳最接近的数据配对。简单，但精度有限。
- 精确同步：利用硬件信号（如GPS的PPS）对齐。复杂，但精度高。
我一般这么选：
- 如果只是做可视化，近似同步就够了。
- 如果要算轨迹误差，必须精确同步。
核心原则：同步精度，至少要高于传感器采样间隔的1/10。比如相机是30Hz（33ms），同步误差要小于3ms。
3.4 时间戳对齐实战：代码怎么写
下面是我常用的对齐方法。以激光雷达和IMU为例：
def align_timestamps(laser_topics, imu_topics, max_diff=0.01):
"""
近似同步：找时间差小于10ms的数据对
"""
aligned_pairs = []
for laser_msg in laser_topics:
laser_time = laser_msg.header.stamp.to_sec()
# 找最近的IMU数据
closest_imu = min(imu_topics,
key=lambda x: abs(x.header.stamp.to_sec() - laser_time))
diff = abs(closest_imu.header.stamp.to_sec() - laser_time)
if diff < max_diff:
aligned_pairs.append((laser_msg, closest_imu, diff))
return aligned_pairs
这段代码看着简单，但实际用的时候，有几个坑：
- 数据量大的时候，min()函数会卡。建议用二分查找。
- max_diff别设太死。我一般先统计一下时间差分布，再定阈值。
小技巧：对齐后，把时间差画成直方图。如果分布是高斯型，说明同步没问题。如果出现双峰，说明有数据丢了。
3.5 实战中的“避坑指南”
我曾经在某个项目中，发现轨迹评估结果总是偏大。查了三天，最后发现是时间戳对齐时，用了错误的坐标系时间。
嗯，这里要记住：
- ROS时间戳是UTC时间，不是本地时间。
- 如果用了模拟器，时间戳可能是虚拟时间，不能和真实数据混用。
- 多传感器融合时，最好统一用GPS时间作为基准。
说白了，时间同步这件事，做对了没人夸你，做错了坑死人。我建议你在项目一开始，就写好时间同步的测试用例。别等到最后才发现问题。
可可精品资料库