4. 时间同步

时间同步这件事，说实话，是感知融合里最容易被忽视、但坑最多的环节。我见过不少团队，算法模型调得漂漂亮亮，一上路就崩，最后查出来——摄像头和激光雷达的时间差了几十毫秒。嗯，几十毫秒在高速场景下，可能就是几米的偏差。

今天我们就来聊聊，怎么把多传感器的时间对齐做好。

4.1 为什么时间同步这么重要？

你想想看，摄像头拍到一辆车在位置A，激光雷达却在20ms后扫到同一辆车在位置B。融合的时候，这两帧数据一叠加，车就变成了“鬼影”。说白了，时间不同步，融合就是瞎搞。

我个人的习惯是，在项目初期就把时间同步方案定死。否则后期改起来，牵一发动全身，太痛苦了。

4.2 硬触发 vs 软触发

先讲清楚这两个概念。硬触发，就是靠硬件信号（比如PWM脉冲）来同步触发多个传感器。软触发，则是靠软件层面的时间戳对齐。

对比项	硬触发	软触发
精度	微秒级（< 1ms）	毫秒级（1-10ms）
实现难度	高（需要硬件支持）	低（纯软件方案）
成本	高（需要专用线缆、控制器）	低（现有硬件即可）
适用场景	高速移动、高精度融合	低速、静态场景

4.3 硬触发机制详解

硬触发说白了，就是给所有传感器一个统一的“心跳”。

常见的做法是：

• 用一个主控制器（比如MCU或FPGA）产生固定频率的PWM信号
• 这个信号同时接到摄像头的外触发接口和激光雷达的同步输入口
• 所有传感器收到信号后，同时开始采集一帧数据

举个例子，我常用的方案是50Hz的触发频率，也就是20ms一帧。摄像头和激光雷达都在这个上升沿开始采集。

// 伪代码：硬触发主控制器逻辑
void trigger_loop() {
    while(1) {
        GPIO_WriteLow(TRIGGER_PIN);  // 拉低
        delay_us(100);               // 保持100us
        GPIO_WriteHigh(TRIGGER_PIN); // 拉高，触发采集
        delay_ms(20);                // 等待20ms，下一帧
    }
}

4.4 软触发机制详解

软触发，说白了就是各采各的，最后靠时间戳来对齐。

核心思路是：

1. 每个传感器采集时，记录当前系统时间（比如ROS的ros::Time::now()）
2. 所有数据统一到一个时间基准（比如GPS的UTC时间）
3. 融合时，根据时间戳找到最接近的帧进行匹配

这里有个关键点——时间戳的精度。我见过有人直接用操作系统的时间，结果发现不同进程的时间差了几毫秒。为什么？因为操作系统调度有延迟。

4.5 时间戳对齐算法

有了时间戳，怎么对齐？最常用的方法是“最近邻插值”。

假设摄像头帧率30Hz（33ms一帧），激光雷达10Hz（100ms一帧）。我们要把激光雷达的每一帧，对齐到最近的摄像头帧上。

def align_timestamps(cam_ts, lidar_ts):
    """
    cam_ts: 摄像头时间戳列表
    lidar_ts: 激光雷达时间戳列表
    返回：对齐后的索引对
    """
    aligned_pairs = []
    for l_ts in lidar_ts:
        # 找到最接近的摄像头时间戳
        diff = [abs(l_ts - c_ts) for c_ts in cam_ts]
        nearest_idx = diff.index(min(diff))
        aligned_pairs.append((nearest_idx, l_ts))
    return aligned_pairs

但这里有个坑——如果两个传感器的时间差超过阈值（比如50ms），就不应该强行对齐。我一般设一个最大容忍时间，超过就直接丢弃这一帧。

4.6 知识体系总览

下面这张图，是我自己总结的时间同步知识框架。你可以把它当作一个检查清单。

4.7 实战中的取舍

说实话，没有完美的方案。硬触发精度高，但硬件成本高、调试麻烦。软触发灵活，但精度有限。

我个人的经验是：

• 量产车项目：必须上硬触发。因为要过功能安全，时间同步的确定性很重要。
• 研发测试车：软触发就够了。我曾在测试车上用软触发跑了半年，只要阈值设得合理，效果也能接受。
• 混合方案：摄像头用硬触发，激光雷达用软触发。嗯，这种方案我试过，效果还行，但调试起来比较麻烦。