YOLOv8电梯电瓶车检测系统实战：从数据集构建到RK3588边缘部署-北京尧图网络

电梯里推进来一辆电瓶车这个画面在很多小区几乎每天都在上演。物业贴告示、保安口头劝阻、电梯里装镜子能试的办法都试过效果都不持久。真正能解决问题的思路是让电梯自己看见并拒绝关门——而这正好是目标检测模型最擅长的事情。下面这套方案我用 YOLOv8 从零搭了一套电梯内电瓶车检测识别系统包含数据准备、模型训练、推理部署、中英文双语界面源码可以直接跑起来。整套东西不依赖任何特殊硬件一台带显卡的普通机器就能训练部署端甚至能塞进 RK3588 这类边缘板子里。适合做安防、智慧社区、嵌入式视觉的开发者也适合刚接触 YOLOv8 想找一个完整落地项目练手的朋友。1. 为什么电梯场景的电瓶车检测不能直接套用通用模型1.1 通用检测模型在电梯里的三个水土不服很多人第一反应是电瓶车不就是个常见物体吗COCO 预训练模型直接拿来用不就行了我一开始也这么想实测下来完全不行。COCO 数据集里根本没有电瓶车这个类别最接近的是 motorcycle 和 bicycle但电梯里的电瓶车往往是只露出车头或者半截车身模型会把它误判成摩托车、自行车甚至在某些角度下判成人。第一个水土不服是视角问题。电梯是俯视或者斜俯视视角摄像头通常装在轿厢顶部角落往下拍。这个视角下电瓶车呈现的是一个被严重压缩的形态车轮变成椭圆车把和车身重叠和路上平视拍到的电瓶车完全不是一个样子。通用模型没见过这种视角特征提取直接失效。第二个是遮挡与截断。电梯空间小电瓶车推进来时经常只进来一半或者被人、被电梯门挡住一部分。检测模型对截断目标的召回率本来就低再加上电梯里光线差、金属反光误检漏检一大堆。第三个是背景干扰。电梯轿厢里有镜子、有广告屏、有金属扶手这些高反光、强纹理的区域特别容易产生假阳性。我早期用通用模型测试镜子里的电瓶车倒影被检测出来两次一次真身一次倒影直接导致误报。所以结论很明确必须针对电梯场景做专门的数据集和微调训练不能指望通用模型开箱即用。1.2 电梯场景下检测到什么程度才算合格这里有个很多人忽略的问题检测精度不是越高越好而是要匹配业务逻辑。电梯电瓶车检测的最终目的是阻止电瓶车进入轿厢并联动电梯控制所以对模型的要求和普通检测任务不一样。我给自己定的指标是这样的召回率优先于精确率。也就是说宁可偶尔把婴儿车、大件行李误判成电瓶车触发一次误报警保安过去看一眼也绝对不能漏掉真正的电瓶车。因为漏检意味着电瓶车进了电梯一旦在轿厢内起火后果是灾难性的。所以训练时我把置信度阈值调得比较低大概 0.35 左右同时通过后处理逻辑连续多帧确认来压制误报。另外一个关键点是响应速度。电梯门从打开到关闭通常只有几秒模型必须在电瓶车进入的瞬间就给出判断延迟超过 500ms 基本就没意义了。这就要求模型不能太大YOLOv8n 或者 YOLOv8s 是比较合适的选择m 以上在边缘设备上跑不动。2. 数据集构建电梯电瓶车检测最耗时也最关键的环节2.1 数据从哪来三种采集渠道的取舍做这个项目模型结构反而是最简单的部分真正花时间的是数据。我用了三个渠道凑数据真实电梯监控截图找物业合作从几个小区的电梯监控里导出视频抽帧。这是最贴近实际部署场景的数据但涉及隐私必须做脱敏处理人脸打码、模糊楼层信息而且数量有限。自己拍摄找几辆电瓶车在不同电梯、不同光照、不同角度下拍。我大概拍了 2000 多张覆盖白天、夜晚、开灯、关灯、满员、空厢等各种情况。这部分数据质量最高因为可以刻意构造困难样本。网络公开数据补充一些公开的电动车、摩托车数据集可以拿来做负样本或者预训练但要注意版权和许可。最终我整理出大约 6000 张有效图像其中正样本含电瓶车约 4000 张负样本电梯内无电瓶车但有婴儿车、行李箱、轮椅等易混淆物体约 2000 张。负样本非常重要它直接决定了模型的误报率。2.2 标注规范一个类别还是多个类别标注这块我纠结过是只标一个电瓶车类别还是细分两轮电瓶车三轮电瓶车电动滑板车实测下来单类别方案更适合落地。原因有三第一业务上不需要区分类型只要判断是不是电瓶车就够了第二细分会导致每个子类样本不足模型学不好第三多类别会增加后处理复杂度没必要。标注工具我用的是 labelImg格式选 YOLO txt。标注时有个经验边界框要尽量贴紧目标但遇到截断目标时框要延伸到图像边缘。比如电瓶车只进来一半框就画到画面边界让模型学会部分车身也是电瓶车。另外镜子里的倒影我统一不标避免模型学到倒影特征。标注完成后做了一次数据清洗把框太小小于 20x20 像素、模糊到看不清、标注错误的样本剔除最终留下约 5500 张。2.3 数据增强哪些增强有用哪些是坑YOLOv8 自带的数据增强已经挺全了但电梯场景有几个特殊需求增强方式是否启用原因Mosaic启用提升小目标和遮挡场景表现但要注意关闭最后 10 轮随机翻转水平启用垂直禁用电梯场景不会上下颠倒垂直翻转会产生不合理样本色彩抖动适度启用应对不同电梯的灯光色温差异随机裁剪启用模拟截断目标旋转小角度启用模拟不同安装角度但角度别超过 15 度这里有个坑Mosaic 增强在训练后期会伤害性能。因为 Mosaic 拼接出来的图像不符合真实电梯场景的分布训练最后阶段应该关掉让模型在真实分布上收敛。YOLOv8 里通过close_mosaic参数控制我一般设成 10也就是最后 10 轮关闭。还有一个容易忽略的点电梯监控图像往往是灰度或者低饱和度的如果训练数据全是彩色高清图部署时会掉点。所以我在增强里加了随机灰度化概率设 0.1 左右让模型对色彩不敏感。3. YOLOv8 训练配置参数背后的逻辑3.1 环境搭建与版本选择环境这块没什么花哨的Python 3.9 以上PyTorch 对应显卡驱动版本然后装 ultralytics 包。我用的组合是pip install ultralytics8.0.200 pip install torch2.0.1 torchvision0.15.2显卡方面GTX 1660 Ti 6G 就能跑 YOLOv8n/s 的训练batch size 设 8 到 16。如果只有 CPU训练会非常慢建议至少用云端的单卡。我实测 1660 Ti 训练 5500 张图、100 轮大概 4 到 5 个小时。注意ultralytics 版本更新很快不同版本 API 有差异。建议锁定一个稳定版本别用 latest否则复现时容易出问题。3.2 训练参数怎么定一份可直接抄的配置我把训练配置整理成了一份 yaml关键参数和理由如下model: yolov8s.pt # 从预训练权重开始收敛快 data: elevator_bike.yaml # 数据集配置 epochs: 150 # 电梯场景数据量不大轮数适当多一些 imgsz: 640 # 标准输入尺寸兼顾精度和速度 batch: 16 # 1660Ti 6G 的极限再大就爆显存 lr0: 0.01 # 初始学习率 lrf: 0.01 # 最终学习率系数 momentum: 0.937 weight_decay: 0.0005 warmup_epochs: 3.0 # 预热轮数防止初期震荡 close_mosaic: 10 # 最后10轮关闭mosaic patience: 30 # 30轮无提升就早停为什么选 yolov8s 而不是 nn 更快但精度差一些电梯场景对召回率要求高s 是精度和速度的平衡点。如果部署到 RK3588 这种算力有限的板子可以退到 n但要做量化。学习率这块0.01 是 YOLOv8 的默认值对大多数场景都适用。如果发现 loss 震荡厉害可以降到 0.005。warmup 一定要开否则前几轮 loss 会炸。3.3 训练过程监控看什么指标怎么判断好坏训练时我主要盯三个东西loss 曲线、mAP 曲线、以及验证集上的实际检测效果。loss 分 box_loss、cls_loss、dfl_loss 三部分。box_loss 管定位cls_loss 管分类dfl_loss 是分布焦点损失。正常情况下三个 loss 都应该平滑下降。如果 cls_loss 一直不降说明类别学习有问题可能是标注错了或者正负样本比例失衡。mAP 看 mAP50 和 mAP50-95。电梯电瓶车检测这种单类别任务mAP50 能到 0.95 以上算不错mAP50-95 能到 0.7 以上就挺好。我最终训出来的模型 mAP50 是 0.968mAP50-95 是 0.742。但指标好看不代表实际好用。我每次训练完都会拿一批真实电梯监控截图做人工验证重点看漏检和误检。有一次 mAP 很高但实际测试发现夜间红外模式下漏检严重原因是训练数据里夜间样本太少。后来补了 800 张夜间图重新训练才解决。4. 推理与后处理让检测结果真正可用4.1 单帧检测到业务判断的鸿沟模型输出的是这一帧里有个电瓶车置信度 0.8但业务需要的是电瓶车正在进入电梯请阻止关门。这中间隔着一层后处理逻辑很多人直接跳过这步结果系统误报率高得没法用。我的后处理策略是这样的多帧确认连续 3 帧检测到电瓶车才触发报警单帧误检直接过滤掉。区域判断只在电梯门口和轿厢内部区域检测画面边缘的误检忽略。面积阈值检测框面积小于画面 2% 的忽略避免远处小目标误报。跟踪去重用简单的 IOU 跟踪同一个电瓶车在连续帧里只算一次。这套逻辑下来误报率从单帧的 15% 降到了 3% 以下基本可用了。4.2 推理代码的核心结构推理部分我封装成了一个类核心逻辑如下from ultralytics import YOLO import cv2 import numpy as np class ElevatorBikeDetector: def __init__(self, model_path, conf0.35, iou0.45): self.model YOLO(model_path) self.conf conf self.iou iou self.frame_buffer [] # 用于多帧确认 def detect(self, frame): results self.model(frame, confself.conf, iouself.iou, verboseFalse) boxes results[0].boxes detections [] for box in boxes: x1, y1, x2, y2 box.xyxy[0].cpu().numpy() conf float(box.conf[0]) area_ratio ((x2-x1)*(y2-y1)) / (frame.shape[0]*frame.shape[1]) if area_ratio 0.02: continue detections.append([x1, y1, x2, y2, conf]) return detections def judge(self, detections): self.frame_buffer.append(len(detections) 0) if len(self.frame_buffer) 3: self.frame_buffer.pop(0) # 连续3帧都有检测才报警 return len(self.frame_buffer) 3 and all(self.frame_buffer)置信度阈值 0.35 是权衡后的结果。调高到 0.5 会漏检调低到 0.2 误报太多。这个值要根据实际部署环境微调不同电梯的光照条件不一样。4.3 中英文双语界面的实现思路项目要求中英文双版我的做法是把所有界面文案抽到一个字典里通过语言参数切换LANG { zh: { title: 电梯电瓶车检测系统, alarm: 检测到电瓶车请勿进入电梯, normal: 电梯运行正常 }, en: { title: Elevator E-bike Detection System, alarm: E-bike detected, please do not enter, normal: Elevator operating normally } }界面用 OpenCV 的 putText 绘制但 OpenCV 默认不支持中文需要换成 PIL 绘制或者用 freetype 模块。我用的方案是 PIL把帧转成 PIL 图像用中文字体绘制文字再转回 OpenCV 格式。字体文件要打包进项目否则换台机器就乱码。5. 部署到边缘设备从 PC 到 RK3588 的迁移5.1 模型导出与量化PC 上跑 PyTorch 模型没问题但部署到 RK3588 这类板子必须转成它支持的格式。流程是PyTorch - ONNX - RKNN。# 导出ONNX yolo export modelbest.pt formatonnx imgsz640 opset12 # 用rknn-toolkit2转RKNN python convert_rknn.py转换时有个关键点量化方式选 i8 还是 fp16。i8 量化速度快、内存占用小但精度会掉一些实测 mAP 大概掉 2 到 3 个点。fp16 精度保持好但速度慢一些。电梯场景我建议用 i8因为掉的那点精度可以通过降低置信度阈值补回来而速度对实时性更重要。量化需要校准数据集从训练集里抽 200 到 500 张有代表性的图就行。校准集要覆盖各种光照和角度否则量化后某些场景会崩。5.2 边缘端推理的性能调优RK3588 有 NPU推理要走 NPU 才能发挥性能。用 rknn-toolkit2 的 runtime 接口加载模型输入图像要做 letterbox 预处理保持长宽比。实测下来YOLOv8n 在 RK3588 上单帧推理大概 30 到 40ms加上前后处理整体能跑到 15 到 20 FPS完全够电梯场景用。如果换成 yolov8s会降到 10 FPS 左右也还能接受。调优经验预处理和后处理尽量用 C 或者硬件加速Python 的 numpy 操作在边缘设备上是瓶颈。如果整个 pipeline 都用 Python光图像 resize 和归一化就能吃掉一半时间。5.3 与电梯控制系统的联动检测只是第一步真正落地要联动电梯控制。常见做法是通过继电器或者串口给电梯主板发信号触发开门保持或者禁止关门。这块涉及电梯厂商的协议不同品牌不一样需要和电梯维保方对接。我的建议是先做报警提示不要直接控制电梯。因为误报导致电梯困人是安全事故责任很大。等系统稳定运行几个月误报率降到可接受范围再考虑联动控制。报警提示可以做成声光报警器或者推送到物业值班室。6. 实测效果与踩坑记录6.1 模型在真实场景的表现最终模型在测试集上的表现mAP50 0.968mAP50-95 0.742单帧推理在 1660 Ti 上 8ms 左右。实际部署到两个小区的电梯里跑了三个月统计下来真实电瓶车进入事件127 次全部检出漏检 0 次。误报事件23 次主要是婴儿车11 次、大件行李箱7 次、轮椅5 次。误报率约 3.5%在可接受范围内。误报主要集中在婴儿车因为婴儿车和电瓶车在俯视视角下轮廓有相似性。后续可以通过增加婴儿车负样本继续优化。6.2 几个印象深刻的坑坑一镜子倒影导致重复检测。前面提过电梯里的镜子会让模型把倒影也检测出来。解决办法是在后处理里加区域过滤把镜子区域排除掉。但镜子位置不固定后来改成用跟踪去重同一个目标在画面里只保留一个框。坑二夜间红外模式掉点严重。白天表现很好的模型到了晚上红外模式下漏检率飙升。原因是红外图像是灰度的而且对比度和可见光完全不同。补了夜间数据重新训练后解决。教训是训练数据必须覆盖部署环境的全部光照条件。坑三模型对电瓶车部分进入判断不准。电瓶车刚进来一个车头时模型置信度只有 0.3 左右低于阈值就漏了。后来把置信度阈值降到 0.25同时靠多帧确认压制误报才解决这个问题。坑四RK3588 量化后精度骤降。第一次量化用了随机抽的校准集结果某些角度下模型完全失效。后来校准集改成按场景分层抽样覆盖各种光照和角度精度才恢复。6.3 还能怎么改进这套系统目前是单类别检测后续可以往几个方向扩展一是加入电瓶车状态判断比如是否在充电充电中的电瓶车风险更高二是结合多模态用视觉加传感器数据综合判断三是做跨镜头的目标跟踪电瓶车从电梯到楼道全程追踪。另外模型层面可以尝试 YOLOv11 或者更新的版本精度和速度可能有提升。但要注意换模型意味着重新训练和调参不是简单替换权重就行。整套源码我整理成了完整工程包含数据集配置、训练脚本、推理代码、双语界面、RKNN 转换脚本。跑起来最需要注意的是环境版本对齐尤其是 ultralytics 和 torch 的版本版本不对会出现各种奇怪的报错。数据集这块如果自己采集困难可以先用少量数据跑通流程再逐步扩充。电瓶车检测这个场景数据质量比模型结构重要得多多花时间在数据上比调参收益大。

YOLOv8电梯电瓶车检测系统实战：从数据集构建到RK3588边缘部署

相关推荐

嵌入式入门实战：LED、按键与LCD的GPIO驱动与状态机整合

DistServe解耦架构实战：Prefill与Decode分离如何让首字延迟骤降80%

AI编程三重奏：Spec、契约与TDD实战指南

更多资讯

AMLL Vue 绑定包演进实录：从 0.4 到 0.5 的架构重构、歌词组模型与关键修复解读

无铜点击葡聚糖：DBCO-Dextran DBCO-葡聚糖DBCO-Dex

开源AI助手WorkBuddy企业化改造：私有化部署与协作升级

易语言恒云雨驱动控制模块：用户态与内核态通信实战指南

WebSphere MQ入门拆解：队列管理器、通道与系统管理实战

从零搭建多角色博弈模拟系统：多智能体强化学习实战与调优

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？