1. 时间同步基础：为什么需要时间同步？
做多传感器融合这些年，我踩过最大的坑，就是时间不同步。
你想想看，激光雷达说「前方3米有障碍物」，相机说「前方3米是空地」，两个传感器各说各话。到底信谁？其实它们说的可能都对——只是时间没对上。
时间同步，说白了就是让所有传感器用同一个「时钟」说话。这件事做不好，融合算法再牛也白搭。
为什么需要时间同步？
我举个例子。你在高速上开车，车速100km/h。激光雷达和相机的时间差了100毫秒。100毫秒能跑多远？差不多2.8米。
这意味着什么？
- 激光雷达看到障碍物在10米外
- 相机看到障碍物在7.2米外
- 融合结果：障碍物位置不确定，误差接近3米
这在自动驾驶里，就是撞车和刹停的区别。
我在项目中遇到过更夸张的情况。有个客户用GPS授时，结果GPS信号被高楼遮挡，两个传感器的时间差直接飙到500毫秒。融合出来的轨迹，简直像喝醉了酒在画龙。
核心结论：时间不同步会导致空间对齐失效。传感器数据的时间差，会直接转化为位置误差。这个误差在高速运动场景下，是致命的。
时间同步的核心概念
搞时间同步，你得先搞懂三个东西：时间戳、时钟源、延迟。我一个个说。
1. 时间戳
时间戳就是数据的「出生证明」。每个传感器数据包，都应该带一个时间戳，告诉系统「我是在什么时候采集的」。
但这里有个坑——时间戳是谁打的？
- 硬件打戳：传感器内部芯片直接打时间戳。精度高，但需要硬件支持。
- 软件打戳：数据到达CPU时，由驱动层打时间戳。成本低，但精度受系统负载影响。
我个人习惯，能用硬件打戳就用硬件。软件打戳在低负载时还行，一旦CPU忙起来，时间戳能偏出去几十毫秒。
注意：ROS1默认用的是软件打戳。如果你做高精度融合，建议换成ROS2或者自己实现硬件时间同步。我曾经因为这个原因，在项目后期被迫重写驱动层，教训深刻。
2. 时钟源
时钟源就是大家参考的「标准时间」。常见的时钟源有：
| 时钟源类型 | 精度 | 适用场景 |
|---|---|---|
| CPU系统时钟 | 毫秒级 | 低精度、低成本方案 |
| GPS/GNSS授时 | 微秒级 | 室外、有GPS信号 |
| PTP网络时钟 | 亚微秒级 | 局域网、工业场景 |
| 原子钟 | 纳秒级 | 科研、军事 |
选哪个？看你的精度需求。
做低速AGV，CPU时钟就够了。做高速自动驾驶，至少得上GPS授时。我见过有人用CPU时钟做高速融合，结果跑一圈回来，两个传感器的时钟差了2秒多——嗯，这已经不是融合了，这是穿越。
3. 延迟
延迟是时间同步里最容易被忽略的东西。很多人以为打了时间戳就万事大吉，其实不然。
延迟分三种：
- 采集延迟：传感器从物理世界采样到生成数据包的时间
- 传输延迟：数据从传感器传到处理单元的时间
- 处理延迟：数据在CPU排队等待处理的时间
你想想看，激光雷达扫描一圈要100毫秒。这100毫秒里，车已经跑了2.8米。如果你用扫描结束的时间作为时间戳，那前面扫到的点，时间戳其实是错的。
我的经验：处理延迟可以用时间戳队列来补偿。我在一个项目中，给每个传感器数据维护一个环形缓冲区，记录最近100个数据包的时间戳和到达时间。这样就能估算出当前的处理延迟，做动态补偿。
时间同步的核心逻辑
说了这么多，我画个图帮你理一理思路。
这个图其实就说明白了：所有传感器先统一时钟源，然后各自打时间戳，再补偿延迟，最后才能做融合。少一步都不行。
避坑指南
做时间同步这些年，我总结了几条血泪教训：
- 别信「默认配置」：ROS的默认时间同步，精度只有几十毫秒。做高精度融合，必须自己写时间同步模块。
- 注意时钟漂移：CPU时钟会漂移，一小时能差几毫秒。长时间运行的系统，必须定期校准。
- 延迟不是常数：系统负载变化，延迟也会变。别用固定值补偿，要动态估算。
我曾经踩过的坑：有个项目用了USB摄像头，驱动层打时间戳。结果USB总线拥堵，时间戳延迟了200毫秒。我查了三天才找到原因。后来换成硬件触发同步，问题才解决。
时间同步这件事，说白了就是「让所有传感器在同一个时间维度上说话」。做不好，融合算法就是空中楼阁。做好了，后面的工作才能顺风顺水。
嗯，这一节就到这里。记住这三个核心概念：时间戳、时钟源、延迟。后面我们会深入讲具体怎么实现。