多传感器硬件时间同步：触发电路与编码器接口

一台移动机器人跑完一圈回来，建出的地图在拐角处出现了重影——同一面墙被描了两遍，错开十几厘米；把激光雷达点云和轮式里程计叠在一起，转弯时两者像打滑一样对不上。第一反应往往是"SLAM 算法没调好"或者"标定矩阵有问题"。但很多现场问题的真凶不在算法层，而在更底下：每个传感器活在自己的时区里。

重影的本质是"同一物理点在不同时刻被当成不同时刻采到"。SLAM 后端把每一帧位姿当已知条件去优化地图，如果喂给它的时间戳本身就偏了，优化出来的轨迹和地图必然扭曲——而且这种扭曲是系统性的、和真值有固定偏差方向的，调再多次 ICP 也回不来。老工程师有一句口头禅：先看时间戳对不对，再调算法。

本篇主线就一句话：软件时间戳的漂移（第一节）→ 用硬件触发统一板内时区（第二节）→ 用 PPS/PTP 统一跨机器时区（第三节）→ 补上最容易被遗忘的编码器接口（第四节）→ 落地成一套三件套方案（第五节）。读完你该能照着画一块触发小板。

为什么把编码器单独拎出来当第四节？因为前三种传感器（相机/IMU/雷达）的时间问题讨论得很多，而里程计作为 SLAM 的另一条腿，它的时钟常常被默认"免费正确"——这正是重影里最阴的那部分。

相机说"我这一帧是 10:00:00.000 拍的"，其实是驱动把数据递给 ROS 的那一刻；IMU 说自己"10:00:00.002 采样"，其实是串口包到达 MCU 缓冲区的时刻。当这些"到达时刻"被当成"产生时刻"拿去做融合，重影和对不上就埋下了。这篇先把"为什么软件时间戳不可信"讲清楚，再给一套硬件层面的统一时区方案，最后补上最容易被忽略的那块短板——编码器接口。

一、软件时间戳的两个误差源

问题出在 header.stamp 这个字段到底记的是哪一瞬间。理想情况下它应该记"传感器真正产生数据的物理时刻"，但软件栈里它几乎总是"数据被操作系统读到的时刻"。这中间差了两样东西。

第一样是传输延迟抖动。相机走 USB 批量传输，IMU 走串口，雷达走以太网，每条链路的协议栈延迟都不固定。举个具体数：相机固件在内部给每帧打了"帧计数器时间戳"，但它通过 USB 传到 ROS 用了 8 ms 且抖动 ±3 ms；IMU 每 5 ms 采一次，UART 到 ROS 用了 12 ms 且抖动 ±8 ms。两者真实采样差 5 ms，ROS 看到的到达时刻差可能是 9 ms，且每次都不同。融合节点如果用到达时刻反推运动状态，等于在喂噪声。

这类抖动的特点是零均值、不可预测，所以你没法像补偿固定延迟那样"减掉一个常数"——它每次都不同，只能从源头消除，也就是让采样时刻由硬件说了算。本文不展开算法层的时序标定（如 VINS 里的在线时间偏移估计），那是软件补救，能在已有误差上再抠一点，但救不了几十 ms 量级的系统性偏差。硬件根治是下限，软件补偿是上限，顺序不能反。

第二样更阴险：时钟漂移。每台设备里都有一颗晶振，标称 8 MHz、16 MHz、25 MHz 不等，但没有哪两颗晶振频率完全相等——它们的误差用 ppm（百万分之一）来标。一颗 ±50 ppm 的廉价晶振，意思是它每秒最多偏 50 / 1,000,000 = 50 ns，一天累计跑快或跑慢约 50e-6 × 86400 s ≈ 4.3 s。单看这数字好像还行，但放到 SLAM 的尺度上就很致命：

一颗 50 ppm 晶振，1 分钟漂移 = 50e-6 × 60 s = 0.003 s = 3 ms
分钟 3 ms，一小时就是 180 ms
激光雷达转一圈通常 100 ms，180 ms 相当于近两圈的转角误差

而机器人上相机、IMU、雷达往往各用各的晶振。更糟的是有些 MCU 为了省外部晶振，直接用内部 RC 振荡器——那东西精度是 1%–2%，也就是 10000–20000 ppm，一秒钟就能漂出 10–20 ms，根本没法用。把几种常见时钟源摆到一起看：

还有个隐藏项：晶振的 ppm 不是常数，它随温度变。普通晶振在 0–40°C 范围内频率-温度曲线是抛物线，拐点处最准，两端能再偏 ±10–20 ppm。机器人跑起来电机和主板发热，工作温度从冷机到热机漂移十几度，等效又叠加一层慢变偏置。这也是为什么温补晶振 TCXO 把温漂压到 ±2 ppm 内——它内部有传感器实时补偿。做长期建图，时钟源的温度特性比标称 ppm 更该被盯。

把漂移量化成距离更直观：机器人以 1 m/s 行走，轮速里程计靠晶振累积计数，50 ppm 晶振每分钟让位移估计偏 3 ms × 1 m/s = 3 mm。看着小，但回环检测要在几米误差内认出同一面墙，累积几十分钟后的偏差就足以让闭环失败，地图在闭环处"啪"地错位。更麻烦的是相机和雷达各自漂，两者的偏差不是常量而是相对斜率差——这正是点云和图像对不上、墙体重影的来源。

两个独立时钟并行走动，它们的差值只增不减——这不是噪声，是单调累积的偏置。 软件层用 NTP 在校准瞬间把表对上，但两次校准之间照样漂。要根治，得让所有传感器在"产生数据"的那一物理瞬间被同一个脉冲拍下，而不是事后去猜。

最典型的反面教材是用 usleep 让相机和 IMU 的读取线程同时醒来再各自取数据——这只能让"取数动作"同时，不能让"传感器采样动作"同时。采样发生在传感器内部，远早于你醒来那几百 ms，那段时间两颗晶振已经各走各的。软件睡眠对齐的是"取数时刻"而非"产生时刻"，纯属治标。

二、硬件触发：给所有传感器同一个时区

思路很直接：由一颗 MCU 的硬件定时器产生一路高精度的同步脉冲，在脉冲的上升沿那一瞬，所有传感器同时动作——相机开始曝光、IMU 触发一次采样中断、雷达锁存一帧 PPS。 于是所有数据的物理产生时刻被强制对齐到同一个上升沿，剩下的只是"谁先传到 ROS"的差异，而那个差异是固定延迟，可以标定补偿。

但这里有个工程坑：能不能拿 MCU 一个 GPIO 直接连到所有传感器的触发脚？答案是"能，但不该"。三个理由：

1. 共地干扰：长距离并行走线把 MCU 的地和传感器地绑死，电机、驱动器一启动，地弹噪声直接灌进触发线，脉冲会被抖烂。
2. 距离与电平：GPIO 是 3.3 V 单端信号，跑不了半米以上；相机和雷达分散在车体前后，电平还可能是 1.8 V / 5 V / LVDS 不统一。
3. 扇出与边沿：一个 GPIO 扇出三四路会衰减，上升沿变缓，远端传感器可能误触发。

触发频率怎么定？取所有传感器里最低的可用帧率再留余量。相机 30 Hz、IMU 200 Hz，就用 30 Hz 触发，IMU 每 30 Hz 取一次、其余 200 Hz 样本靠插值对齐；反过来若用 200 Hz 触发相机，相机来不及曝光，只读得到丢帧。一般取相机帧率的整数分频最省心，既保证每帧都吃到同步沿，又不浪费触发带宽。

有人会问：直接连不就省了光耦和 LVDS 的钱？账不能这么算。一次现场因地弹误触发导致建图返工，代价是几天的调试和一台样机；一颗 TLP521 几毛钱、一块 DS90LV019 一块多，隔离方案的成本相对整机可以忽略。感知同步是地基，地基上省料，楼迟早塌。

所以正路是光耦隔离 + 差分转发：

           [ MCU 硬件定时器 ]
                  │  TIMx_TRGO 同步脉冲 (3.3V 单端)
                  ▼
           [ 驱动三极管 / 门电路 ]
                  │
                  ▼
           [ TLP521 光电耦合器 ]  ← 隔离地弹、切断共地回路
                  │  隔离后的干净脉冲
      ┌───────────┼───────────┬──────────────┐
      ▼           ▼           ▼              ▼
 相机触发脚    IMU 中断脚   雷达 PPS_IN    [DS90LV019]→LVDS 远传
(曝光开始)    (采样中断)   (秒脉冲锁存)   (差分送达远端传感器)

TLP521 是经典低速光耦，隔离电压 2500 V 以上，传播延迟约 4 μs，适合几十 Hz 到几百 Hz 的触发频率。这里 4 μs 的延迟对所有通道是一样的——它只是给整条触发链加了一个固定偏置，标定一次即可。光耦的价值不是"更快"，是"把 MCU 的地和传感器的地彻底撕开"。 隔离之后，电机的地弹再也回不到触发线。

若同步频率上 kHz，4 μs 的延迟和抖动就不可忽略了，得换 6N137、HCPL-2630 这类高速光耦，传播延迟做到 75 ns 以内。还有一个容易漏的点：光耦两侧必须各自独立供电。隔离边的那颗芯片要用隔离电源（比如 B0505S 这种 5 V 转 5 V 的微型隔离 DC-DC）或传感器侧已有的干净电源，绝不能和 MCU 共用同一路 3.3 V，否则隔离白白做了。

触发极性也别随手定：多数 CMOS 图像传感器要上升沿触发曝光，IMU 中断脚低电平有效，雷达 PPS 也是上升沿。统一用 MCU 定时器的一路互补输出（TIMx_CHx 和 TIMx_CHxN）同时给正反两相，既能匹配不同极性，又免去在每个传感器前端再翻一次逻辑。触发线尽量短、远离动力线；必须平行走时夹在两侧地线之间做成微带屏蔽，别让它在板边天线一样摆着。

触发线末端并一个 1–10 kΩ 上拉到隔离边电源，别让它悬空，否则噪声一耦合就乱触发。户外或强干扰场景，光耦输入侧再串一颗 100 Ω 电阻、并一颗 TVS（如 SMAJ5.0A）到地，防 ESD 和浪涌打坏光耦 LED。光耦的发光二极管是电流器件，限流电阻按 If ≈ 5–10 mA 算，3.3 V 驱动配 330 Ω 左右即可；电阻太小 LED 早衰，太大则驱动不足、边沿变缓。

验证触发有没有真的对齐，别只信原理图。把示波器两通道分别勾在相机的帧同步输出和 IMU 的中断脚上，让 MCU 发脉冲，看两个上升沿在时间轴上的偏差——理想情况是重合在纳秒级，肉眼看就是一条线。若差了几 μs 且随温度变，多半是光耦两侧供电同源或隔离没做好；若偏差恒定，那就是固定延迟，记下来后面减掉。现场调试六成的问题，示波器一勾就现原形。

如果触发 MCU 和某个传感器各自有独立 MCU（比如雷达内部还有一颗处理器），那这两颗 MCU 的定时器也得先对到同一时基，否则"同步脉冲"在雷达侧仍按它自己的本地钟解释。办法是把 PPS 同时喂给触发 MCU 和雷达 MCU 的定时器捕获脚，两者都以 PPS 为基准重置计数器——这就把板内多级 MCU 也拉进了同一个时区，避免"触发发了，但接收方钟不对"的二次错位。

三、PPS 与跨机器：GPS 授时和 PTP

板内触发解决了"同一块板上的传感器"对齐。可一旦涉及多机、或多块独立计算机，就得引入外部绝对时间基准。

GPS 模块的 PPS（Pulse Per Second）是最便宜的秒脉冲源。 它每秒从天线锁定卫星后输出一个上升沿，精度在 ±几十 ns 量级（授时型模块能到 ±20 ns）。把这个 PPS 同时喂给每块工控机的 GPIO，所有机器就有了一个共同的"滴答"。GPS 同时通过串口吐 NMEA-0183 语句（如 GPRMC）告诉你是"哪一秒"，PPS 告诉你"这一秒的精确起点"，两者结合就能给软件时钟打上绝对时间戳。解析 GPRMC 拿到的日期时间是整秒对齐的，PPS 边沿再把它细化到纳秒——这就是"软秒 + 硬边沿"的组合拳。

但 PPS 只能对到秒，秒以内的对齐仍靠本地晶振维持。跨机器要做亚微秒级对齐，得上 PTP（Precision Time Protocol，IEEE 1588）：主时钟通过 Ethernet 发同步报文，从时钟利用网卡硬件时间戳（在 PHY/MAC 层打戳，绕过操作系统抖动）测算链路延迟并修正本地时钟。普通的软件时间戳在网卡驱动里打，受中断延迟影响能抖到几十 μs；硬件时间戳在硅里打，误差降到纳秒级。

要玩 PTP 先确认网卡支持硬件时间戳：Linux 下 ethtool -T eth0 看 Time stamping parameters，有 hardware-transmit / hardware-receive 才值得上 PTP；只有 software 的话，PTP 精度退化到几十 μs，不如老实做板内触发。这也是为什么工控机选型时网卡比 CPU 更该被盯一眼。

当然不是所有场景都值得上 PTP。低速巡检机器人（<0.5 m/s）对 ms 级时间误差不敏感，NTP 把多机对齐到 1–5 ms 已经够用，硬上 PTP 是过度设计。判断标准很简单：时间误差造成的位移 Δt × v 是否小于你的建图容差。0.5 m/s 下 5 ms 只差 2.5 mm，可忽略；2 m/s 下同样的 5 ms 差 10 mm，闭环就可能失败。速度越高，越必须 PTP。

在 ROS 2 这一层，拿到统一时间戳后靠 message_filters 把不同话题按 header.stamp 对齐：

// 相机 30Hz、雷达 10Hz，按时间戳做近似时间同步
message_filters::Subscriber<sensor_msgs::msg::Image> cam_sub(node, "camera/image");
message_filters::Subscriber<sensor_msgs::msg::PointCloud2> lidar_sub(node, "lidar/points");
typedef message_filters::sync_policies::ApproximateTime<
    sensor_msgs::msg::Image, sensor_msgs::msg::PointCloud2> SyncPolicy;
message_filters::Synchronizer<SyncPolicy> sync(SyncPolicy(10), cam_sub, lidar_sub);
sync.registerCallback(&onSynced);

上线后用 ptp4l 跑主从协商、phc2sys 把 PHC 硬件时钟同步到系统时钟，再用 pmc 查端口状态确认锁定（state 变 SLAVE 且 offset 收敛到百 ns 内）。别只看 timedatectl 显示已同步就放心——那是 NTP 的表，PTP 的精度要单独验。多机部署时指定一台带 TCXO 的机器当 grandmaster，其余做 boundary clock，避免每台都直连卫星造成抖动不一致。

没有 GPS 也没关系，PPS 不必非从卫星来。用一颗 TCXO 给 MCU 做时钟，再让 MCU 的硬件定时器每秒翻一次 GPIO 当本地 PPS，精度就能从普通晶振的 ±50 ppm 提到 TCXO 的 ±2 ppm——足够单机内所有传感器对齐到亚 ms。多机时把这个本地 PPS 分发给各工控机 GPIO，再叠加 PTP 做细调，等于自己造了一个低成本的"伪卫星"时基。前提是这台机器上电就要稳，别让它睡死或重启丢基准。

关键点：这里的 header.stamp 必须是"传感器物理产生时刻"，而不是"ROS 收到时刻"。 硬件触发和 PPS 保证的就是这个 stamp 的信噪比——滤波只是把已经对齐的数据"捡"到一起。如果上游还在填到达时刻，下游再怎么同步也是拿错的数据做对齐，重影照旧。

做完硬件同步，建议端到端验一次：用同步脉冲同时触发相机和 IMU，看 ROS 里两话题 header.stamp 的差是否收敛到亚 ms 且不再随运行时间发散。若收敛但仍有固定偏置，那是传输延迟没标，去第六节；若继续发散，说明还是两颗时钟在漂，触发没真正同源。

四、编码器接口：被忽略的最后一块短板

板内触发、PPS、PTP 把相机、IMU、雷达都收拾干净了，但很多时候建图还会飘——因为轮速/里程计的时钟根本没进这套系统。轮子上的增量编码器是最原始、也最容易被软件时间戳糊弄的传感器。

更隐蔽的是：很多方案把编码器计数直接当"当前位置"塞进 odometry 话题，却不给它的采样时刻打硬件戳——它用的是发布时刻。轮子转得快时，从"编码器计到数"到"ROS 发布"之间的几十 ms，车轮又滚了一段，里程计就永远慢半拍。正确做法是定时器捕获边沿的同时锁存一个本地时基计数器，发布时把这个时基换算成统一时间戳。

增量编码器输出 ABZ 三相：A、B 两路正交方波判断转向和计脉冲，Z 是每圈一个的零位脉冲。它直接吐的是脉冲，不是"带时间戳的数值"，所以必须靠 MCU 的定时器在脉冲边沿捕获计数——STM32 的 TIMx 编码器模式能直接做 X4 解码（A、B 四个边沿都计），硬件搞定，不占 CPU。长线传输必须走差分，因为编码器线往往和电机动力线捆在一起走，电机启停的共模噪声能到几伏。AM26LV32 这类差分接收器把 A+/A-、B+/B- 的压差还原成干净单端信号：

电机端编码器                      控制板
   A+ ───┐                          ┌── A_out ─→ MCU 定时器捕获
   A- ───┼──(差分双绞线,抗共模)───┐ │
         │                        ├─┤ AM26LV32 (4 路 RS-422 接收)
   B+ ───┘                        └─┤  VCC=3.3V, 共模范围 ±7V
   B- ───┐                          └── B_out ─→ 正交解码
         │
   Z+ ───┼── Z 零位脉冲同样差分进来
   Z- ───┘

AM26LV32 的卖点是接收共模范围 ±7 V、输入灵敏度 ±200 mV，意思是只要 A+ 比 A- 高 200 mV 就认成逻辑 1——电机噪声再大，只要两条线被噪声一起抬，差值不变，信号照常解。RS-422 双绞线末端要并一颗 120 Ω 终端电阻匹配阻抗，否则长线反射会把边沿打成振铃。板上再在 A/B 输入并一小电容（几百 pF 到 1 nF）做硬件消抖，滤掉接触毛刺，否则一个抖动脉冲就让里程计凭空多走几毫米。

正交解码的方向判定也值得提一句：A 相领先 B 相 90° 是正转，B 领先 A 是反转。线序接反了，里程计方向就反，融合时车体"倒着走"，建图直接崩。STM32 的编码器接口有 TIM_ENCODERMODE_TI12，硬件自动按相位差判向，但前提是 A/B 没焊反——上电先用个手动转轮验证一下计数增减排向对不对，比事后查代码快得多。Z 零位脉冲则用来把多圈累计清零、消除长期计数的舍入误差，每圈归一次零位最稳。

实际布线有个常被忽略的坑：把 A/B 两根线拉得不一样长。差分对的两条线长度差超过信号上升时间对应的电长度（编码器上约几 cm），接收端看到的就是 A、B 不同时到达，正交相位被拉长，高速计数会丢边沿。所以 A+/A-、B+/B- 必须等长绕线，差控制在 5 mm 内——这是差分线的基本功，和共模抑制同样重要。

差分线本身也有讲究：用屏蔽双绞线（STP），A+/A- 绞在一起，屏蔽层单端接地（只在控制板侧接，电机端悬空），避免屏蔽层形成地环路反而引入噪声。线长超过十米时，AM26LV32 接收端除了 120 Ω 终端还要把未用的通道输入短接到地或偏置，别留浮空引脚当天线。26LV32 是 3.3 V 版，若传感器是 5 V 逻辑要换 26C32（注意 26C31/26C32 才是驱动接收对，26LV 系列才是低电压）。

前面讲的是控制板侧的接收（AM26LV32）。编码器那头如果是差分输出型，它本身就用 AM26LV31 / 26C31 这类差分驱动把单端正交信号转成 A+/A- 发出去；若是集电极开路或单端编码器，则要在一端先加驱动再做长线。记住 RS-422 是"平衡驱动器 + 平衡接收器"成对出现的，线两头器件要配齐，别指望单端编码器直接怼进 AM26LV32——灵敏度 ±200 mV 是给差分信号预备的，单端悬着的一根线没有回流通路。

至于绝对值编码器，SSI（同步串行接口）和 BiSS-C 直接输出每圈绝对角度，断电不丢位置，靠时钟沿逐位读出。BiSS-C 是时钟驱动的全双工协议，速率能到 10 MHz，带 CRC 和从机报警，比单向的 SSI 更稳；一句话带过：要绝对位置、要免回零，选 BiSS-C；只要相对位移、要便宜，增量差分配 AM26LV32 足矣。

回到开头那句：重影的凶手常常不是算法，是里程计这条腿的时钟没和相机对齐。增量编码器只要差分接好、定时器锁好时基，就能和相机-IMU 进同一个时区，闭环不再因为"腿和眼不同步"而错位。这一步成本最低、收益最隐蔽，也最容易被跳过。

五、实战清单：相机-IMU-雷达三件套怎么排

把前面几节落到一张表，就是一套最小可用的同步方案。注意"精度量级"指的是各传感器物理产生时刻之间的相对不确定度：

优先级上，相机-IMU 这对最该先同步：VIO/视觉惯性里程计对两者时差最敏感，几 ms 偏差就会让尺度估计漂移。雷达相对宽容，因为单帧点云内部时间一致性比跨帧对齐更重要。所以小车上若只够做一路触发，优先喂相机和 IMU。

排布原则：能硬件触发的绝不靠软件睡眠对齐，能差分的绝不走单端长线，能 PTP 的绝不只靠 NTP。 触发脉冲走光耦隔离，编码器走 AM26LV32 差分，远端走 LVDS——这三句话基本覆盖了移动机器人感知层的同步布线。

预算极紧、跑不了光耦和 LVDS 的小车，至少做到两步：相机和 IMU 共用 MCU 一路定时器触发（成本几乎为零），编码器务必差分（AM26LV32 几毛钱）。PTP 可暂用 NTP 顶替，但要清楚 NTP 只有 ms 级，高速场景迟早要换。同步的投入和 SLAM 收益是强相关的——先有对的时基，再谈算法优化。

临上线前用三句话自检：触发脉冲示波器上看齐了没？PPS 日期解析了没？编码器差分且方向验证了对没？三个"没"对应前三节，任一个没过，建图就还背着物理层面的病因。

这套方案在作者经手的几台 AGV 和巡检机器人上都跑过。最夸张的一次，把 50 ppm 晶振的散架建图换成 TCXO + 光耦触发后，回环误差从 30 cm 降到 3 cm 以内——硬件同步的红利，往往要等闭环成功那一刻才显形。

六、固定延迟也要消：离线标定

硬件触发把"产生时刻"对齐了，但数据从传感器到 ROS 还有一段固定传输延迟——USB 几 ms、以太网亚 ms、串口十几 ms。这些不是抖动，是常量偏置，融合时若不减掉，相机和雷达之间仍残留一个固定时移。消法是离线标定一次、长期复用。

在机器人上装一个 LED，由 MCU 同步脉冲同时点亮 LED 并打 IMU 中断；LED 亮这一事件既被相机拍到（在图像里看亮度跳变），也被 IMU 记到（中断时刻）。把图像里检测到的亮起帧时间和 IMU 中断时间做互相关，差就是相机相对 IMU 的固定延迟，写进标定文件减掉即可。雷达同理，用 PPS 锁存时刻和到达时刻之差估传输延迟。传输延迟本身几乎不随温度变，所以标定一次能吃很久，把残差再压一个数量级。

给个量级参考：USB 3.0 相机的端到端延迟常在 20–40 ms 且批次间不一致，UART IMU 约 10–15 ms，这两者的差就是十几 ms 级的固定偏置，不标掉的话 VIO 直接尺度崩。标定本身不难，难的是别偷懒——很多团队卡在"差几 ms 无所谓"，结果高速回环时那几 ms 正好越过了闭环阈值。

七、常见踩坑：工程现场的血泪清单

1. 用 MCU 内部 RC 当同步时钟。 图省一颗晶振，结果 1% 精度让 IMU 和相机在一分钟内漂出近 1 秒，建图直接散架。外部晶振是底线，TCXO 更稳。
2. 光耦隔离却共用电源。 隔离边的芯片还从 MCU 的 3.3 V 取电，地没断开，隔离形同虚设。隔离边必须独立供电。
3. PPS 接了但不解析 NMEA。 只有秒脉冲没有日期，所有机器都以为自己是"今天 00:00:00"，跨天直接错 24 小时。PPS 配 GPRMC 才完整。
4. 编码器单端长线直连。 几米线不差分，电机一转里程计就跳数。凡超过半米、邻近动力线，必须 AM26LV32 这类差分接收。
5. header.stamp 填到达时刻。 上游不改，下游 message_filters 再准也是拿错数据对齐。硬件同步的红利全卡在"stamp 填对"这一行代码上。
6. 触发频率和曝光时间打架。 相机曝光 30 ms 却要 100 Hz 触发，帧没读完就被下一拍打断，丢帧还错时。触发周期必须 > 曝光时间 + 读出时间。
7. 只同步不标定固定延迟。 硬件把产生时刻对齐了，但 USB/以太网传输延迟仍是固定偏置，不量出来减掉，残差照样有亚 ms 级误差。用双传感器互相关法离线标一次。
8. 差分线屏蔽层两端接地。 屏蔽层在电机端也接了地，和控制板地形成地环路，电机噪声顺着屏蔽层灌回来。屏蔽层只在一端接，另一端悬空或经电容接地。
9. 把同步当一次性工程。 换传感器型号、改相机帧率、动触发频率后不重标，之前的标定全废。同步参数随 BOM 和配置走，任何改动都要回到示波器重验时基，别信"上次标过就行"。

八、软硬联动：同步是感知的地基

讲到底，时间同步不是炫技，它是所有感知融合的地基。地基歪了，上面建再多算法楼都会斜。硬件触发统一了板内时区，PPS/PTP 统一了跨机器时区，编码器接口补齐了里程计这块最短的板——三件事做完，SLAM 的"重影"和"对不上"至少能消掉一大半物理层面的病因。

这一篇只讲了"时间"怎么对齐。要让轮子真的按指令转、让数据真的低延迟进算法，还有两篇要搭配着看：驱动侧看三相 FOC 驱动板：栅极驱动与电流采样，它决定了电机相电流采样和编码器计数的同源精度；通信侧看ROS 2 高性能通信架构：自定义接口零拷贝与硬件桥接，它决定了同步好的数据能不能以最低延迟喂给融合节点。时间对齐、驱动精确、通信够快——三者齐了，感知才站得住。

把这套逻辑串起来看，感知链路的每个环节都在和时间较劲：驱动要采得准（FOC 篇的电流与编码器同源）、通信要传得快（通信架构篇的零拷贝）、而本篇要采得"同时"。三者不是并列的模块，是一条流水线——上游不同步，下游再快再准也是把错的数据加速搬运。所以调试顺序也该反过来：先用示波器把时基对齐，再调驱动，最后压通信延迟。重影治好了，再去怪算法不迟。

下一期可以接着聊：当所有传感器时基统一后，SLAM 后端该怎样利用这个高质量 stamp 做紧耦合——那是软件层能真正发挥红利的地方。

参考文献

1. IEEE Standard 1588-2019, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems（PTP/IEEE 1588 权威定义，硬件时间戳与链路延迟测算）。
2. Texas Instruments, AM26LV32 Quadruple Differential Line Receiver datasheet, SLLS103E（±7 V 共模范围、±200 mV 灵敏度、RS-422 接收器参数）。
3. Texas Instruments, LVDS Owner's Manual / SLLS072 – LVDS Design Guide, 4th ed.（DS90LV019 等 LVDS 收发器应用与抗噪设计）。
4. ROS 2 Documentation, message_filters — ApproximateTime Policy（按 header.stamp 多话题时间同步 API）。
5. u-blox / Trimble, Timing Modules Application Note: PPS and NMEA Synchronization（GPS PPS ±几十 ns 授时与 GPRMC 解析）。
6. iC-Haus, BiSS-C Interface Protocol Description（绝对值编码器 BiSS-C 串行协议，相对 SSI 的改进）。

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章