资讯动态

基于YOLOv8的厨房物品智能识别系统:从数据标注到实时检测部署

发布时间:2026/10/22 2:53:22 来源:尧图企业网站定制
做饭这几年我最大的感受是厨房永远比你想的更乱。这边锅里的油还没热那边要找的菜刀又被砧板盖住了明明伸个手就能拿到酱油非要眯着眼睛在调料区里分辨哪个是生抽。所以我花了两周时间基于YOLOv8训练了一个多类别家庭厨房物品智能识别系统核心就是目标检测让程序在摄像头画面里实时圈出菜刀、砧板、碗盘、调料瓶等十几类物品并输出坐标和类别。这篇文章会把整个项目从数据准备、模型训练到源码实现的完整过程写出来适合有Python基础、想把目标检测落到实际场景里直接参考的朋友。1. 为什么是YOLOv8厨房场景对检测模型的真实要求1.1 厨房物品识别不是简单分类题一开始我也觉得识别物体不就是拿个分类模型跑一下吗但真进到厨房场景就发现画面里几乎永远同时出现一堆东西台面上摆着锅、碗、菜刀、砧板、几个调料瓶相互遮挡光线还会被窗户或顶灯打得忽明忽暗。纯分类模型只能告诉你“画面里有没有菜刀”却没法告诉你“菜刀在哪个位置”更没法配合后续的机械臂、安全提醒或者自动记账功能。目标检测模型输出的是每个物体的边界框和类别天然适合“找东西”这种任务。我在摄像头俯拍画面里需要把每个目标的位置框出来同时判断类别后面才能做区域判断——比如检测到菜刀出现在炉灶附近时给出预警。1.2 在实时性和精度之间YOLOv8是平衡点两阶段检测方案在精度上确实能打但推理速度往往扛不住实时摄像头流尤其在家里只有普通显卡或者核显的情况下。旧版单阶段模型部署简单但对密集小目标和重叠场景的泛化能力弱一些。我最终锁定YOLOv8主要是因为它把训练、验证、推理和导出封装得很顺从自定义数据集到跑到摄像头前不需要自己写太多配套脚本。更具体一点YOLOv8的骨干网络用了C2f结构既控制了参数量又增强了梯度流动解耦头把分类和回归分支分开收敛更快而且它自带尺度自适应的训练策略。对厨房里“中等大小的日常物品”这种目标YOLOv8n或s足够用输出帧率也可以接受。我在普通笔记本GPU上跑s模型推理延时大概在二三十毫秒量级完全够实时交互。2. 数据是识别的底气类别划分、采集和标注规范2.1 怎么定类别才不会被模型搞晕我第一版竟然定了20类包括锅、锅盖、菜刀、水果刀、砧板、碗、盘子、杯子、筷子、勺子、铲子、打蛋器、油瓶、酱油瓶、盐罐、洗菜盆、电饭煲内胆、微波炉、冰箱、燃气灶。训练之后发现问题很多油瓶和酱油瓶在俯拍画面里颜色太像碗和盘子更是几乎一样模型在混淆矩阵里疯狂把它们认错。后来我按“外观可区分、使用频率高、边界清晰”三原则重新精简成12类锅、菜刀、砧板、碗盘、杯子、筷子、勺子、铲子、调料瓶、洗菜盆、微波炉、冰箱。注意这里我把碗和盘子合并成了“碗盘”因为它们在俯拍视角下外轮廓高度相似合并之后模型轻松了很多实际使用中“找到碗盘”也不受影响。类别设计还要注意避免“包含关系”。比如“调料瓶”是很多不同形状瓶子的总称模型要学的是一个很分散的分布如果家里调料瓶颜色特别多样可以考虑按颜色或形态细分成“深色瓶”“浅色瓶”但不要分得太碎。分得太碎每个类别样本量不够反而互相打架。2.2 采集图片的三个渠道和关键细节训练数据我主要用了三个来源一是公共目标检测数据集里抽取厨房物品相关图片二是自己用手机和摄像头在不同时间、不同天气、不同灯光下拍摄三是录制厨房操作视频再抽帧。自己拍的数据尤其重要因为模型最终要部署在“你家的厨房光线”下公共数据集的分布和实际场景往往有差距。拍摄时要有意识覆盖这些变化不同拍摄高度平视、俯视、不同摆放状态整齐、凌乱、使用中、不同物品组合单件、多件、互相遮挡、不同材质不锈钢高光、玻璃透明、塑料哑光。每个类别的标注实例尽量不少于500个。如果某个类别数量实在不够哪怕先用少量的100个加上增强撑起来也比完全缺失好。2.3 标注工具与规范一个框也不能含糊标注用的是常见的桌面端开源标注工具导入图片、画矩形框、选类别、导出YOLO格式txt。规范我踩坑后再整理成这样边界框要紧贴可见边缘不要留太大空白也不要切掉目标实体。遮挡严重时只框住可见部分不要猜测被挡住的外形。透明玻璃杯、保鲜盒按整体轮廓框不要因为透过去看到背景就框得很小。类别名不要用中文和空格否则后续写配置文件容易出编码问题。一张图里同类物品出现多个时每个都要单独标注一个都不能漏。标注工具导出的是txt文件每行格式是class x_center y_center width height其中坐标都归一化到0到1之间。我每次标完都会抽查txt内容防止出现负数或大于1的坐标。2.4 数据划分和增强策略划分训练集和验证集时我犯过一个典型错误同一个视频连续帧拆开分到两边结果验证指标虚高了几个点。因为相邻帧内容太像模型相当于“记住了”验证画面。后来我改成按场景分组划分同一个房间、同一段时间拍的图片只进训练集或只进验证集才能看到真实泛化能力。数据增强方面YOLOv8训练时默认会做Mosaic、随机翻转、HSV扰动等。Mosaic对厨房场景帮助很大相当于把四张图拼在一起让模型见过更复杂的物体组合。但最后几十轮我会关闭Mosaic让模型在接近真实分布的单图场景里充分收敛。如果自己额外做离线增强注意翻转图片时标注坐标要同步翻转否则等于把标签改错了。3. 训练前的准备环境、目录结构和模型尺寸选择3.1 一套能跑通的环境配置环境部分其实不需要最新潮的配置稳定就好。我用的是Python 3.8以上安装好PyTorch以及配套的图像处理库、文件处理库。有GPU最好显存4GB以上就能训练YOLOv8s如果只有CPU也可以训练只是速度慢到让人怀疑人生建议先拿小模型试跑通再考虑。项目目录我建议这样组织kitchen_detect/ ├── datasets/ │ └── kitchen/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── kitchen.yaml ├── weights/ ├── src/ │ ├── detector.py │ ├── video_process.py │ └── safety_guard.py └── runs/图片放在images目录同名的txt标签放在labels目录YOLO训练时会自动根据base路径找对应标签。kitchen.yaml是数据集配置文件里面指定训练和验证图片路径、类别数量以及类别名称列表我提供一个参考path: datasets/kitchen train: images/train val: images/val names: 0: pot 1: kitchen_knife 2: cutting_board 3: bowl_plate 4: cup 5: chopsticks 6: spoon 7: spatula 8: condiment_bottle 9: basin 10: microwave 11: refrigerator3.2 YOLOv8n、s、m、l到底用哪个我的判断标准只有两条部署设备能不能跑得动以及精度差距是否对业务有影响。因为它们共用同一套训练代码切换尺寸只是改一个参数的事。在6GB显存上YOLOv8s训练batch16没问题速度也还行。我对比过n和s验证集mAP50大概差3个百分点s的框更稳尤其是对小一点的调料瓶和杯子。m和l虽然理论上精度更高但训练时间和推理耗时会明显上升对家庭厨房这种场景属于浪费算力。如果你的最终设备是一块低功耗边缘板子或者手机那就老实选n别纠结。模型尺寸不是越高越好部署时跑不动才是最大的问题。4. 训练、调参与验证结果分析4.1 训练命令和关键参数解读我用命令行方式启动训练配置文件直接传入yolo train datakitchen.yaml modelyolov8s.pt epochs300 imgsz640 batch16 device0 workers4 optimizerSGD lr00.01 close_mosaic10拆开说说每个参数的经验epochs300厨房场景不算复杂300轮足够如果数据量少200轮也够。imgsz640默认尺寸厨房物品普遍不是极小目标640能平衡速度和精度。如果摄像头画面里的物体都很小可以试1280但训练和推理都会变慢。optimizerSGDYOLOv8默认是AdamW但我在中后期切换到SGD能让边界框回归更稳这只是个人实验感觉你不一定照抄。close_mosaic10最后10轮关闭Mosaic让模型在真实单图分布上微调避免验证集和实际使用时因为拼接图引入的分布偏差。batch16如果你的显存只有4GB改成8显存足够可以到32但收益有限。训练时会自动保存最后一轮权重和最佳权重一般看runs/detect/train/weights/best.pt。4.2 验证指标怎么看不要只盯mAP50训练输出里有mAP50和mAP50-95两类指标mAP50是IoU阈值0.5下的平均精度mAP50-95则更严格。厨房物品日常使用中边界框不需要像素级精确所以mAP50达到0.85以上基本就够用了。真正要关注的是mAP50-95如果它明显偏低说明框的定位还是不够稳。我还喜欢看验证图片和混淆矩阵。混淆矩阵能直接告诉我哪些类别在互相认错碗和盘子、酱油瓶和醋瓶是最常见的打架组合。看过矩阵以后该合并类别、该补数据就一目了然。用验证图片看检测效果时重点关注三类错误漏检、误检和重复框。重复框通常可以通过调整NMS参数解决漏检往往发生在物品重叠较多或光线偏暗时误检常见于不锈钢反光被认成刀具、纹理复杂的抹布被认成砧板。4.3 两次训练失败的修复记录第一次训练我只给了每类两百多张图epochs跑到250轮训练集精度很高验证集mAP很低典型的过拟合。解决方案不是简单加正则而是老老实实补数据。我重新拍摄了不同角度和光线条件尤其是把餐具混在一起的照片拍了几百张类别样本翻了一倍过拟合明显缓解。第二次训练的问题是小类别被压得很惨筷子的召回率只有六成。原因很简单筷子样本少而且目标细长。我针对筷子单独补充了俯拍、斜放、交叉摆放的图片效果立刻上来。这里有个经验如果类别样本量差距过大硬性降低多数类的权重不如直接补少数类的真图合成数据只能应急。5. 源码核心模块与摄像头实时检测实现5.1 项目源码结构怎么拆如果只是把检测跑通一行命令就能预测图片但要做成“智能识别系统”还是要写几个模块。我的源码里核心就三个文件detector.py负责模型加载和单帧检测video_process.py负责读取摄像头、循环处理帧、绘制结果safety_guard.py负责业务逻辑比如判断菜刀是否靠近炉灶区域。detector.py的核心逻辑是初始化时加载训练好的best.pt和类别映射提供一个detect(frame)方法内部把图像预处理成模型输入尺寸运行模型过滤低置信度框再做NMS合并重叠框最后把框坐标换算回原图尺寸返回一个结构化的结果列表。这样上层业务代码完全不用关心模型细节。下面是一个简化版的检测函数骨架具体实现可以对照你用的YOLOv8接口调整import cv2 def detect_objects(model_img, frame): # 将frame预处理好送入模型 results model_img.predict(frame, conf0.25, iou0.45) detections [] for r in results: boxes r.boxes for box in boxes: cls int(box.cls[0]) conf float(box.conf[0]) x1, y1, x2, y2 box.xyxy[0].tolist() detections.append({ class: class_names[cls], confidence: conf, bbox: [x1, y1, x2, y2] }) return detections要注意不同YOLOv8实现返回的对象字段不完全一样有的可能是xywh而不是xyxy。写代码前先打印一下返回结果的结构不要凭感觉取字段。5.2 摄像头实时检测的主循环实时检测的主循环其实不复杂就是读取一帧、检测一帧、画框显示cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: break detections detect_objects(frame) for det in detections: x1, y1, x2, y2 map(int, det[bbox]) label f{det[class]} {det[confidence]:.2f} cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(frame, label, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) cv2.imshow(kitchen_detect, frame) if cv2.waitKey(1) ord(q): break cap.release() cv2.destroyAllWindows()这里有个容易被忽略的点摄像头分辨率不要直接拉满。我一开始用4K摄像头结果每一帧推理延时感人。后来把输入分辨率限制在1280x720检测框依然够用帧率明显回升。视频流检测时还可以做跳帧比如每两帧检测一次中间一帧直接复用上一帧的检测结果对保鲜膜这类静止物品没有影响。5.3 从“检测”到“智能”用一个简单安全提醒举例如果只画框这套系统还谈不上“智能”。我加了一个小功能检测菜刀是否进入灶台区域。实现方式很简单在画面中手工标出灶台对应的多边形区域然后判断菜刀检测框中心点是否落在这个区域内。这个逻辑放在safety_guard.py里import cv2 zone [(250, 180), (520, 160), (600, 320), (300, 360)] def in_danger_zone(center): return cv2.pointPolygonTest(zone, center, False) 0 def check_knife(detections): for det in detections: if det[class] kitchen_knife: x1, y1, x2, y2 det[bbox] center ((x1 x2) / 2, (y1 y2) / 2) if in_danger_zone(center): return True return False当返回真时就可以触发声光提醒或推送一条消息。这种基于几何位置的业务扩展目标检测坐标本身的价值就体现出来了。你可以继续扩展识别到锅在灶台上并且长时间无人提示注意关火识别到多个调料瓶时语音播报当前拿的是哪一瓶。所有扩展都建立在稳定、低延迟的检测结果上。6. 部署到真实厨房性能优化与误检抑制6.1 模型导出与量化把体积和延时都降下来训练好的best.pt是PyTorch格式直接部署时加载慢、体积大。我先导出为ONNX格式再转换到目标设备上更高效的执行格式。这一步操作起来很简单但要注意导出时把输入尺寸固定为部署时实际使用的尺寸不要一会儿640一会儿320。批次大小设成1能省掉不少转换问题。如果设备算力紧张可以尝试INT8量化。我实际测试过INT8模型体积只有原来的四分之一推理路径上的耗时也明显降低代价是部分小物体检测框会轻微抖动尤其是筷子这类细长目标。对厨房物品识别来说INT8精度下降还在可用范围内但如果你要做手术刀这种毫米级应用那就老老实实用FP16或FP32。6.2 光线反射导致的误检靠补负样本压下去实装之后我发现一个让人头秃的问题不锈钢锅盖在阳光照射下形成的高光区域经常被模型识别成“菜刀”因为反光的形状和刀身太像了。这就是训练图像分布和实际环境不一致导致的误检。除了补充大量不同光线条件的真实照片外我还加入了一批“负样本”完全不包含任何待识别物品的厨房背景图、只有台面空空的图、只有窗户反光的图。标注时不给这些图标任何物体模型通过这些图学会了“画面里没有目标时不要强行输出”背景误检明显减少。处理误检还有一招是调置信度阈值。实时检测时我把阈值提到0.4误检降低不少同时漏检也没增加太多。实际阈值要根据摄像头安装角度和现场情况调不要照抄别人的0.25。你可以先记录一组不同阈值下的检准率和检全率再选平衡点。6.3 低算力设备上的实时性取舍如果你的最终设备不是电脑而是边缘盒子或者手机一定不要直接拿s模型去跑。我的做法是先换n模型再把推理尺寸从640降到480。降低输入尺寸对mAP的影响可能只有1个百分点但帧率提升非常明显。另外摄像头角度也直接影响检测难度。我实测过垂直俯拍台面时物体重叠严重检测表现最差稍微倾斜30度到45度拍摄物体边界更清楚检测精度反而更高。安装摄像头时不要追求正上方俯拍稍微斜一点对模型更友好。最后说点实在的整个项目做完我最大的体会是模型训练只占一小部分时间大部分时间都花在数据清洗、标注复核和实景调试上。如果你也想做类似的物品识别系统建议别一上来就追求20类、30类先把5类最想识别的物品跑通等流程成熟了再逐步加类。从头搭建时可以把检测结果先打印出来看看模型在哪些图片上翻车再针对翻车图片补数据这样迭代效率最高。厨房场景虽然乱但物体类别相对固定只要数据分布贴近你的真实厨房YOLOv8完全能给你意外惊喜。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑