带 SLAM 能力的采集设备（手持激光扫描仪、全景建图相机等）通常同时挂着 IMU、相机、激光、GNSS 等多类传感器，还要和机外的时间基准（GNSS 时间、后处理软件的时间）对齐。这类系统里"时间同步"不是一次对表就完事，而是一套贯穿采集、存储、后处理的设计。本文总结这类设备上反复用到的模式。
核心概念：同步时间域
多传感器融合算法（VINS、激光惯性里程计）要求参与融合的每帧数据都落在同一个时间坐标下。把设备上所有传感器数据统一到的那个时间坐标，称为同步时间域。
设计的第一步不是选同步方案，而是先明确：这台设备的同步时间域是哪个？常见选择是主控 SoC 的某个单调时钟，所有传感器数据在进入算法前都必须被标注到这个时间域上。这个时间域不需要等于任何"真实世界时间"，它只需要单调、全设备唯一。
设备上实际存在的多个时间基准
落地时会发现系统里同时跑着好几个时钟：
- 主控系统时钟：Linux 系统时间，会被 NTP 等外界因素改动，不能直接当同步时间域
- 传感器本地时钟：IMU、相机模组各自的上电计时，零点和漂移都不同
- GNSS 时间：定位模块输出的绝对时间，是与机外世界对齐的桥梁
- 后处理软件的时间轴：PC 端后处理软件解析数据包时重建的时间
时间同步方案要做的，是在这些基准之间建立确定的转换关系。
各时间基准之间的转换
模式上有两类转换：
传感器本地时钟 → 同步时间域。在硬件打通阶段解决：IMU 和相机的采样时刻要么由硬件触发信号锁定（主控发出拍照/采样控制信号，采样时刻由主控侧记录），要么在数据到达主控时打上同步时间域的时间戳并扣除已知链路延迟。前者精度更高，后者实现简单。实践中对 VINS 这类紧耦合算法，优先走硬件触发路线——IMU 与导航相机的时间同步、拍照控制本身就是这类设备硬件打通的核心工作。
同步时间域 → GNSS 时间。通过在采集过程中持续记录两者的对应点对（同一物理时刻下两个时钟的读数）建立映射。不要求两个时钟"对准"，只要求对应关系可回放——后处理时把同步时间域下的任何一帧换算到 GNSS 时间。
PPK：时间同步价值的最终体现
PPK（后处理动态差分）是这类设备上做高精度定位的常规手段：事后把机载 GNSS 观测数据和基准站数据联合解算，得到比实时解更准的轨迹。PPK 对时间同步方案提出了最苛刻的要求：
- 定位结果必须能精确对齐到每一帧图像/激光的曝光时刻，也就是"同步时间域 → GNSS 时间"的映射误差会直接变成轨迹与点云的配准误差
- 拍照事件本身需要以 GNSS 时间记录，供后处理软件逐张检索对应时刻的位置
因此时间同步方案不是采集阶段结束就完成，而是要作为数据包的一部分落盘，一路传到后处理软件。我们在产品化过程中对时间同步方案做过一次大版本迭代，核心改进正是把"采集端的时间映射关系"作为一等公民纳入数据格式，并围绕 PPK 流程做了针对性优化。
检查清单
- 同步时间域选的是哪个时钟？单调吗？全设备唯一吗？
- 每个传感器的数据进入算法前，时间戳来自硬件触发还是软件打戳？
- 同步时间域到 GNSS 时间的映射点对在持续记录吗？随数据落盘了吗？
- 后处理软件重建的时间轴和采集端一致吗？PPK 流程验证过端到端精度吗？