3. 时钟同步原理

多摄像头系统里，时钟同步是个绕不开的坎。说白了，就是让每个摄像头都知道「现在」到底是几点几分几毫秒。如果各拍各的，时间戳对不上，后面做融合、做拼接、做三维重建，全都会乱套。

我最早做双目视觉的时候，觉得两个摄像头挨着放，时间应该差不多吧？结果一分析数据，发现左右图的时间差能飘到几十毫秒。嗯，从那以后我再也不敢轻视时钟同步了。

这一章，咱们把三种主流同步方案掰开揉碎讲清楚：PTP 协议、硬件触发、软件时间戳。每种方案都有它的适用场景，也有它的坑。

3.1 为什么需要时钟同步？

先想一个问题：两个摄像头同时拍一个运动物体，如果它们的时钟差 10ms，物体移动了 1 米，那融合出来的点云就是错位的。你想想看，这数据还能用吗？

时钟同步要解决的核心矛盾就两个：

  • 频率同步：所有摄像头的时钟走速一致，每秒滴答次数相同。
  • 相位同步：所有摄像头的时钟起点对齐，知道「时间」是多少。

频率同步保证误差不累积，相位同步保证误差有基准。缺一个，系统就不稳。

关键指标：多摄像头系统的同步精度通常要求亚毫秒级（<1ms），高端视觉测量系统甚至需要微秒级（<10μs）。

3.2 PTP（IEEE 1588）协议

PTP 全称 Precision Time Protocol，精度能到亚微秒级。它不像 NTP 那样走网络层，而是走硬件时间戳，直接在 MAC 层或物理层打时间标签，延迟抖动极小。

3.2.1 PTP 的工作原理

PTP 网络里有一个主时钟（Master），其他都是从时钟（Slave）。主从之间通过四步握手来校准：

  1. Sync 消息：主时钟发出 Sync 包，记录发送时间 t1。
  2. Follow_Up 消息：主时钟把 t1 告诉从时钟。
  3. Delay_Req 消息：从时钟发出请求，记录发送时间 t2。
  4. Delay_Resp 消息：主时钟收到请求，记录接收时间 t3，并回复给从时钟。

从时钟拿到 t1、t2、t3、t4 四个时间戳，就能算出链路延迟和时钟偏移，然后调整自己的本地时钟。

我的经验：PTP 精度高度依赖网络拓扑。我建议用交换机做边界时钟（Boundary Clock），别让 PTP 报文穿过太多跳数。每多一跳，抖动就多一层。

3.2.2 PTP 的硬件支持

不是所有网卡都支持 PTP。你需要找带 硬件时间戳引擎 的芯片，比如 Intel I210、I350，或者 FPGA 自己实现 PTP 栈。软件 PTP 精度只能到毫秒级，基本没用。

方案 精度 硬件要求 典型场景
软件 PTP ~1ms 普通网卡 低精度监控
硬件 PTP <100ns 专用网卡/FPGA 自动驾驶、工业视觉
混合 PTP ~10μs 部分硬件支持 机器人、无人机

3.2.3 PTP 的配置示例

在 Linux 系统上，用 ptp4l 工具配置 PTP 主时钟：

# ptp4l 配置文件示例
[global]
clockClass              248
clockAccuracy           0xFE
priority1               128
priority2               128
domainNumber            0
logging_level           6
network_transport       L2
delay_mechanism         E2E

启动命令：

sudo ptp4l -f /etc/ptp4l.conf -i eth0 -m

注意：PTP 报文默认走多播，如果你的网络有 VLAN 隔离，记得放通多播流量。我曾经因为交换机没配 IGMP Snooping，折腾了两天才发现是报文被丢了。

3.3 硬件触发（GPIO/FSYNC）

硬件触发是最直接、最可靠的同步方式。它不依赖网络，直接用一根信号线把多个摄像头的曝光时刻对齐。

3.3.1 硬件触发的工作原理

主控板（比如 FPGA 或 MCU）产生一个脉冲信号，通过 GPIO 或 FSYNC 引脚同时发给所有摄像头。摄像头收到脉冲后，立即开始曝光或复位帧计数器。

信号可以是：

  • 上升沿触发：脉冲从低到高时触发。
  • 下降沿触发：脉冲从高到低时触发。
  • 电平触发：持续高电平或低电平期间触发。

我个人习惯用上升沿触发，抗干扰能力更强。

3.3.2 硬件触发的精度

硬件触发的精度主要取决于信号传输延迟和摄像头响应时间。在 PCB 板上走线，延迟可以控制在纳秒级；用线缆连接，延迟取决于线长和驱动能力。

连接方式 典型延迟 抖动
PCB 走线 <1ns <0.1ns
同轴电缆（1m） ~5ns <1ns
双绞线（1m） ~10ns ~2ns
LVDS 差分线 <3ns <0.5ns

3.3.3 硬件触发的实现示例

用 FPGA 产生 30Hz 的触发脉冲：

// Verilog 代码片段
reg [23:0] counter;
reg trigger_out;

always @(posedge clk_100MHz) begin
    if (counter == 3_333_333) begin  // 30Hz
        counter <= 0;
        trigger_out <= 1;
    end else begin
        counter <= counter + 1;
        trigger_out <= 0;
    end
end

避坑指南：我曾经用普通 GPIO 直接驱动多个摄像头，结果信号反射导致误触发。后来加了 74HC244 缓冲器，问题就解决了。记住，驱动多个负载时一定要加缓冲。

3.4 软件时间戳

软件时间戳是成本最低的方案，不需要额外硬件，直接在应用层或驱动层打时间标签。但精度也最低，受操作系统调度和中断延迟影响很大。

3.4.1 软件时间戳的实现方式

常见做法有两种：

  • 应用层时间戳：在读取图像数据时调用 clock_gettime() 或 gettimeofday()。
  • 驱动层时间戳：在摄像头驱动的中断服务程序里打时间戳。

驱动层时间戳比应用层更准，因为离硬件更近。但即使这样，精度也只能到毫秒级。

3.4.2 软件时间戳的误差来源

误差主要来自三个方面：

  1. 调度延迟：操作系统可能正在处理其他任务，你的线程被挂起。
  2. 中断延迟：中断响应时间不确定，尤其是高负载时。
  3. 时钟漂移：本地时钟本身就不准，需要 NTP 或 PTP 校准。

实测数据：在普通 Linux 系统上，应用层时间戳的抖动通常在 1-5ms 之间。用实时内核（RT-PREEMPT）可以降到 100μs 左右。

3.4.3 软件时间戳的优化技巧

如果只能用软件方案，我建议做几件事：

  • 绑定 CPU 核心，避免线程迁移。
  • 提高线程优先级，用 SCHED_FIFO 调度策略。
  • 禁用 CPU 频率缩放，防止时钟频率变化。
  • 用 clock_gettime(CLOCK_MONOTONIC_RAW, ...) 避免 NTP 调整带来的跳变。
// C 代码示例：高精度时间戳
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
uint64_t timestamp_ns = ts.tv_sec * 1000000000ULL + ts.tv_nsec;

3.5 三种方案的对比与选择

三种方案各有优劣，选哪个取决于你的系统需求。我整理了一张对比表：

方案 精度 成本 复杂度 适用场景
PTP <100ns 中 高 分布式系统、车载网络
硬件触发 <10ns 低 低 近距离多摄像头、工业检测
软件时间戳 ~1ms 极低 低 低成本方案、非实时系统

我的建议是：能用硬件触发就用硬件触发，简单可靠。如果摄像头分布较远，走 PTP。实在没办法了，再考虑软件时间戳，但要做好精度评估。

3.6 本章知识结构图

下面这张图把三种同步方案的核心逻辑串起来了，方便你理解它们之间的关系：

时钟同步方案知识结构图 时钟同步方案知识结构图 时钟同步方案 PTP 协议 硬件触发 软件时间戳 主从握手校准 硬件时间戳引擎 边界时钟/透明时钟 GPIO/FSYNC 脉冲 上升沿/下降沿触发 缓冲器驱动多负载 应用层/驱动层 调度/中断延迟 实时内核优化 精度：硬件触发 > PTP > 软件时间戳 成本：软件时间戳 < 硬件触发 < PTP

3.7 本章小结

时钟同步是多摄像头系统的基石。PTP 适合分布式网络，硬件触发适合近距离高精度场景，软件时间戳是低成本妥协方案。选型时，先看精度需求，再看系统架构，最后考虑成本。

嗯，这一章的内容就到这里。记住一句话：同步做不好，融合全白搞。

← 上一章 📖 返回目录 下一章 →