自助售货机行业的运营方最怕的不是机器大故障，而是"货道明明有货却报缺货"、"顾客选了商品但出货时卡住"、"货被买走之后系统没扣款"。这些问题的根源，很多都能归结到"机器没有眼睛"。自助售货机商品检测这个毕设方向，正好就是在给机器装上一双"能看懂货道的眼睛"——用摄像头感知货架状态，再通过目标检测模型识别商品、判断货道是否缺货、是否卡货。这个课题既有算法深度，又有工程落地属性，从数据集构建、模型训练、边缘部署到业务逻辑闭环，全链路都能覆盖，属于"拿得出手、讲得清楚、演示得了"的典型毕业设计选题。
选题的时候我就给这个项目定了一个基本盘：不做机械臂，不做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 答辩提问的常见方向与准备思路
老师围绕这个题目最喜欢问的问题有三个。第一个是"你的数据集有多少张、多少类、标注质量怎么保证"，对应回答要突出标注规范、抽检机制、难例补充；第二个是"你和现有方法相比的优势在哪"，不要笼统说"效果更好"，而是说"在售货机场景下的误报率更低、业务逻辑更稳"；第三个是"如果换一种场景，你的系统能不能迁移"，这个问题考察的是你对系统设计解耦程度的理解。
准备的时候可以把这些问题和答案写成单独的问答文档，不用背，但每个问题的核心逻辑链要能不看笔记讲出来。我见过很多同学模型做得好，却因为现场紧张讲不清数据来源和系统设计，白白丢了分数。
这套流程走下来，项目以"实训验收通过、演示效果稳定"收官。如果说一定要留一条最值得分享的经验，我会选这一条：工程类毕设的成败不取决于最后一个月能爆发多少，而取决于前面数据、日志、版本管理这些"不性感"的工作有没有打好底子。源码目录、数据集版本、模型权重、日志文件，从第一天就用"日期+内容"的方式命名归档，你会感谢当时的自己。
