2025年由于公司项目进入攻坚期，且生活重心有所调整，博客暂停了实时更新，现将这一年的技术沉淀集中整理到“2025实战总结”系列中。

需求概述

随着AI技术的发展普及，公司提出了通过深度学习方式来监督工厂环境中作业员的需求

1.检查作业员的手指有没有移动到SOP定义的位置

2.检查作业人员有没有使用治工具进行作业

3.检查作业人员有没有按照SOP操作产品（例如翻转产品）

4.实时显示检查结果并对错误的步骤即时提醒

5.网页端建立看板实时查看达标情况，并能查看每一个站的实时监测画面

6.每日发送未做到位的邮件提醒，实时监测并发送派工确认信息到对应责任人收集上

需求效益可以节省每条产线的监督人员2人（产线为处理异常和监督人员作业配置了4人编制），并建立了全流程监督回环

解决方案和遇到的问题

1（检查作业员的手指有没有移动到SOP定义的位置）

子需求1是检查作业员的手指有没有移动到SOP定义的位置，我们采用的解决方案是先通过YoloV7监测出产品的外部轮廓，再相对外部轮廓通过相对位置标记出需要检查的位置（也就是SOP定义的位置），接着使用MediaPipe来跟踪获取作业员手指位置，然后通过运算手指位置是否到需要检查的位置来判定是否PASS，在实现期间遇到诸多问题如下

期间遇到的问题如下

1.模型启动不使用显卡问题，解决方案是在代码添加CUDA检查代码

IsCUDA = f'(GPU:{subprocess.check_output(["nvidia-smi", "--query-gpu=name", "--format=csv,noheader,nounits"]).decode("utf-8").strip()})'

2.YoloV7检查产品的时候存在漏帧，解决方案是添加延时0.5秒，在新对象检测到的0.5秒前认为之前检测的有效

3.作业员手移动经过位置瞬间PASS，达不到检查目的，解决方案是添加检测延时，在网页配置此动作需要的时间，在手移动到目标框时间后才会PASS，一般是2秒

2（检查作业人员有没有使用治工具进行作业）

子需求2是检查作业人员有没有使用治工具进行作业，治工具主要是盖板，为达到限位目的配置的标准治工具，不使用会导致产品超过间隙标准和起子打坏料件。我们采用解决方法是在治工具上方添加特殊标识对象，用YoloV7模型检测到对象即认为有使用治工具

期间遇到的问题如下

1.治工具特殊标识漏识别问题，解决方案是重新挂载一个YoloV10模型，这个模型与产品轮廓模型独立开，且优化算法，在检测期间只要检测到添加特殊标识对象一次就认为治具已使用，直到下一个产品进入

3（检查作业人员有没有按照SOP操作产品）

子需求3是检查作业人员有没有按照SOP操作产品，例如翻转产品，解决方案是收集作业员翻转产品后的产品图作为训练资料训练YoloV10模型，使用时检测到了翻转后对象则认为作业员翻转了产品

期间遇到的问题如下

1.翻转后产品的样式不一样，把所有翻转后的样本训练后发现模型误报严重，训练了多个版本的产品翻转图都不行，随后团队进入思考人是怎么判断人员有没有翻转产品的，得出人原来是依靠人员翻转后的两只手的手指握住产品的样子判断的，于是翻转数据集使用实例分割标注人的两只手的样子得以解决

2.准备训练翻转模型的数据集时发现数据集筛选效率低，人工筛选需要两天左右，但是这个产品已经开始投产需快速导入，为解决效率问题，我们直接将前次训练的最优翻转模型用来离线赛选数据集，降低置信度后的准确度超过80%，人工筛选数量降低约95.83%，以前需要两天的数据集只需2小时筛选完

4（实时显示检查结果并对错误的步骤即时提醒）

子需求4是实时显示检查结果并对错误的步骤即时提醒，例如SOP定义的作业顺序是123，但是人员作业顺序是213，此时需提醒人员按照正确的顺序作业，此需求是为了贴合工厂制程组装料件顺序要求

期间遇到的问题如下

1.顺序配置问题，产品的种类很多，每个产品顺序需特异化配置，工作细致且数量大；解决方案是建立一个网页按照"厂别_线别_站别"-"机种"单独维护SOP步骤，每一步截取产线生产环境截图进行框选位置,单个机种站位维护在2分钟内

2.顺序检查和报警触发问题，实际导入遇到何时报警顺序不正确问题，部分产品站对于顺序并没要求，只要完成步骤就可以，部分产品对顺序要求严格，顺序错误极易导致制程不良；解决方案是网页特异配置，对制程顺序无要求的在产品作业结束后语音提醒，整体算做PASS，对有顺序要求的，进行单步骤监测，也就是第一步PASS后才会让第二步PASS，以此类推。

5（网页端建立看板实时查看达标情况）

子需求5是网页端建立看板实时查看达标情况，并能查看每一个站的实时监测画面，此需求要求较高，主要体现在远程连接和画面实时传输上，解决方案是固定IP+转流服务+Websocket，固定IP是为了找到连接的终端，转流服务是跨网段连接和负载均衡，Websocket是实际传输图像的协议，其中转流的图像为减少带宽占用，使用pyqt5只截取了程式UI部分传输

期间遇到的问题如下

1.固定IP方法问题，设备电脑ip有租赁期限，可能有变动，解决方法是使用可配置路由器（例如Cisco），制程工程师维护设备固资信息后，将mac地址和当前IP存储在数据库中，可配置路由器抓取这个表进行自动配置永不过期

2.转流服务构建问题，产线的设备电脑在内网，OA电脑在另一个网段，不在同一网段的电脑不能连接，解决方案是让一台服务器同时连接多个网段，同时为规避带宽问题，这个转流服务限制了最大同时连接4个用户，每个用户最大连接1分钟，规避带宽负载问题

3.Websocket连接问题，Websocket连接很耗费带宽和存在安全性风险，解决方案是限制帧数为10FPS，最大1分钟，并进行AD账号验证

6（每日发送未做到位的邮件提醒）

子需求6是每日发送未做到位的邮件提醒，实时监测并发送派工确认信息到对应责任人收集上，例如人工作业监测站每一台数据都会存储在数据库中，但是不会有人实时查看网页监控，于是构建了相关指标和责任人，由系统每15分钟自动监测一次，出现问题则发送给对应责任人

期间遇到的问题如下

1.发送派工太多处理不过来问题，主管要求精细化管理，每15分钟监测一次导致每日派工总数达到2000条以上，单个责任人达到100条以上，且主管将派工结案率作为KPI；目前此问题没有摸索解决方案，属于不同行政管理风格问题

2.派工项目分类过多问题，主管要求下分出了8个监测项目，实际派工中发现8个项目的原因归属存在争议，简而言之明面的责任人没有权力和责任来处理这个异常，解决方案短期是设立责任窗口，由责任窗口寻找对应责任人，并将解决信息填入网页记录，然后通过数据分析来派工实际负责单位，目前还是存在问题，暂未完全解决

3.派工解决积极性问题，由于派工数量大，处理人员少，因搭配第二条的解决方案责任人需串接多个单位和人员处理异常，责任人每日上班约处理20条异常已饱和，每日100条派工量导致人员积极性持续降低，目前没有解决方案，属于KPI管理效率协调问题

4.需求爆炸异常不收敛问题，由于此方案包含大量数据和解决方案，具有一定价值，于是工厂许多主管均基于此份数据需求开发派工看板，绩效评估API，派工结案率看板，派工回复网页等，但是开发完成后使用率和效果较低，重复性功能较多，管理空转严重，除绩效考核阶段需要写报告时大量问责外，平时少有人管理，目前没有解决方案，属于KPI管理和协调问题

#开发者思考：

对于上述问题可以总结成两个关键问题点：a.派工项目及数量过多，b.责任人的处理效率和积极性低；可能存在资源不足的问题，但工厂本身是制造企业，花费少量资源创造更多效益本身是其目标所以不过多讨论资源问题，

#要解决上面两个突出问题，可以有两个方向：

a.通过将8个项目进行数据统计出TOP2，将此TOP2的内容进行派工，剩余6项先不派工，派工的TOP2数量也会很多，单个负责人保守估计会收到20条，可以将这些项目合并成by项目发送，也就是责任人只会收到两条，就是TOP2的项目，包含了细节的线别和站别；b.对于责任人处理效率低的问题，当数量可以处理完成时，此问题属于管理问题，可以将处理数量和完成程度与绩效挂钩，以数据库回复数据做佐证，向上集成KPI绩效管理，也就是部长将此作为责任人课长的KPI之一，课长把这个作为工程师KPI之一，才有机会让这个项目不荒废，否则荒废只是时间问题

总结：

这个专案在实际应用中，确实是对AI技术的工业场景落地，也确实实时监测了作业员的动作并实时反馈结果，也做到了信息的数据存储和派工的闭环管理，但我身处在实际场景中，能感受到高管想导入这个专案并不是真的认可专案价值和逻辑，而是因为有这个专案，可以有理由每条线减少两个人，因为有数据存储和派工记录，可以在每年年底作为主管的扣分作证，因为有这个项目，可以得到每一站的作业时长，然后压着降低瓶颈站时长而提高产能。