3、图像采集稳定性：触发模式与同步、帧率控制、缓存机制、丢帧检测与处理、多相机同步采集
图像采集，是整个视觉系统的「第一道关卡」。
我见过太多项目，算法模型调得再准，最后栽在采集环节。图像没采好，后面全是白搭。说白了，采集不稳定，你连「错」的机会都没有。
这一节，我们聊聊怎么让相机老老实实地、稳定地、不出岔子地把图像交到你的手里。
3.1 触发模式与同步：别让相机「自由发挥」
相机采集有两种模式：内触发和外触发。
内触发，就是相机自己按固定频率拍。适合流水线上匀速运动、光照稳定的场景。但一旦物体速度变了，或者来了个急停，内触发就抓瞎了——你想想看，物体没到位，相机「咔嚓」一张空图，浪费带宽还占内存。
外触发，才是工业场景的标配。传感器、PLC、编码器给一个脉冲，相机才拍。这样能保证「物体到了才拍，没到不拍」。
核心原则：能用外触发，就别用内触发。除非你的场景极其稳定。
同步问题，我踩过坑。有一次做锂电池检测，两个相机拍同一个电池的正反面，结果因为触发信号没对齐，正面拍的是第100个电池，反面拍的是第101个。你说这数据怎么对齐？
解决办法：所有相机共享同一个触发源，或者用同一个编码器信号分路。硬件上要保证信号延迟一致，别一个走长线、一个走短线。
3.2 帧率控制：不是越快越好
很多人觉得帧率越高越好。其实不是。
帧率高了，数据量就大。CPU/GPU处理不过来，缓存爆了，就开始丢帧。你想想看，你每秒采了100帧，但只处理了30帧，那70帧去哪了？丢了。
我个人习惯：帧率 = 处理速度 × 安全系数。比如你的算法每秒能处理25帧，那相机就设20帧，留点余量。别把系统跑在极限上。
| 场景 | 推荐帧率 | 说明 |
|---|---|---|
| 高速运动物体（如药片检测） | 60-120 fps | 配合外触发，只拍有效帧 |
| 中速流水线（如电子元件） | 20-30 fps | 连续采集，缓存要够 |
| 静态或低速场景 | 5-10 fps | 降低带宽占用，减少发热 |
小技巧：如果必须用高帧率，可以考虑「跳帧处理」——采集全帧，但只处理关键帧。比如每3帧处理1帧，其他帧只做缓存或丢弃。
3.3 缓存机制：给数据一个「缓冲区」
相机采集的数据，不会直接送到算法手里。中间必须有个缓存区。
为什么？因为采集是实时的，但处理不是。处理可能卡一下，或者某个帧特别复杂，耗时长了。如果没有缓存，处理卡住的时候，新来的数据就把旧数据覆盖了——丢帧。
我建议用环形缓冲区（Ring Buffer）。它像一个循环队列，采集线程往里面写，处理线程从里面读。只要读的速度平均上能跟上写的速度，就不会丢帧。
// 伪代码示例：环形缓冲区
#define BUFFER_SIZE 16
Image buffers[BUFFER_SIZE];
int write_idx = 0, read_idx = 0;
// 采集线程
void capture_thread() {
while (1) {
buffers[write_idx] = grab_image();
write_idx = (write_idx + 1) % BUFFER_SIZE;
// 如果写指针追上了读指针，说明缓存满了
if (write_idx == read_idx) {
// 丢帧了！需要处理
handle_overflow();
}
}
}
// 处理线程
void process_thread() {
while (1) {
if (read_idx != write_idx) {
process_image(buffers[read_idx]);
read_idx = (read_idx + 1) % BUFFER_SIZE;
}
}
}
注意：环形缓冲区的大小要合理。太小了容易溢出，太大了浪费内存。我一般设成处理延迟的2-3倍。比如处理一帧平均要50ms，那缓冲区至少能存3帧，也就是150ms的数据量。
3.4 丢帧检测与处理：别等出了问题才发现
丢帧是不可避免的。但你不能让它「静默地」发生。
我曾经在一个项目中，相机偶尔丢一帧，但系统没报错。结果产线跑了三天，发现产品检测结果和实际对不上。查了半天，才发现是丢帧导致的数据错位。
从那以后，我养成了一个习惯：每个采集循环都检查帧序号。
// 丢帧检测示例
uint64_t last_frame_id = 0;
void on_frame_capture(Frame* frame) {
uint64_t current_id = frame->frame_id;
if (current_id != last_frame_id + 1) {
// 丢帧了！
uint64_t lost_count = current_id - last_frame_id - 1;
log_warning("丢帧 %d 帧，从 %d 到 %d", lost_count, last_frame_id, current_id);
// 处理策略：重采？忽略？报警？
if (lost_count > MAX_ALLOWED_LOST) {
trigger_alarm("丢帧过多，系统异常");
}
}
last_frame_id = current_id;
// 正常处理...
}
丢帧后的处理策略，取决于你的应用：
- 关键检测场景（如医疗、安全）：丢帧就报警，产线停机，人工介入。
- 非关键场景（如统计计数）：丢帧就丢了，记录日志，继续跑。
- 数据对齐场景（如多相机）：丢帧必须重采，否则数据对不上。
我的经验：丢帧检测一定要放在采集线程里，不要放在处理线程里。因为处理线程可能本身就慢，等它发现丢帧，黄花菜都凉了。
3.5 多相机同步采集：让所有相机「步调一致」
多相机同步，是视觉系统里最头疼的问题之一。
你想想看，两个相机拍同一个物体，一个拍早了10ms，一个拍晚了10ms。如果物体在运动，那两张图里的物体位置就不一样。做3D重建、拼接、或者比对，全都会出错。
同步方案，我按难度排个序：
- 硬件触发同步（最简单）：所有相机接同一个触发信号。信号同时到达，同时曝光。延迟差异在微秒级，基本可以忽略。
- PTP（精确时间协议）同步：通过以太网同步时钟。适合分布式相机，精度在亚微秒级。但需要相机和交换机都支持PTP。
- 软件时间戳同步（最不推荐）：每个相机自己记时间，事后对齐。精度差，依赖网络延迟，我一般不用。
避坑指南：我曾经用软件时间戳做多相机同步，结果两个相机的时钟漂移不一样，跑了半小时就差了100ms。后来老老实实换了硬件触发，问题解决。记住：能用硬件，别用软件。
多相机同步还有一个细节：曝光时间要一致。如果A相机曝光10ms，B相机曝光20ms，那即使触发信号同时到，B相机的结束时间也比A晚10ms。对于运动物体，这10ms的差异足以让图像模糊或位置偏移。
嗯，图像采集稳定性这块，说白了就是「让相机听话」。触发要准、帧率要稳、缓存要够、丢帧要查、多机要同步。每一步都做到位了，你的视觉系统才算有了一个靠谱的「眼睛」。