4、硬件同步：ToF与RGB相机的硬触发与软触发方案

做多传感器融合，最头疼的问题是什么？

我个人的答案是：时间同步。

你想想看，ToF相机采集一帧深度图，RGB相机采集一帧彩色图。如果这两帧不是同一时刻拍的，那融合出来的彩色点云就是「错位」的。物体动一下，边缘就出现重影，颜色和深度对不上。嗯，这问题我在项目里踩过好几次坑。

4.1 为什么需要硬件同步？

先讲个真实案例。我之前做一个人体三维重建的项目，用的是某品牌的ToF模组和USB摄像头。软件上各自开线程采集，然后靠时间戳对齐。结果呢？

• 人站着不动还好，稍微晃一下，点云就花了
• 手挥动的时候，彩色图和深度图差了将近50ms
• 重建出来的人脸，嘴巴是歪的

说白了，软件时间戳的精度不够。操作系统调度、USB传输延迟、缓存堆积，这些都会引入不可控的抖动。你想想看，ToF一帧曝光可能就几毫秒，RGB一帧曝光也是几毫秒，但两者之间的时间差可能达到几十毫秒——这误差太大了。

4.2 硬触发方案：用一根线搞定同步

硬触发，说白了就是让一个相机发出脉冲信号，另一个相机收到信号后立即开始曝光。

我习惯把ToF相机设为主设备，RGB相机设为从设备。为什么？因为ToF的曝光时序通常更严格，它需要配合激光发射的时序。

4.2.1 硬件连接方式

• ToF相机：GPIO输出引脚，配置为「帧同步信号输出」
• RGB相机：GPIO输入引脚，配置为「外部触发模式」
• 连线：一根杜邦线，连接ToF的OUT到RGB的IN

我记得第一次搭这个电路时，还特意用示波器看了波形。ToF输出的是一路3.3V的方波，上升沿触发RGB开始曝光。时序上要特别注意：

参数	典型值	说明
触发信号脉宽	≥100μs	太短了RGB可能检测不到
触发信号延迟	<1μs	线缆长度影响很小
RGB曝光延迟	几μs到几十μs	取决于相机内部处理

4.2.2 代码配置示例

以某款ToF模组为例，配置硬触发输出的代码大概是这样：

// ToF相机配置为触发源
tof.setTriggerMode(TRIGGER_MODE_MASTER);
tof.setTriggerPin(GPIO_PIN_1);
tof.setTriggerPolarity(TRIGGER_RISING_EDGE);
tof.setTriggerInterval(33); // 30fps，约33ms一帧

// RGB相机配置为外部触发
rgb.setTriggerMode(TRIGGER_MODE_SLAVE);
rgb.setTriggerSource(TRIGGER_SOURCE_GPIO);
rgb.setTriggerPolarity(TRIGGER_RISING_EDGE);
rgb.setExposureTime(5000); // 5ms曝光

4.3 软触发方案：没有硬件怎么办？

说实话，不是所有设备都支持硬触发。有些USB摄像头根本没有GPIO引脚。这时候只能用软触发。

软触发的思路是：用软件指令同时启动两个相机的采集。但这里有个坑——你发指令的瞬间，两个相机不一定同时开始曝光。

4.3.1 软触发的实现方式

• 方法一：两个相机都设为「软件触发模式」，用一个线程同时调用trigger()
• 方法二：两个相机都设为「连续采集模式」，靠时间戳对齐
• 方法三：用外部微控制器（如STM32）发USB指令，同时触发两个相机

我曾经试过方法一，发现效果并不理想。为什么？因为两个trigger()调用之间，哪怕只差1ms，在高速运动下也会产生明显错位。而且USB的传输延迟是不确定的。

4.4 两种方案的对比

对比项	硬触发	软触发
同步精度	微秒级	毫秒级（有抖动）
硬件要求	需要GPIO引脚	普通USB即可
适用场景	运动物体、高精度	静态场景、原型验证
开发难度	中等（需要接线）	低（纯软件）
稳定性	高	受系统负载影响

4.5 我的建议

如果你问我个人怎么选，我的答案是：

• 量产产品：必须用硬触发。这是底线。
• 科研实验：如果场景是静态的，软触发够用。但记得做时间戳校准。
• 原型验证：先用软触发快速跑通流程，再换成硬触发优化精度。

嗯，这里还要补充一点。即使用了硬触发，也要做帧级对齐。因为ToF和RGB的帧率可能不同，比如ToF是30fps，RGB是60fps。这时候需要决定：是让RGB每两帧才触发一次，还是让ToF降帧率？我个人习惯让RGB跟随ToF的节奏，这样深度图和彩色图是一一对应的。

---

公众号:蓝海资料掘金营，微信deep3321