自助售货机行业的运营方最怕的不是机器大故障而是货道明明有货却报缺货、顾客选了商品但出货时卡住、货被买走之后系统没扣款。这些问题的根源很多都能归结到机器没有眼睛。自助售货机商品检测这个毕设方向正好就是在给机器装上一双能看懂货道的眼睛——用摄像头感知货架状态再通过目标检测模型识别商品、判断货道是否缺货、是否卡货。这个课题既有算法深度又有工程落地属性从数据集构建、模型训练、边缘部署到业务逻辑闭环全链路都能覆盖属于拿得出手、讲得清楚、演示得了的典型毕业设计选题。选题的时候我就给这个项目定了一个基本盘不做机械臂不做SLAM不做支付系统先把视觉感知状态推理这条主线做扎实。这个定位很重要因为毕设的核心是完整闭环而不是把摊子铺得太大。接下来我把整套流程拆开复盘一遍从选题论证、方案设计、数据准备到模型训练、部署调试、论文答辩每个环节该注意什么、坑在哪里全部按实操节奏来讲。1. 选题复盘为什么商品检测值得拿来当毕设做1.1 先搞清检测在售货机场景里的真实任务很多同学一听商品检测就以为是做一个通用的物体检测Demo拿个预训练模型跑通就结束了。实际上售货机场景里的检测是分层的罗列一下就有四层第一层是识别告诉系统货道里摆的是什么是可乐还是薯片是矿泉水还是运动饮料第二层是定位商品出现在图像里的哪个位置对应物理空间里的哪个货道第三层是计数这个货道里现在有几件商品是否已经快要卖空第四层是状态推理结合连续多帧检测结果判断货道是否卡货、是否有商品倾倒、是否有不属于该货道的商品混入。把这四层串起来就是一个完整的视觉感知业务闭环。相比单纯的图像分类只回答这是什么或者纯目标检测只回答哪里有目标这种带业务规则判定的方案更有说服力也更贴近真实产业需求。答辩的时候老师问你做了什么创新你就可以说不是算法层面的新结构而是把检测结果转化成了可用的业务信号。1.2 为什么比单纯做一个模型更有差异化我建议你把这个毕设定位成业务驱动的视觉系统而不是一个模型。两者的差别在哪里单纯做一个YOLO模型指标就是mAP但做成售货机商品检测系统你的工作就扩成了五个部分数据构建、模型选型、后处理逻辑、边缘端部署、系统演示。这里有一条重要的逻辑毕设的验收标准不只看模型的精度还看工作量和系统完整度。如果你只做一个预训练模型微调可能两周就做完了后面没东西写而一旦加入货道状态推理和缺货告警系统论文的第三章、第四章、第五章都能铺开实验章节也有对比数据。这个选题的差异化恰好在于它不是一个孤立的模型训练任务而是一个能落地的感知系统。1.3 选题边界要主动砍掉哪些内容我在规划时特意划了一条不做清单不做机械臂抓取不做PLC联动不做移动端App不做多模态融合。原因很简单——毕设时间和精力有限砍掉这些非核心模块才能把主力方向做深。不做机械臂是因为机械结构设计和控制逻辑要额外消耗大量时间不做App是因为前后端开发工作量会挤占模型调优时间不做多模态融合则是因为售货机场景下单摄像头视觉已经足够满足需求加传感器反而增加变量。这个砍需求的动作本身在开题报告里也可以作为研究边界来写老师会觉得你想得很清楚。1.4 从毕设验收角度倒推工作量结构我习惯用倒推法来做工作量规划。如果学院要求论文的第三章是方案设计、第四章是实验验证、第五章是系统实现与测试那倒推出数据就应该是数据集部分至少对应第三章的一个完整小节模型对比实验对应第四章系统集成和测试对应第五章。这个结构决定了你每个阶段要完成的任务量数据要自己采集标注一批不完全依赖公开集模型要跑至少三个算法的对比实验系统要有一个可视化界面或者至少一套能运行的检测逻辑能对着摄像头实时出结果。这样排下来从开题到答辩的几个月就不会有空窗期也不会到最后一个月才开始极限补实验。2. 系统总体架构与硬件视角设计先定框架再写代码2.1 核心架构的三层分离整套系统我按照标准的三层结构来设计感知层、算法层、业务层。感知层负责图像采集用固定视角的摄像头拍摄货道区域保证图像的稳定性和一致性算法层运行目标检测模型输出每个商品的类别、置信度和检测框业务层拿到检测结果后将检测框映射到预设的货道感兴趣区域ROI结合当前货道应该摆放的商品清单计算该货道是否缺货商品是否错位是否疑似卡货等状态。这三层分离的核心好处是任意一层都可以独立替换和调试。模型精度不够就换算法层光线环境变化就调整感知层硬件规则逻辑有问题就只改业务层互不干扰。写代码的时候解耦做得好后期调试能省掉大量时间。2.2 摄像头安装视角的设计经验摄像头怎么摆直接决定了模型能不能训出来以及后面推理会不会经常出错。我实测下来的最优方案是采用倾斜俯视视角大约与货道水平面成45到60度夹角能看到每一层货道的商品正面和部分顶面。这里有一个关键原则尽量避免正对玻璃拍摄。自助售货机柜门是透明玻璃正对拍摄时反光极其严重玻璃上的倒影和光源反射会造成大量误检。倾斜视角可以大幅减少反光面积让模型只关注货道区域。同时要固定摄像头的焦距、光圈和曝光参数不能用自动曝光——自动曝光会在光源变化时导致画面明暗波动直接影响检测稳定性。照明方面我建议给货道加一组固定角度的LED补光灯把亮度补到500 lux以上。固定照明的好处是数据分布稳定模型训练时不需要为多种光照情况头疼。如果只能在自然光下使用那么数据增强里的亮度扰动就要做得更重。2.3 开发平台与部署平台的选型逻辑训练平台的选择比较省心有显存的消费级GPU就够用了。毕设级别的数据集规模下显存6GB即可运行主流检测模型的训练8GB更宽裕。关键是部署平台要提前想好别等模型训完了再配环境。我优先推荐的部署平台是一类带GPU的嵌入式边缘开发板显存2GB以上支持主流推理框架的硬件加速。备选方案是CPU边缘盒子适合把模型换成轻量化版本后用OpenVINO或ONNXRuntime加速。两种方案各有优势嵌入式GPU板运行YOLO系列时帧率更高演示更流畅CPU盒子价格便宜、功耗低但要把输入分辨率降到640以下并开启线程优化才能保证实时。如果你是纯软件方向没有硬件预算也可以用实验室里的台式机配普通USB摄像头完成部署同样能跑通全流程。不过演示效果会打折扣因为台式机的CPU推理往往不如带专用加速单元的设备流畅。我的建议是至少准备一套独立运行的最小硬件演示环境答辩时现场效果会好很多。2.4 评价指标定义别只盯着一个mAP做这个项目指标要分两层来看。模型层次和标准目标检测一样看mAP、Precision、Recall系统层次还要看三个业务指标缺货检出率、误报率没有缺货却报缺货的比例以及从图像采集到状态输出的端到端延迟。有一个容易被忽略的点单帧检出率并不代表业务正确率。商品在货道里被遮挡是常事一瓶饮料放在第二层可能被第一层商品挡掉一半。如果你只看单帧会发现检测框时有时无非常不稳定。这时就要用连续帧投票逻辑——连续N帧检测到该货道存在商品才判定为有货连续M帧检测不到才判定为缺货。N和M分别建议设为5和10这样能大幅减少误报。3. 数据集构建最容易被低估、实际最耗时的环节3.1 数据来源组合策略数据从哪里来决定了模型的泛化能力和你在论文里能讲多少东西。纯用公开数据集省事但答辩易被追问你的数据是否适配售货机场景纯自采数据成本和耗时又太高。我的做法是三路组合。第一路是自采数据占比大约百分之六十。把摄像头按最终方案的视角、光照、分辨率拍货道拍空货道、满货、半货、单件货、商品倾倒等各种状态每种状态都拍一段视频然后抽帧成图片。第二路是公开数据集我用了几个常见的商品检测数据集做预训练和补充量不需要大主要用来提升模型对同类商品包装形变的适应能力。第三路是增强数据在自采数据上做亮度扰动、模糊、缩放、旋转等增强生成一部分额外图片参与训练。3.2 标注规范与工具选型标注时最容易犯的错是随手标导致框的质量参差不齐。我的经验是立一个明确的标注规范检测框框住商品主体外轮廓不包含背景间隙类别名以货道中的固定编号商品名来命名比如channel_3_cola同一类别所有图片里的标识大小、字体重命名必须严格一致。标注工具我用过最顺手的还是开源的图形标注工具它支持Pascal VOC格式和YOLO格式导出也支持多人协作标注。毕设级别的数据集标注两三个同学一起做能快很多。要注意的是每周做一次标注抽检随机抽几十张图检查有没有漏标、错标、框偏的情况。标注质量差后期模型精度提升想都别想。3.3 面向售货机场景的数据增强策略通用目标检测的数据增强套路大家都清楚但售货机有特殊性以下四个增强操作强烈建议必做第一个是亮度扰动。售货机场景里光源角度、LED灯闪烁都会导致亮度波动把亮度随机调整幅度设置到正负百分之二十模型就能适应这种变化。第二个是玻璃反光模拟。在图像上叠加半透明的渐变白条或圆形高光模拟玻璃反光效果能有效减少反光导致的目标漏检。第三个是遮挡模拟。随机给商品区域添加黑色矩形块或局部模糊块模拟前层商品遮挡后层商品的情况。第四个是镜头污渍模拟。加一些细小灰色斑点和杂点模拟长时间未清洁的柜门玻璃上的污渍。3.4 数据量建议与难例挖掘毕设级别的项目我建议初始规模控制在20到30个产品类别每类200到400张包含该商品的有效图片总计图片量6000到8000张标注框数量2万个左右。这个数据量在这个场景下能把模型的mAP做到0.85以上也足够支撑论文实验了。数据构建阶段留一个专门的文件夹记录难例样本。什么叫难例同一商品出了新包装和旧包装外观差异大货道里有大量阴影和光照不均两瓶饮料紧贴导致检测框互相重叠。这些难例不要一开始就大量加入训练集而是等到模型训练后期针对性地补充进训练集微调效果比一开始全部混在一起好很多。4. 模型训练与业务逻辑从检测框到缺货/卡货判定4.1 算法选型别为最先进付多余成本这个项目的场景和需求其实很明确所以算法选型上不要贪新。我在复盘时把候选方案列了一个表这里直接分享对比结论方案精度推理速度部署难度备注主流YOLO系列中等尺寸高快低首选生态完善主流YOLO系列轻量版中等极快低适合无GPU设备传统轻量级检测头方法低中等中适合早期基线对比大尺寸模型高慢高适合精选难例不适合实时实测下来中等尺寸的YOLO版本在6000张数据量上训练最终的mAP能到0.87左右单张640乘640图片在嵌入式设备上推理耗时大约30到50毫秒完全满足实时率要求。轻量版YOLO在精度上会掉三到五个点但推理速度能压到20毫秒以内适合没有GPU的部署环境。选型逻辑的核心是先定部署平台再定模型复杂度。如果平台没有独立加速单元再大的模型也跑不动一切都是空中楼阁。4.2 训练细节盯着Loss曲线和验证集指标训练阶段有几个可以复用的实操经验。输入分辨率我建议固定640乘640不要一味加大到1280商品在图像里占的面积不算小640分辨率在精度和速度之间已经平衡得很好了。初始学习率设置在0.01附近用余弦退火调度批次大小根据显存来定8或16都可以。数据增强开启Mosaic、随机翻转、随机缩放但是有一个坑随机翻转不能垂直翻转。售货机里的商品永远是在货道上水平摆放的垂直翻转会生成实际中不可能出现的图像干扰模型学习。训练过程中不要只看最终的mAP我习惯每隔几个周期记录一张验证集曲线图和几张典型检测输出图。翻车的案例很多都藏在曲线里训练loss下降正常但验证集mAP横盘不动大概率是学习率设置过高或者数据增强过强训练loss和验证loss同时下不去先检查数据的标注有没有大面积错误而不是急着改模型结构。4.3 从检测框到业务状态ROI映射与缺货判定逻辑模型输出的检测框不是最终答案必须经过业务逻辑层转换这是我反复强调的一点。实现方式很直接在摄像头画面里预先标定每一层货道的左边缘、右边缘和分隔线生成一系列规则矩形区域作为ROI。每个检测框的中心点落在哪个ROI就认为该商品属于哪个货道。具体判定逻辑分三步走。第一步统计每个ROI里检测框数量以及检测框类别第二步和该ROI的期望商品列表比对类别匹配即认为存在该商品第三步结合连续帧投票判定货道状态。这里有一个很有用的技巧不要把检出的边框面积直接当作商品面积因为商品在图像里的成像大小会受透视影响要计算该检测框面积占整个ROI面积的比例低于一个小阈值比如百分之五时视为可能是误检不参与计数。缺货判定的阈值逻辑不同货道应该分开配置。最上层的货道可能只放一件大商品空与不空就看有没有检测框下层的饮料货道一排放五六瓶缺货阈值则设为检测框数量小于期望数量的一半再触发告警。这种按货道差异化配置的思路在真实项目中极其好用。4.4 模型部署与量化注意精度下跌的隐藏原因模型训练好之后从PyTorch训练权重到部署推理格式为标准流程。我建议导出为ONNX格式再用对应平台的推理框架做转换和加速。转换过程中最容易踩的坑是模型在PC上测试精度很高部署到边缘设备后精度明显下降。大多数时候问题不在量化本身而在预处理不统一。训练时用的是RGB三通道、归一化到0到1取值部署时如果预处理代码里把图片转成了BGR、或者忘了除以255、或者尺寸缩放方式对不上精度一定会掉。我的排查经验是先在部署设备上用同一张图跑一遍预处理后的张量数值对比PC端的输出是否一致差异大就说明预处理链路出问题了。最后再依次检查量化方式推荐先用INT8动态量化不行再回退FP16、NMS阈值、置信度阈值这几个环节。5. 实测中的翻车现场与完整排查链路5.1 现象一同一个商品有时能检出、有时检不出系统部署后的第一个诡异现场同一瓶可乐摆在同一个位置前一帧检测框稳稳地在后一帧就消失了再过几帧又回来了。这不是模型玄学而是工程问题。我按以下链路排查。先在离线保存的测试图片上跑模型确认在静态图片上检测正常排除模型本身不稳定的可能然后对着实时视频逐帧保存检测结果对比出错的帧和正常的帧发现出错帧的亮度普遍偏低再采集光照日志发现某个时间段柜机顶部的照明灯被遮挡画面亮度下降了百分之三十最后定位根因模型训练时数据增强的亮度扰动范围不够实际光照变化超出了训练分布。修复方案有两个方向。硬件层面换成恒流驱动的LED补光灯稳定光照软件层面增加亮度扰动强度到正负百分之三十并在模型训练集里补充低亮度样本。两件事都做了之后该现象的复现率基本降到零。5.2 现象二空货道被误报为有货有货被漏检这个现象比前一个更头疼。货道清了、扫描一下还是显示有货或者明明摆着商品却老是报缺货。单独看模型输出的检测框时会发现误报的框基本集中在货道边缘的隔板上隔板的金属反光在某个角度下会和商品特征撞脸漏检呢则大多发生在两个商品紧紧挨着的时候检测框互相覆盖后处理把其中一个框当成重复框抑制掉了。排查链路是这样的把所有误报和漏检截图导出按检测框坐标做热力分布图发现误报框坐标高度集中在ROI边缘再检查后处理阶段的NMS阈值发现设置的IoU阈值偏小重叠的两个框被激进地合并成一个。根因清晰后修复分两步第一步在后处理中加入边缘抑制检测框中心点距离ROI边界小于阈值就直接丢弃第二步调整NMS的IoU阈值从0.45上调到0.55同时保留置信度阈值在0.4附近。修复后误报率降低了约七成。5.3 现象三边缘设备推理耗时突然从稳定变成抖动有一版系统在白天运行稳定单帧推理稳定在30毫秒但到了晚上就开始随机抖动到60毫秒乃至80毫秒整个系统的告警延迟明显变大。这个现场很多人会一头扎进模型加速但其实问题不在模型。排查链路走下来先在终端打印每个推理阶段耗时发现检测模型本身耗时稳定抖动出现在图像读取和预处理阶段再对比白天和晚上的电源环境发现晚上柜机照明开启时摄像头模块的功耗增大USB供电不足导致传输帧率下降图像获取出现排队最终定位是电源和摄像头模块的组合问题。修复方案是为摄像头单独接入稳定电源模块并在代码里把图像输入缓存改为双缓冲读帧和推理并行处理。改完后单帧耗时重新回到稳定区间。5.4 调试工具与经验清单再次复盘我发现调试效率高的秘诀不在于查问题的速度而在于一开始就准备了三样东西。第一样是日志系统每次推理保存原始帧、检测框、置信度、耗时、帧号以环形缓冲形式保留最近五百帧。有了日志排查任何问题都有现场可以回放。第二样是可视化调试面板实时把检测框、ROI、货道状态直接叠加画在视频画面上调试时一眼就能看出问题在哪一层。第三样是离线回放工具把现场录制的视频保存下来在本地用同一套模型和逻辑跑一遍还原现场错误环境复现能力是排查问题的关键。6. 论文写作、工作量展示与答辩的四个要点6.1 论文章节怎么组织才有说服力论文结构建议按背景与需求分析、系统总体方案设计、数据集构建与标注规范、模型训练与优化方法、系统集成与测试结果、总结与展望来组织。这个结构的逻辑是每个环节都能在论文里分到独立章节每章都有实际产出不会出现前面写了很多理论、后面没有工程落实的失衡。在实验章节里务必放一张模型对比表。我做的对比表包含三列核心指标mAP、单帧推理耗时、模型参数量。对比对象包括轻量版YOLO、中等YOLO版本、以及一个传统目标检测方法作为baseline。实验结论要落在一句话上在保证实时率的前提下选择哪个模型平衡性最好。这个表述比单纯吹mAP高更有说服力。6.2 系统演示是最容易被忽视的加分项答辩现场最拉胯的情况是投影仪演示到一半摄像头画面变暗、检测框漂移然后全场看着你手忙脚乱地调参。我的建议是准备两套演示链路现场实时演示以及备用录屏视频。现场演示前做三件事选一个光线稳定的时间段把柜机摆在不逆光的位置提前预录一段包含正常有货、取走商品、系统报缺货三种状态的视频文件把模型置信度阈值适当调高到0.5减少现场误报的可能性。录屏备用视频的优势是画面稳定、可暂停、可回放答辩时完全可控。如果设备临时出问题果断切换到录屏视频不要在现场硬撑。6.3 时间排期参考与保底策略毕设整体节奏建议按四到四个月半来排。前三周完成选题调研和方案论证开题报告里核心系统设计图要画清楚第四周到第八周做数据采集和标注这个阶段每两周检查一次标注质量第九周到第十二周模型训练与调优跑算法对比实验和部署转换第十三周到第十五周完成系统集成、稳定性测试和论文初稿最后两周留作答辩准备。一个很实用的保底策略在第十五周结束时先冻结所有功能改进只修影响演示的严重Bug。毕设不是产品不要抱着还能再优化一版的心态无限拖延。把留出的最后时间用来整理答辩PPT和演练讲解词收益远大于再刷零点几个点的mAP。6.4 答辩提问的常见方向与准备思路老师围绕这个题目最喜欢问的问题有三个。第一个是你的数据集有多少张、多少类、标注质量怎么保证对应回答要突出标注规范、抽检机制、难例补充第二个是你和现有方法相比的优势在哪不要笼统说效果更好而是说在售货机场景下的误报率更低、业务逻辑更稳第三个是如果换一种场景你的系统能不能迁移这个问题考察的是你对系统设计解耦程度的理解。准备的时候可以把这些问题和答案写成单独的问答文档不用背但每个问题的核心逻辑链要能不看笔记讲出来。我见过很多同学模型做得好却因为现场紧张讲不清数据来源和系统设计白白丢了分数。这套流程走下来项目以实训验收通过、演示效果稳定收官。如果说一定要留一条最值得分享的经验我会选这一条工程类毕设的成败不取决于最后一个月能爆发多少而取决于前面数据、日志、版本管理这些不性感的工作有没有打好底子。源码目录、数据集版本、模型权重、日志文件从第一天就用日期内容的方式命名归档你会感谢当时的自己。