3、同步触发原理：硬件触发（GPIO、外部信号）与软件触发（API指令）的区别与适用场景

做双目相机采集，最头疼的问题是什么？

我告诉你，不是分辨率不够，也不是帧率太低。而是——左右眼拍到的画面，到底是不是同一时刻的？

哪怕差了几毫秒，运动物体的位置就会错位。三维重建出来的点云，直接就是歪的。所以，同步触发这件事，是双目系统的命门。

今天我们就来聊聊两种触发方式：硬件触发和软件触发。它们各自怎么工作？什么时候该用哪个？我踩过的坑，也一并告诉你。

3.1 软件触发：最直接，但别太信任它

软件触发，说白了就是你在代码里调用一个API指令，比如 camera.start_capture() 或者 camera.trigger_once()。操作系统收到指令后，通过驱动程序告诉相机：“现在，开始拍！”

听起来很简单对吧？但问题就出在这个“告诉”的过程上。

延迟是不确定的。

你想想看，你的Python代码跑在用户态，中间要经过解释器、操作系统调度、USB/以太网驱动……这一层层下来，延迟可能从几毫秒到几十毫秒不等。更糟糕的是，如果系统正在忙别的事（比如写日志、处理网络请求），这个延迟会更大。

我记得有一次，我在一个工控机上跑双目采集。软件触发，左右相机各用一个线程。结果发现，左右图像的时间戳差了将近30毫秒。一开始我还以为是相机时钟不同步，后来用示波器一量——好家伙，两个触发信号本身就有20多毫秒的相位差。

软件触发适合什么场景？

• 静态场景：拍摄静止的物体，比如拍一张电路板、拍一个零件。左右相机差几毫秒没关系，反正物体没动。
• 低帧率需求：比如每秒只拍1-2帧，系统负载不高，延迟抖动相对可控。
• 原型验证：刚开始做算法验证，先跑通流程再说。软件触发最方便，不用额外接线。
• 多相机不需要严格同步：比如两个相机各自拍不同的场景，不需要对齐时间戳。

3.2 硬件触发：用一根线，搞定所有问题

硬件触发，就是直接用一根物理信号线（GPIO、TTL电平、光耦隔离信号等）连接外部触发源和相机。触发源可以是PLC、运动控制卡、编码器，甚至是一个简单的按钮。

信号来了，相机就拍。没有操作系统调度，没有软件延迟。信号从触发源到相机传感器开始曝光，延迟通常只有微秒级，而且抖动极小。

硬件触发的典型接线方式：

触发源（PLC/编码器）  ——>  左相机 Trigger In
                       ——>  右相机 Trigger In
                       ——>  示波器（用于监测）

注意，这里的关键是：左右相机的Trigger In要并联在同一根信号线上。这样，同一个上升沿信号会同时到达两个相机。理论上，它们的曝光开始时间是完全一致的。

但“理论上”和“实际上”之间，还有几个坑。

硬件触发适合什么场景？

• 高速运动物体：比如传送带上的产品检测、机器人抓取。需要精确到微秒级的同步。
• 多相机系统：3个、4个甚至更多相机同时拍摄。软件触发根本搞不定，必须用硬件信号同步。
• 与外部设备联动：比如PLC控制相机在特定位置拍照。PLC输出一个脉冲，相机就拍一张。
• 高可靠性要求：医疗、军工、自动驾驶等领域，不允许有任何一次触发失败或延迟。

3.3 两种触发方式的对比

3.4 核心逻辑：一张图看懂

下面这张图，是我自己总结的触发方式选择逻辑。每次做新项目，我都会先过一遍这个流程。

3.5 实际项目中的选择建议

我个人的习惯是：只要条件允许，优先用硬件触发。

为什么？因为硬件触发带来的确定性，能让你少排查很多莫名其妙的bug。你想想看，如果图像同步出了问题，你是愿意花一天时间查代码、查线程调度、查USB驱动，还是花半小时接一根信号线？

当然，硬件触发也有它的麻烦：

• 需要额外的IO线缆。如果相机距离触发源很远（比如10米以上），信号可能会衰减，需要用差分信号或者光耦隔离。
• 触发频率受限于相机的最短曝光时间。比如相机最短曝光时间是10微秒，那触发信号的间隔就不能小于这个值，否则相机反应不过来。
• 有些廉价相机不支持硬件触发。买相机之前，一定要确认规格书里有没有“Hardware Trigger”或者“External Trigger”这个功能。

嗯，关于触发原理，今天就聊到这里。下一节我们实际动手，看看怎么在代码里配置这两种触发模式，以及如何用示波器验证同步效果。