YOLOv5+PLC：汽车产线错漏装检测系统完整拆解

简介《基于机器视觉技术的汽车制造零件检测系统》是一份面向汽车制造、工艺工程与工业视觉检测领域的技术论文针对多车型混线生产中因人工检查疲劳导致的零件错装、漏装问题提出了一套低成本、高准确率的视觉检测方案。作者围绕YOLOv5s算法详细介绍了数据样本采集与降噪、模型训练、准确率与召回率评估以及通过Python Snap7与西门子PLC通信、获取车辆实时车速和位置信息、调用OpenCV进行图像预处理的完整实现流程同时提及改进YOLOv3在同类零件识别中的应用兼顾算法原理与产线落地细节。整个资源包仅含1个PDF文件体积约1.08MB全文页面紧凑查看方便。适合智能制造研究人员、产线工艺工程师以及目标检测算法学习者阅读可快速了解机器视觉在整车制造防错漏装中的典型应用路径。目前已有212人学习/下载其系统集成思路与实测数据对同类产线的数智化改造具有参考价值。1. 机器视觉技术在汽车产线能替代什么一套YOLOv5检测系统的完整拆解整车厂产线上最怕的不是设备故障而是错装漏装。一辆乘用车要装上万件零件混线生产时车型配置来回切换人工终检靠眼睛盯看久了难免走神酒精管道插头、胶堵这类小件藏在结构深处等发现问题往往已经造成返修甚至停台。王金成和刘兴在《汽车工艺与材料》2023年第7期提出的这套方案思路很直接用普通网络摄像头拍照用YOLOv5s做目标识别再通过PLC和RFID确定车辆到站位置与底盘号用Python、OpenCV把流程串起来。11类易错装零件、11个独立模型准确率和召回率均在98%以上实际识别准确提醒概率超过99%半年把漏检返修从每年240次压到只剩1次。不用换高端设备一套低成本视觉检测系统就把人工终检的活接了下来。2. 系统整体架构与关键选型为什么是YOLOv5s、PLC和RFID这套组合2.1 选型逻辑11类零件为什么要用YOLOv5s而不是大模型YOLOv5家族有s、m、l、x四个档位网络规模依次变大、精度变高、速度变慢。项目里选的是最小的YOLOv5s不是拍脑袋。车间线体有节拍约束车辆经过拍照工位到判定完成之间的时间窗口很短模型推理速度直接决定系统能不能在线运行。YOLOv5s在网络最小的情况下速度最快对门槛亮条、尾标、胶堵这类特征相对规整、类别数量只有11种的零件来说精度余量完全够用。更值得关注的是训练组织方式系统没有把所有零件塞进一个大模型而是每类零件单独训练一个模型一共11个。这种“一零件一模型”的做法有实际好处。第一每类零件的样本可以独立采集、独立标注互不干扰第二新增零件不需要把旧模型推倒重来只加一个新模型第三部署时可以按车辆配置信息只加载该车型需要的模型节省推理时间。产线场景里零件更换迭代是常态这种增量式建模在工程上要灵活得多。2.2 五大模块的职责与数据流整个系统拆成图像采集、车辆配置信息获取、车辆信息采集、图像识别、系统报警五个模块。图像采集由OpenCV基于RTSP协议调用普通网络摄像头完成拍照后做降噪、灰度处理和尺寸归一化车辆配置信息获取模块用pymssql从SQL Server的FIS服务器读取车型和配置代码车辆信息采集模块的关键是Python-Snap7与西门子S7-300系列PLC实时通信拿到车辆到达信号图像识别模块用迁移学习训练好的YOLOv5s模型判断安装状态报警模块负责把异常结果推到语音屏和钉钉。数据流是这样的RFID阅读器从吊具标签读到底盘号存入PLC的DB块Snap7把底盘号读出来写进MySQL程序判断底盘号变了就触发OpenCV拍照识别结果再次写入MySQL语音屏按车辆信息实时查询结果异常则语音播报和钉钉报警。这套链路里PLC不参与图像处理只负责“告诉系统车来了”这就把工控星和算法星解耦了两边可以独立升级。2.3 车辆信息采集节点Snap7读取PLC DB块的实现先说代码再解释参数。论文里明确写了用Snap7的read_area函数读取S7-300系列PLC的DB块常见实现是下面这样from snap7 import client, types # 连接S7-300 PLC参数分别是IP、机架号、槽号 plc client.Client() plc.connect(192.168.1.10, 0, 1) # 读取DB块数据区域为DB、DB号为10、起始字节偏移0、读取16字节 db_number 10 data plc.read_area(types.Areas.DB, db_number, 0, 16) # 返回的是字节数组需要按PLC程序里的变量定义解析 print(data.hex()) plc.disconnect()read_area的四个核心参数分别是区域、DB号、起始地址、读取长度。车间现场用的是S7-300系列DB块里的变量布局完全取决于PLC工程师写的程序。比如底盘号存在DB10.DBW0还是DB10.DBD4直接决定start参数填0还是4。我一般建议先在TIA Portal里打开对应DB块确认底盘号的实际偏移后再写代码不要照抄示例就上产线。Snap7连接时的rack和slot参数也要和组态一致S7-300常用的是0架1槽但挂分布式IO后会变连不上先查这两个值。2.4 图像识别与报警衔接从识别结果到钉钉提醒识别结果落到MySQL后需要把异常信息推到操作人员手上。论文的做法是手机钉钉报警和线尾语音屏双通道。钉钉这边用自定义机器人Webhook本质是向一个HTTP地址POST JSON数据import requests import json # 钉钉自定义机器人Webhooktoken由群机器人创建后生成 url https://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKEN payload { msgtype: text, text: { content: QRK1线检测异常车辆VIN XXXXX门槛亮条识别为缺装请确认 } } headers {Content-Type: application/json} resp requests.post(url, datajson.dumps(payload), headersheaders) print(resp.status_code, resp.text)这段的逻辑就是向钉钉服务器发一个HTTP POST请求消息体里必须用msgtype字段声明消息类型。要注意钉钉自定义机器人的安全设置如果开启了“加签”模式请求头里就必须带timestamp和sign参数否则接口会返回“token不存在”或“签名不匹配”。关键词模式相对简单只要消息内容包含设置的关键词就能发出去建议在content里固定写入工位编号像“QRK1”这种既方便排查又满足机器人关键词限制。语音屏那一路则是通过Vue.js和Node.js搭建显示界面在线尾按底盘号实时查询识别结果异常时语音合成播报操作员不确认就一直报警。3. 数据样本与模型训练从网络摄像头到98%精确率的完整参数3.1 样本采集与预处理现场摄像头不是接上就能拍数据样本完全来自现场实际工况这是这套系统能落地的第一道门槛。系统测试车间是多车型混线生产不同车型配置不同所以训练集和测试集的划分要按零件实际出现过的情况来准备不能简单随机切分。摄像头本身和信号传输都会带来干扰图像里经常出现高斯噪声和椒盐噪声体现为影响判断的黑白像素点。论文采用的是OpenCV的cv2.blur()均值滤波函数处理核大小取的是经验值import cv2 # 打开网络摄像头RTSP流 cap cv2.VideoCapture(rtsp://user:passwordcamera_ip:554/stream) ret, frame cap.read() if ret: # 均值滤波核大小(15, 5)用于去除高斯噪声和椒盐噪声 denoised cv2.blur(frame, (15, 5)) # 统一缩放到640x640满足YOLOv5输入尺寸 resized cv2.resize(denoised, (640, 640)) # 归一化到0-255范围保持像素分布稳定 normalized cv2.normalize(resized, None, 0, 255, cv2.NORM_MINMAX) cv2.imwrite(capture.jpg, normalized) print(图片已保存)cv2.blur的核大小(15,5)是个值得记的参数。核选大了图像会明显变糊零件边缘和字符细节跟着丢失选小了椒盐点去不干净。现场光线稳定、摄像头固定的场景下宽向15、高向5的非对称核既能压掉传输噪声又不至于把胶堵这类小目标的轮廓抹平。归一化的作用是把像素值压到统一区间防止光照变化让同一零件在不同时段拍出明暗差异很大的图。全部图片统一到640×640后再交给模型这也是YOLOv5系列的标准输入尺寸。3.2 标注与样本组织Labelimg标注与11个模型的数据分布标注工具用的是Labelimg业内最常用的开源标注工具。每张图框出目标位置和类别输出YOLO格式的txt标注文件。每个零件单独一个模型意味着要准备11份数据集每份数据集有独立的训练集和测试集划分。从论文的表1能看出数据量分布很不均匀门槛亮条训练集有3700多张左侧裙只有282张这种差异直接体现在模型精度上。零件训练图片数测试图片数精确率(IOU0.5)门槛亮条37227120.98917酒精罐插头36003030.98822尾标logo6969310.99977左侧裙2823350.99864侧标13813060.99909这里能看出两个信息。第一所有模型的精确率都在0.988以上整体满足产线质量要求第二样本量少的左侧裙精确率反而到了0.99864说明在零件特征明显的前提下两三百张图也能训出可用的模型。真正限制精度的不是样本数量绝对值而是类内差异有多大。尾标logo这类带复杂图案的零件样本量不足时容易把不同配置的标志判错反而需要更多图片来覆盖变化。完整的数据分布表在论文的表1里做同类项目的可以直接拿来参考建模。3.3 训练参数配置学习率0.01、weight decay 0.0005、epoch 300训练阶段的关键参数论文写得非常明确适合直接照抄再按自己环境微调。初始学习率0.01weight decay设0.0005batch size是64训练300轮。这个组合在零件检测场景下是合理的起点YOLOv5自带的学习率调度会随epoch衰减。给出典型的训练命令# YOLOv5官方训练命令按项目路径修改 python train.py --data part_data.yaml \ --weights yolov5s.pt --img 640 \ --batch-size 64 --epochs 300 \ --lr0 0.01 --weight-decay 0.0005--lr0是初始学习率0.01在YOLOv5里偏大适合数据量中等、目标特征明显的场景训练初期loss下降快后面靠调度器降下来收敛。--weight-decay是权重衰减系数防止参数过大导致过拟合0.0005是YOLOv5官方推荐的默认值。--batch-size 64需要足够的显存我自己的经验是单张消费级显卡跑不满64常见做法是降到16或32同时把学习率按比例调低比如batch 16时lr0改0.002左右否则loss会震荡。训练环境论文给的是PyTorch 1.8.0、Python 3.8、Windows 10这套组合跑YOLOv5s没有问题。3.4 评价指标与模型效果精确率、召回率和IOU阈值0.5论文把精确率和召回率作为模型好坏的最终评价指标IOU阈值固定在0.5。IOU是预测框和真实框的重叠程度阈值0.5意味着重叠超过一半才算正确检出。阈值定高了检测框稍微偏一点就被算成误检召回率掉下来定低了框得不准也能通过精确率注水。0.5是目标检测领域最常用的平衡点论文里的11个模型都按这个口径评估精确率均在0.988以上召回率也在可接受范围内说明系统对漏装和错装都能给出稳定响应。数据库设计也值得一提。系统使用MySQL 8.0.1论文表2列出了13张表命名规律非常清晰A402_qrk1_visual_realtime、A403_qrk1_visual_history这类是实时结果和历史记录A405_qrk1_visual_dispose是处置记录A408_qrk1_visual_plc保存PLC读取数据A430_qrk1_image_history存储图片路径。表名按工位号、区域、功能分段用VIN和底架号做关联字段。这样设计的好处是查问题的时候按工位前缀就能定位到对应数据表不用在一个大表里翻来翻去。语音屏按底盘号查实时结果查不到就持续报警等待人工确认逻辑简单可靠。4. 现场落地的常见问题与排查噪声、漏拍、报警与模型迭代4.1 图像噪声引发误检均值滤波核大小怎么定现象模型把背景里的反光点、地面杂物当成目标零件误检率偏高。实际表现是某个零件明明装好了识别结果却提示缺装。原因网络摄像头通过RTSP传流信号在传输链路里被干扰图片上出现黑白像素点。论文明确说这种噪声高斯和椒盐两种都有直接喂给模型特征提取时容易被这些假像素带偏。解决在拍照后立刻做均值滤波。cv2.blur的核大小要先从(15,5)起步如果噪声点还明显就往大调比如(21,7)如果零件边缘明显发虚说明核大了减小一个方向。这个参数要对着现场实际抓图调不能靠猜。4.2 混线生产时漏拍底盘号比对是关键现象线体上车型切换后某台车没有触发拍照导致识别流程被跳过车辆带着潜在问题直接流到下一工位。原因系统触发逻辑是“底盘号变化才算新车到站”如果PLC DB块里的底盘号没有被正确刷新或者MySQL里存的上一条记录已经是最新程序会误以为还是同一台车不执行拍照。解决严格按论文步骤2的逻辑走每次从MySQL取到的新底盘号都要和识别数据库里的编号做比对不一致才认定是新车辆。排查时先看A408_qrk1_visual_plc表里的底盘号有没有更新没更新就是Snap7读取链路的问题优先检查PLC DB块地址和RFID阅读器状态。4.3 钉钉报警收不到Webhook配置和加签模式现象系统判定缺装语音屏也播报了但钉钉群没有任何消息。原因钉钉自定义机器人有安全设置如果群里同时开启了关键词和加签直接在POST请求里塞文本是不够的需要额外计算签名把timestamp和sign拼到请求头里。解决先在机器人设置里确认是关键词模式还是加签模式。关键词模式让消息内容必须包含指定词例如“QRK1”调整payload里的content即可。加签模式需要追加签名import requests import json import time import hmac import hashlib import base64 secret SEC你的加签密钥 timestamp str(round(time.time() * 1000)) string_to_sign f{timestamp}\n{secret}.encode(utf-8) hmac_code hmac.new(string_to_sign, digestmodhashlib.sha256).digest() sign base64.b64encode(hmac_code).decode(utf-8) url fhttps://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKENtimestamp{timestamp}sign{sign} payload {msgtype: text, text: {content: QRK1线缺装报警请确认}} requests.post(url, datajson.dumps(payload), headers{Content-Type: application/json})注意sign的计算必须严格按“换行符分隔timestamp和secret”的格式少了换行符签名就对不上接口返回310000。4.4 训练集不平衡拖累精度小样本零件的模型怎么救现象某些零件精确率能到0.999另外几个始终在0.988附近徘徊再训练也上不去。原因样本量差异大。门槛亮条有3700多张训练图左侧裙只有282张模型见过太少泛化能力弱换角度和光照就认不准。解决两个方向并行。一是对样本量少的类别补充采集连续多跑几个班次专门收集该类零件不同角度、不同光线的图片二是做在线数据增强YOLOv5默认会做随机旋转、缩放、色彩抖动可以把增强幅度调大到0.5以上。论文强调每隔一个月重新训练模型会越来越准道理就在这里——误报和漏报图片回流到数据集里相当于持续给模型补课。4.5 模型精度“玄学”上线后翻车IOU阈值不能随便动现象离线测试精确率98%以上上线后漏报反而变多了特别是小板件和暗色胶堵。原因离线评估和现场实拍存在分布差异阈值卡在0.5时预测框只要稍有偏移就被判为负样本。阈值高边界框要求严格暗色零件对比度低框的位置稍微偏一点就失败了。解决先固定IOU为0.5复现论文口径确认模型本身没问题后再针对漏报案例把阈值往下调0.05试一轮例如0.45观察精确率和召回率的变化。调阈值是最后的补救手段根本解法是把漏报案例加入训练集重新迭代。现场最怕的是追求漂亮数字而层层调阈值最后模型对真实样本完全失明。4.6 服务器算力不够导致识别卡顿现象车辆到了拍照工位系统还在处理上一台车的图片识别结果迟迟出不来节拍被拉长。原因YOLOv5s虽然网络最小但CPU推理一帧也要几百毫秒到数秒不等论文没有详述服务器GPU配置只提了Windows 10、PyTorch 1.8.0的环境。如果推理设备没有独立显卡或者显卡显存不足导致batch size被迫调小速度跟不上线体节拍。解决优先确认服务器是否装了NVIDIA显卡驱动和CUDA对应版本的PyTorch。显存吃紧时把batch size降到8或4牺牲吞吐保延迟再不行就换一张中端显卡或者把识别线程和图像采集线程分开采集线程持续抓帧放队列识别线程异步消费避免一拍一停。5. 从99%迭代到99.5%月度重训、数据闭环与效果验证5.1 月度重训的正确姿势论文里有一句话容易被忽略每隔一个月会对模型进行重新训练让准确性达到99.5%以上。这不是定时把旧模型拿出来再跑一遍就完事而是要把这一个月里现场实际产生的识别结果数据特别是错报和漏报的图片人工确认后补充进训练集再执行一轮完整训练。这里有一个隐含习惯值得照做每次翻车后都要把出问题的图片归档标注好正确结果累计到一定数量就触发新一轮训练。我自己跑产线项目的固定动作是每周导出本月的误检样本按工位和零件分类存好月底统一并入数据集重训。这样做的好处是模型会记住现场新出现的光线条件、换型工况和新装零件不会越用越钝。5.2 效果与经济效益对照论文给出的前后对比数据非常扎实之前车间漏检返修数量为每年240次经济损失20万元系统运行近6个月相关零件错漏检返修数量只有1次。换算下来半年只花了一台普通服务器的成本就换回了原来一年都消不掉的质量赔款。这套系统的经济性来自三个方面摄像头用现有的普通网络摄像头而不是工业相机模型用开源的YOLOv5s和PyTorch没有闭源授权费后端用Python、MySQL和钉钉这些现成组件开发成本集中在数据标注和联调上。项目原人工检查机器视觉系统漏检返修次数240次/年6个月1次经济损失约20万元/年大幅下降影响因素疲劳、经验、注意力光照依赖无主观疲劳识别准确率受主观干扰精确率和召回率均大于98%扩展性增加人员应对新车型新增模型即可适配5.3 换零件快速铺开的方法论这套系统最值钱的不是代码本身而是“一零件一模型数据闭环验证”这套方法论。新的零件要接入检测只需要做三件事第一用现有摄像头采集该零件的正常和缺装状态图片各几百张按640×640预处理并标注第二单独训练一个YOLOv5s模型按第3节的参数配置走一遍IOU设0.5评估第三部署时在PLC触发逻辑里增加一个零件类型字段车辆到站先判断车型对应的检测项再加载对应模型推理。整个过程不用动系统主体架构模型文件和平时的坑基本都在样本侧只要把样本采集现场的光照固定下来精度就有下限保证。从那以后我每次做完一轮模型迭代都会强制自己走一遍“旧样本回归验证”把上一版能检出的测试集再跑一遍防止新增样本把旧场景的精度拉崩。这个习惯帮我在多个项目里提前拦下了返工风险。这套基于机器视觉技术的汽车制造零件检测系统从PLC联动到模型训练都给了可复现的细节值得下载下来照着搭一遍希望帮到你。本文还有配套的精品资源点击获取