“M8内六角螺栓直径8毫米在1280×720的画面里也就占30多个像素。就是这30多个像素让我前面那套识别方案在产线上连续翻车漏检率一度爬到2%以上后面直接卡了一条装配线。项目名里的那个‘2’就是从这次翻车里长出来的——实时识别螺栓2本质上是一套针对紧固件小目标、高反光场景重新设计的视觉检测方案。”这套方案要解决的不只是“能不能认出螺栓”而是三件事叠加在产线节拍内完成识别、在金属强反光下保持稳定、在多规格混线时还能分清楚型号。如果你是做机器视觉的工程师、想在边缘设备上跑实时目标检测的开发者或者正被“小目标反光速度”这三座大山折磨这篇内容应该对你有用。下面写的内容来自我自己的项目复盘所有数据都来自模拟环境验证具体参数和配置只做思路参考别直接当成你们产线的验收标准。1. 为什么会有“实时识别螺栓2”v1版本的三个现场短板1.1 节拍不达标单帧推理时间拖了整条产线v1用的是通用目标检测模型直接在工控机上跑960×960输入单帧推理稳定在250毫秒左右。当时产线要求的节拍是单件120毫秒也就是说从相机抓图到PLC收到结果不能超过120毫秒。v1在最顺利的情况下也要180毫秒以上这还没算图像采集和通信的时间。节拍不达标带来的直接后果是产线要么降速运行要么堆料停机生产效率被砍掉将近一半。为什么v1会这么慢拆开看有三个原因。一是任务本身叠加了“识别多个规格螺栓区分方向”的需求模型参数不敢压太狠二是后处理NMS在候选框多的时候会吃掉不少时间三是采集软件用的是按帧轮询模式图像还没传完就开始做解码预处理CPU和GPU抢资源。这里面每一项单看都不是大问题但叠在一起就把延迟顶过了红线。v2在设计时列的第一条硬指标就是整链路单帧必须压到120毫秒以内最好留出20%余量。1.2 小螺栓漏检目标太小是原罪M6的螺栓头直径只有6毫米在镜头工作距离下投到传感器上也就是十几个像素。通用检测模型的neck和head设计对中等尺寸目标最友好对小目标天然不敏感。v1在验证集上的mAP看着有0.8但一统计小目标类别的召回率只有六成出头。产线上真正出问题的大多就是M6、M8这些小规格。这里要解释一个很多人忽略的点目标检测模型里的“小目标”问题不光是分辨率低更关键的是浅层特征图里的语义信息不足。模型的深层特征图负责识别“是什么”浅层特征图负责定位“在哪里”小目标几乎全靠浅层特征来撑。v1没有给小目标单独加监督网络训练时会把大部分注意力放在大目标上小螺栓在特征图里对应区域太小梯度贡献被大目标淹没。v2的第一个改动方向就是重新设计检测头把小目标监督单独提了一路。1.3 反光和运动模糊模型在图库上“分数虚高”离线验证的时候v1用的测试图库是专门去现场挑的“干净图”光源稳定、螺栓静止、背景没有杂物。结果一到现场就露馅金属螺栓头部的高反光让画面里有大块过曝区域螺槽的纹理特征被白光吞掉转盘上的螺栓还在缓慢移动拖出一点点运动模糊后边缘直接虚化。模型在这两类图上频繁出现漏检和误检抽检漏检率2.1%远超当初定的千分之一目标。这件事给我的教训是离线图库的“平均质量”完全不能代表现场的真实分布。v2从数据侧和算法侧同时做了干预数据侧是重新采集了一批带过曝和运动模糊的真实样本算法侧是加入了专门的抗干扰增强。后面会展开讲。2. 数据采集与标注螺栓识别的难点全在反光和细节2.1 光源和相机位姿先决定上限再谈模型金属反光是做视觉检测最头疼的问题之一而它恰恰可以通过硬件手段先缓解一大半。v2在打光上做了三件事把直射光换成低角度环形光让螺栓头边缘形成轮廓反差而不是镜面反射在镜头前加偏振片过滤掉大部分镜面反射光相机曝光时间从常用的5毫秒压到1毫秒以下避免亮部过曝。这三件事的效果立竿见影。镜头前的偏振片一加画面里原来白花花一片的螺栓头部立刻露出了螺槽和边缘纹理。你可能觉得这是“传统视觉”的思路和目标检测没关系但恰恰相反——深度学习模型对输入图像质量的下限要求其实很高光源调好了训练出来的模型稳定性会明显上一个台阶。这里有个很实用的建议采集训练数据的时候刻意把光源开成高中低三档每种档位都拍一批让模型见过不同亮度条件下的螺栓。这样上线后即使光源控制器漂移模型也不会立刻崩。相机位姿方面我踩过一个坑只用一个垂直俯拍视角采集数据模型确实在这个视角下检测很好但产线调试时稍微调了相机支架的倾斜角检测率直接掉了一截。v2补了三种视角的数据垂直俯拍、45度斜拍、侧面低角度拍。如果你的工位相机角度已经固定至少也建议拍两组不同角度的数据做测试验证一下模型的位姿鲁棒性。2.2 标注要避开的三个坑标注是数据质量的地基但螺栓这个场景有它的特殊性。第一个坑是水平框在螺栓斜置时框进太多背景。螺栓头是圆的斜着停的时候水平标注框的四角会落到背景板上模型训练时会把这些背景特征学进“螺栓”的语义里。v2的折衷方案是对正常位姿的样本用紧密水平框对斜置样本和部分遮挡样本先用裁剪放大的预处理再标注而不是直接在原图上硬拉一个大框。第二个坑是模糊样本别硬标。一张已经运动模糊到看不清螺栓槽型的图你凭经验标注了模型就会学到一个“错误的模板”在清晰图上反而容易误判。v2的原则是模糊样本要么放到专门的分桶里做弱监督要么直接丢掉不要混进主训练集。第三个坑是空背景样本被忽略。很多项目只标“有螺栓的图”完全不拍空背景。这会导致模型在没有任何螺栓的背景板上也强行给出检测框误报率偏高。建议每个场景至少拍5%到10%的空背景图标签为空让模型学会“这里什么都没有”。2.3 数据增强真正见效的三个操作螺栓检测里通用增强操作很多HSV扰动、随机裁剪、翻转、旋转都有用但实测下来最容易解决现场痛点的是三个。第一是模拟过曝增强随机把图像亮度拉高并压缩高光区域细节训练模型在反光下的抗性第二是运动模糊增强用随机方向和高度的模糊核处理图像对应转盘运动导致的拖影第三是对小目标做细节保留标准随机裁剪会频繁把螺栓主体裁掉一半让模型学到错误的局部模式。v2的增强策略是对标注目标较小的情况先用随机缩放在整图内重贴再裁剪保证每个批次里都有足够多的小目标正样本。这三个增强看起来简单但它们直接影响的是模型在“反光、模糊、小尺寸”这三个崩溃点上的表现。当时模型加了这三项之后现场漏检率从2.1%往下掉到了0.5%附近大家都松了一口气。3. 模型选型与训练调参速度精度平衡的一次系统性实践3.1 选型逻辑从通用检测器到轻量级检测的取舍v1直接套用了当时通用检测器里精度最高的那一档事实证明在产线节拍面前走不通。v2选型时列了个对比表把备选方案分了三类大型通用检测器、中等规模轻量检测器、传统视觉分类器组合。大型检测器精度确实高但推理时间普遍在200毫秒以上直接出局。传统视觉方案在干净场景下速度快可一旦过曝或背景变化鲁棒性完全扛不住也放弃了。最后选定的是中等规模的轻量级单阶段检测框架配一个专门加强的小目标检测头。选它的理由有三条一是单阶段结构天然比两阶段快二是这类框架的预训练权重在公开数据集上经过考验迁移到螺栓场景上手容易三是社区开源工具链成熟导出到推理加速框架的坑少。这最后一条在工业部署里非常重要一个模型在训练集上跑得再准如果推理框架不支持它的算子上线阶段会把人折磨死。3.2 小目标漏检怎么治特征层和损失函数的具体改动v2在检测头里加了一条浅层特征输出专门负责小尺寸目标的检测。模块层面其实不复杂但训练时有两个细节必须注意。一是浅层特征图的通道数不能贪多否则推理阶段计算量飙升v2反复试下来在速度可接受的前提下选了前两层的特征拼接。二是训练时对小目标分支单独设置权重让它在整体损失里的占比不随batch变化被稀释。我习惯的做法是统计每个batch里小目标的个数动态放大它们对应的损失系数。损失函数这边v1用的标准边框回归损失在高宽比收敛时总是不太稳定。v2换成了带几何匹配的损失函数SIoU这类核心改进是把预测框和真实框的宽高比惩罚项加进去解决螺栓这种窄长目标在回归时“横竖不分明”的问题。改完之后检测框的位置抖动明显减少尤其是内六角螺栓的六边形轮廓定位更准了。这里补充一个训练策略先用公开预训练权重在低分辨率下微调50轮让模型先学会提取通用特征再切到目标分辨率继续训练80轮最后把浅层小目标分支unfreeze用更低学习率精调20轮。三个阶段的思路是“先学得会再学得准最后学得细”。这套流程比一步到位直接跑几百轮稳定得多。3.3 训练评估mAP只是起点现场漏检率才是终点不少团队在模型迭代时只看mAP曲线这是一个典型的误区。mAP是多个类别、多个IoU阈值下的综合平均一个螺栓类别识别得很差只要另一个大类识别得好mAP也可能拉高。v2的评估体系加了三个更细的指标小目标类别单独统计的召回率RecallSmall、重叠度高阈值下的检测框定位精度mAP0.5:0.95、以及模拟现场光照和运动模糊条件下的“场景抽检漏检率”。在v2的迭代过程中后面这个“场景抽检漏检率”帮了大忙。模型在标准测试集上mAP已经接近0.9了但换到过曝增强的验证子集里漏检率还是偏高。因为这个指标单独被卡住团队才沉下心来补了光源偏振和增强策略而不是提前上线。建议你的项目也把“最接近现场条件”的验证子集做成固定测试集每次迭代都盯住它这比盯着mAP曲线有用得多。3.4 训练阶段踩过的两个坑第一个坑是类别不均衡。产线上M10螺栓的数量远大于M6小螺栓常规采样训练时模型几乎被M10的样本“带跑”对M6的检测头分支没有准确的梯度更新。解决办法是类别加权采样每个batch里让各类别数量大致均衡而不是按真实分布。第二个坑是标注噪声。人工标注的框和螺栓真实边缘之间经常有一两像素的错位训练时模型被迫在这些噪声上反复拟合损失曲线容易出现“阶段性平台”。v2后来加了一道标签清洗流程统计每个标注框和周围样本的一致性偏差过大的框重新人工核对。清理一圈之后同样的训练配置下mAP又涨了近两个点。4. 实时性优化从单帧快跑到全链路低延迟4.1 推理侧的四板斧量化、剪枝、固定shape、NMS简化实时性优化的第一站是推理本身。v2的模型在PyTorch里裸跑大概是110毫秒经过四步改造压到了58毫秒。第一步是把模型导出为通用推理加速框架的格式并开启半精度推理因为螺栓检测任务对数值精度不敏感半精度损失几乎可以忽略但速度能提升约三成。第二步是剪枝——模型的网络里有些卷积核通道对输出贡献非常小按权重幅值和激活统计剪掉了一部分冗余通道模型体积小了约20%。第三步是固定输入shape。很多推理框架在动态尺寸下会频繁重新分配内存和调度kernel固定成640×640或1280×1280之后显存分配稳定了推理延迟也低了。这里有个细节推理建议如果螺栓宽度固定优先用1280×1280的分辨率配合固定shape小目标召回率的提升很明显如果节拍更紧再用640×640求速度。第四步是简化NMS把按类别分别执行的NMS合并成一个类别无关的全局NMS候选框数量多的时候省出的时间非常可观。4.2 相机、采集、处理全链路时延拆解很多人只优化模型推理时间却忽略整条链路的延迟。v2上线前做了一次完整的时延拆解数据大致是这样的环节耗时说明相机曝光2ms压到最短配合偏振光源图像传输8ms千兆网口传输避免丢帧解码与预处理5msGPU上做resize和归一化不走CPU模型推理58ms半精度剪枝固定shape后NMS后处理3ms全局NMS按得分截断结果通信输出2ms以标准协议发给下位机合计78ms节拍120ms留出约35%余量这个表做完全团队对痛点一目了然模型推理占大头其他环节加一起才20多毫秒。即便后续需要增加更复杂的识别逻辑余量也足够撑住。强烈建议你在做类似项目时先做一次全链路时延拆解别只盯着模型。4.3 触发式识别和状态机过滤避免每帧做全套决策产线画面里大部分时间是“转盘转到下一工位没有螺栓”或者“螺栓在移动中”如果每帧都跑一次完整推理算力浪费很大。v2在采集端加了光电传感器触发模式只有螺栓运行到指定拍照位置时才触发相机抓帧其他时间相机休眠。单线工况下这直接把平均功耗和发热降了下来。如果还是遇到连续帧场景建议搭配状态机而不是每帧独立判断。v2里用了一个“两帧确认、连续三帧不确认才告警”的规则第一次检出时先作为候选下一帧再次检出且位置变化在合理范围内才正式输出结果连续丢了两帧也不急着报漏检第三帧若重新检出则自动恢复。这套机制显著降低了偶发的误报和抖动导致的漏判代价是逻辑复杂度变高但换来的是现场稳定性。5. 部署到产线干扰处理、结果闭环和现场避坑5.1 选工控机和模型导出时的注意点选硬件时不必盲目追求高端芯片关键看两件事推理加速框架的支持度以及I/O接口的齐全度。v2用的是一台无风扇的工控机配上边缘级显卡在1280×1280输入下半精度推理跑到了前述的58毫秒。如果你用纯CPU也未必跑不动但建议输入降到640×640并测量实际节拍再做决定。模型导出有个很实际的经验导出前把输入尺寸和batch size固定推理框架里很多算子会针对固定shape生成专用kernel性能差异可能在10%到20%之间。另外导出来的模型不要只在本地跑一次验证就完事一定要在目标设备上跑一段长时间压力测试因为工业场景下长时间运行引发的显存泄漏和微小的资源碎片问题在短测试里根本看不出来。相机选型方面优先选全局快门的工业相机避免卷帘快门在运动场景下产生果冻效应。镜头要固定焦距、手动光圈装配后即锁定不要用自动光圈镜头它在产线亮度变化时会自行调整曝光直接干扰识别稳定性。5.2 现场三大干扰反光、震动、背景杂物偏振镜加上低角度光源之后反光问题基本可控。万一还有残余高光另一个通用技巧是“两次曝光融合”同一位置拍短曝光和长曝光两张图做HDR合并后输入模型。这个方法在强反光场景下很有效代价是吞吐量减半适合节拍不那么紧的工位。震动问题在小螺栓识别里会被放大——画面轻微抖动螺栓边缘就模糊了。v2的做法是给相机支架加了橡胶减振垫同时把相机帧率提到最高用连续多帧中质量最好的一帧做判断。背景杂物则靠划定ROI区域来处理让模型只关注工作窗口转盘上的其他金属零件不会进入检测范围。5.3 结果怎么反馈给PLC和执行机构模型输出的是“螺栓所在位置和类别”但要真正驱动产线还要把结果变成控制信号。v2通过标准工业通信协议把检测结果队列发给下位机包含工位号、检测时间、类别置信度、检测框的像素坐标和“OK/NG”标记。下位机收到NG信号后按预设逻辑执行分流或者停机。通信这一层最容易踩的坑是延迟抖动v2用循环缓冲和超时重传机制来规避确保PLC侧拿到的不是过期数据。报警逻辑这里我想多说一句不要单帧NG就立刻停机。螺栓在运动状态下一帧识别失败是正常现象v2设了个“连续N帧未检出且置信度低于阈值才触发停机”的规则N根据产线节拍和停机成本来调。这个规则有效避免了大量误停但在安全性要求极高的位置需要评估有没有出现过漏报未拦截的风险再决定是否调整。6. 实测指标对比与下一步可以做的扩展6.1 从v1到v2的指标变化拿v2在模拟产线条件下的实测表现来对比整个系统的改进一目了然指标v1v2单帧推理耗时260ms58ms整链路耗时380ms78msmAP0.50.780.93小目标类别召回率0.610.88现场抽检漏检率2.1%0.12%误报率1.8%0.37%单看mAP涨幅似乎不算大但真正关键的是现场抽检漏检率从2.1%降到了0.12%这一档。这再次印证了脱离现场条件谈mAP没有意义数据采集、光源改善和增强策略的工程优化对产出质量的影响往往比模型结构本身更大。6.2 这个方案还可以怎么扩展v2完成之后后续还有几个明确可做的事。第一是从2D识别延伸到六维位姿估计加一个回归头输出螺栓头部的平面旋转角和倾斜方向这样可以给装配机器人提供抓取角度意义比单纯识别大得多。第二是和拧紧工具联动视觉确认螺栓是否到位后直接把结果传给拧紧枪控制器形成一个“识别-拧紧-复检”闭环。第三是多工位相机联动把几个工位的识别结果汇总到统一中台做整线级别的质量统计。这几个方向都建立在同一个前提上当前的实时识别链路已经稳定才有余量去叠加更复杂的感知逻辑。最后说点个人体会。做这类识别项目我最深的感受是模型只占一半另一半是数据、光源和工程管线。如果你正在复现类似的方案给你一个最实际的建议先把现场的光源调好再回头调模型。光源不行后面再好的模型都在补数据缺陷。另一个小技巧是把验证集里故意塞入一批过曝和运动模糊的图每次迭代都盯着这批图看它能提前暴露你上线后才会遇到的坑比什么指标都管用。
