简介一套电梯内人车识别数据集面向深度学习目标检测任务适用于YOLO系列、Faster RCNN、SSD等主流算法训练。数据集中共97张电梯场景图片标注类别为person、motorcycle、bicycle覆盖行人、摩托车、自行车三类目标可用于电梯内安全监控、违规行为预警等场景的模型开发。压缩包共2000个文件其中1999个txt标签文件与1个yaml类别配置文件txt文件为YOLO格式的标注信息yaml文件包含类别名称与路径设置整体包体大小约193.33MB下载后可直接接入YOLOv5至YOLOv10等版本进行训练。目前已有200人学习下载。数据集同时兼容VOC格式便于不同框架间转换配套的标签文件命名规范图像与标注一一对应省去整理数据的繁琐步骤适合刚接触目标检测的初学者快速开展实验也可作为真实电梯场景下算法评测与调参的基准数据。1. 电梯内人车识别数据集为什么通用目标检测模型在这里总是翻车做智慧社区和安防监控的工程师多半都接过这样一个需求电梯里进了电瓶车物业想用摄像头自动盯住。电梯内人车识别数据集目标检测方向里最不起眼却最容易返工的场景之一。这个数据集定义的是一个封闭轿厢空间里的两类目标——人和两轮车视角固定、纵深短、光照随开关门剧烈变化不锈钢镜面反光还会把目标复制一份。通用目标检测模型在公开数据集上跑得不错丢进电梯里第一版往往全是误报漏检。我会围绕数据采集、标注规范、YOLO 训练参数、边缘部署和现场排查这几个环节把这个方向完整落地。2. 电梯人车数据集的构建从摄像头到 YOLO 训练集2.1 电梯场景的特殊性决定了类别怎么定电梯轿厢是固定点位的封闭空间摄像头多数装在顶部角落呈斜向下俯视。这种视角有两个直接后果一是目标尺寸整体偏小一辆电动自行车在 1080p 画幅里通常只有 150×80 像素左右属于典型的小目标二是目标互相遮挡严重人推车进电梯时车身侧面被人腿挡住大半人下车推行时人又在车后面。公开的人车数据集里几乎没有轿厢这个视角拿来预训练可以直接当训练集用就会在换点位时崩掉。类别定义我建议一开始就拆细。不要直接标 person 和 vehicle 两类而是标 person、bicycle、motorcycle、ebike 四类。电梯场景里后三类混着出现但客户对电瓶车的告警优先级远高于自行车拆细了后面做策略很简单合并成“车”类只是后处理几行代码的事反过来一开始标成一个大类等客户提出“只报电瓶车”的需求时就得重新导数据返工标注这是这个项目里第一个值得多花半天时间的决定。类别不平衡在电梯场景里格外明显电梯里绝大多数时间是“有人无车”有车帧往往只占全部录像的 5% 到 10%数据分布和真实业务分布一致所以训练时不能只追求整体指标要把“进电梯的车”当成真正的正样本去抠。2.2 采集抽帧用 ffmpeg 在录像里取样大部分项目是直接从物业手里拿现成的监控录像而不是自己布摄像头。物业给的录像常带日期水印、画质陈旧、白天夜间都有这反而适合做数据集因为它覆盖了白天、夜间红外、开门瞬间曝光过曝等真实情况。拿到原始录像后的第一步是按固定帧率抽帧避免相邻帧高度重复浪费标注量。下面这个命令是我常用的抽帧方式ffmpeg -i elevator_cam_day1.mp4 -vf fps5,scale1280:720,setptsPTS -q:v 2 -threads 4 frames/day1/frame_%06d.jpg抽帧参数按需求调整。fps5 是平衡点电梯从开门到关门大概 15 到 30 秒5 帧每秒能保证每一秒有 4 到 5 个可用画面又不会产生大量几乎相同的相邻帧scale 到 1280×720 是为了和后续模型输入尺寸匹配同时避免 4K 源图把标注工作量放大好几倍q:v 2 表示 JPEG 压缩质量较高细节损失小。抽完帧先做一次人工快筛把长时间空轿厢、镜头被遮挡、检修停机这类无效帧删掉再进入标注环节这一步能直接砍掉三成无谓标注工作量。另一个容易忽略的点是开门动作的 1 到 2 秒内画面过曝、模糊这类帧不能删它们正是推理阶段最容易翻车的数据。2.3 标注工具与标注规范目标检测常用的标注工具里电梯这类密集小目标场景我推荐 X-AnyLabeling 或 labelImg。X-AnyLabeling 可以用 SAM 做预标注人推车这类对比度高的目标预标注质量不错人工只需要修正边界框和补漏检速度比纯手工大概快一倍。labelImg 更轻量适合不依赖预标注的旧电脑。项目产出统一采用 YOLO 格式每个 jpg 对应一个同名 txt每行内容是 class_id x_center y_center width height四个坐标值都是相对图像的归一化数值。标注规范要在动工前写死否则多人标注出来的框会不一致。我的三条硬规则第一只要目标可见面积超过 20% 就必须标注被电梯门切掉一半的人也要标第二婴儿车、轮椅、快递小推车不标为 ebike但单独留一批不标注的负样本帧专门用来治误报第三镜面里的倒影坚决不标这一点电梯场景特别容易踩不锈钢轿厢反射出的人影如果被标进去模型会把“两个人影”学成正常特征推理时就会出现同一物理位置重复出框。提示标注规范写完后先让两个人各标 50 帧计算框的 IoU 一致性低于 0.8 就说明规范还有歧义不要急着铺开。标注完成后统一导出一份 COCO 或 VOC 格式用于后续分析再转成 YOLO 训练格式边界坐标要做 clamp 处理防止标注时手抖把框拖出画面边界。转换脚本的核心逻辑如下def voc_to_yolo(voc_w, voc_h, box, cls, out_txt): # box: [xmin, ymin, xmax, ymax]以像素为单位 dw, dh 1.0 / voc_w, 1.0 / voc_h x_center (box[0] box[2]) / 2.0 * dw y_center (box[1] box[3]) / 2.0 * dh w (box[2] - box[0]) * dw h (box[3] - box[1]) * dh x_center min(max(x_center, 0.0), 1.0) y_center min(max(y_center, 0.0), 1.0) w min(max(w, 0.0), 1.0) h min(max(h, 0.0), 1.0) out_txt.write(f{cls} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}\n)这段逻辑是把 VOC 的绝对像素坐标换算成 YOLO 需要的归一化中心点加宽高换算公式是中心点等于 (xminxmax)/2 再除以图宽宽高同理。最后四行 clamp 是为了防止标注框拖出画面导致训练报错。脚本本身不复杂但它是数据集流转到 YOLO 训练阶段必经的一步出问题最多的就是坐标算反或者忘记归一化训练时 loss 从第一个 epoch 就异常这时再回头排查非常耗时。2.4 数据划分按监控点位切不按随机帧切训练集、验证集、测试集的划分方式是电梯数据集里影响泛化最深的一个决定。常见错误是按帧随机划分同一个视频序列里第 10 帧在训练集、第 12 帧在验证集两者相差不到一秒画面几乎一模一样验证集的 mAP 会虚高到失去参考价值。正确的做法是按监控点位划分把编号 1、2、3 号摄像头的全部帧放进训练集4 号摄像头的全部帧放进验证集5 号摄像头单独留作测试集。这样验证集看到的是没见过的摄像头下的光照、视角和电梯品牌用来评估“换一台电梯还能不能用”的泛化能力。划分比例我一般取 7:2:1。同时重点保证验证集里“有车帧”占比和真实业务接近不能全是空轿厢。真实业务里 10% 左右的帧有车那么验证集也应该大致维持这个比例。要是验证集里空轿厢占了 95%模型把一切判断为背景也能拿到 0.95 的准确率这个分数没有任何意义。按点位划分会让验证集和训练集的图像风格差异变大初期指标可能比随机划分低几个点这才是真实的泛化水平上线前宁可看这个偏低的数据。3. 用 YOLO 训练自己的电梯人车数据集从选型到参数调优3.1 模型选型小模型起步别一上来就追求大模型电梯内人车识别最终要跑在边缘盒子上推理速度直接决定用多大的模型。我的建议是先用 YOLOv8n 跑通基线再根据实际帧率需求升级到 YOLOv8s 或 YOLOv11n。n 系列在 Jetson Orin Nano 这类设备上做 640 输入推理经验上的单帧延迟在十几毫秒到几十毫秒量级足够支撑 10 帧以上的实时分析s 系列精度更高帧率会往下掉。不要把 YOLOv11x 这类大模型当成第一步选择电梯场景目标类别少、场景单一大模型的提升很有限过拟合风险和部署成本却不小。目标检测模型微调崩了的案例里多半都是小数据硬上大模型导致的。类别数少不代表问题简单。电梯场景的难点是环境干扰多不是类别多所以模型的参数量不是瓶颈数据质量和增强策略才是瓶颈。选好模型后准备一份数据集配置文件指向前面整理好的训练集和验证集# elevator.yaml path: /data/elevator train: images/train val: images/val names: 0: person 1: bicycle 2: motorcycle 3: ebike配置文件的 names 顺序要与标注文件里的 class_id 严格一致。多轮迭代后如果重新整理过数据集先检查类别顺序是否被改过我曾经因为重新导出时把 person 和 ebike 的顺序写反训练出来的模型输出的类别标签全部错位推理结果在画面上“人车不分”排查了大半天才发现只是配置文件的问题这个黑匣子式的错位很难一眼看出来。3.2 关键超参数epochs、imgsz 与增强开关训练命令我一般这样组织yolo detect train \ dataelevator.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16 \ patience20 \ optimizerAdamW \ lr00.001 \ close_mosaic10 \ fliplr0.0 \ hsv_h0.02 hsv_s0.4 hsv_v0.3 \ scale0.5参数含义逐个说。imgsz640 是通用默认的输入分辨率电梯内目标尺寸偏小如果验证集上小车 AP 不理想可以试 imgsz960代价是推理耗时增加约一倍所以先跑 640 做基线close_mosaic10 表示最后 10 个 epoch 关闭马赛克增强因为马赛克会把同一张图里来自不同录像的片段拼在一起造成电梯轿厢的纹理失真模型可能学到“拼贴感”而不是目标本身fliplr0.0 是关闭左右翻转这个很多人忽略电梯不是左右对称的场景——轿厢门通常在一侧对面的电视广告牌、摄像头安装角度都有方向性强行左右翻转等于制造错误样本scale0.5 控制尺度变化幅度限制在 0.5 是为了不让目标被缩得太小。优化器上我偏好在中小数据集上用 AdamW收敛比 SGD 稳lr00.001 是 AdamW 相对稳妥的起始值。patience20 表示连续 20 个 epoch 验证集指标没有提升就提前结束电梯数据集一般 60 到 80 个 epoch 就能收敛跑满 100 个 epoch 多数是浪费时间。如果验证 loss 震荡第一反应不是乱调 lr而是检查验证集里是不是混进了重复帧或标注错误帧数据脏导致的震荡调参没有效果。3.3 类别不平衡与小目标看起来是模型问题实际是数据问题电梯人车识别里车类样本天然稀缺。有车帧只占总帧数的 5% 到 10%模型天然偏向把画面全部判成背景。解决手段按优先级排序先做负样本难例挖掘把标注时明确排除的婴儿车、轮椅帧挑选出来单独留作背景负样本再考虑对车类做 1.5 到 2 倍的重复采样让训练时车类样本出现频率和 person 类接近最后才考虑调损失权重也就是 YOLO 训练参数里的 cls 权重。小目标方面电梯里最常见的问题是远角的人只有不到 50 像素高640 输入下采样 32 倍后只剩 1 到 2 个特征点。先检查数据再看模型把标注框尺寸分布统计出来如果大部分框的宽高小于 48 像素说明小目标问题是数据分布本身决定的。一个有效做法是训练用 960 输入、推理保持 640配合 SAHI 这类切片推理库在部署时对大图做滑窗检测两个方案能覆盖大多数电梯小目标漏检问题。不要上来就调 anchor 或换注意力模块电梯场景的收益通常没有想象中大数据侧的改变在工程上更可控。4. 从模型到告警边缘部署与电梯联动控制4.1 模型导出从 PyTorch 到 ONNX 与 TensorRT训练完成后导出环节决定了模型在边缘设备上能跑多快。YOLOv8 系列导出 ONNX 的命令yolo export modelbest.pt formatonnx opset12 dynamicFalse simplifyTruedynamicFalse 很关键固定输入尺寸可以让 TensorRT 在构建引擎时做更多优化。导出后先用 onnxruntime 在本地跑一遍和训练相同的前处理对比输出框是否一致再转 TensorRT 的 FP16 引擎。边缘硬件选型上常见方案是 RK3588 系列盒子或 Jetson Orin Nano两者都能跑 640 输入的裁剪模型。尽量别用纯 CPU 盒子扛两路以上的实时分析帧率会掉到个位数。这里有个经验之谈如果现场只有一路电梯视频n 系列模型在好一点的 CPU 上勉强能跑但一有夜视增强或去噪就扛不住预算允许时直接上带 NPU 的盒子省掉后面所有性能扯皮。4.2 RTSP 拉流推理主循环部署代码的核心是一个可靠不崩的推理循环。电梯监控的 RTSP 流经常因为信号问题断流重连推理程序要对读取失败做自动重连。主循环的基本结构import cv2 import numpy as np import onnxruntime as ort sess ort.InferenceSession(model_fp16.onnx, providers[CUDAExecutionProvider]) cap cv2.VideoCapture(rtsp://user:passcamera_ip:554/stream1) retry 0 while True: ret, frame cap.read() if not ret: retry 1 if retry 10: cap.release() cap cv2.VideoCapture(rtsp://user:passcamera_ip:554/stream1) retry 0 continue retry 0 img cv2.resize(frame, (640, 640)) blob img[:, :, ::-1].transpose(2, 0, 1)[None].astype(np.float32) / 255.0 outputs sess.run(None, {sess.get_inputs()[0].name: blob}) # outputs 经过解码与 NMS 后得到 boxes, scores, class_ids # 去抖逻辑该点位连续 3 帧出现 ebike 时才触发告警这段代码的前处理顺序是 BGR 转 RGB、通道维度调整到 (1,3,640,640)、归一化到 0~1任何一个顺序错误都会导致推理结果完全混乱。颜色顺序错是最隐蔽的坑画面还能出框但目标颜色特征全乱夜间红外画质下误检率飙升。后处理部分用的是模型输出的解码头包括置信度阈值过滤和 NMS置信度阈值一般设 0.25太低会出现大量误报电梯这种高风险场景宁可漏一帧也不要反复误报。断线重连的 retry 计数上限和间隔也要调电梯井道内信号屏蔽严重摄像头偶尔断流是常态程序不能一断就退出。4.3 告警联动人车同框去抖与现场联动业务上真正要报的不是“画面里有车”而是“人把车推进了电梯”。纯车的画面可能是邻居在挪车、维修工在检修这类误报会让物业很快关掉整个系统。所以告警逻辑必须做状态机检测到 ebike 或 motorcycle 后要求连续 3 到 5 帧都命中同一个人车同框区域才置为“告警确认”状态同一目标在 60 秒内只触发一次避免电梯门一开一合连发七八条推送。联动输出一般走两种通道。一种是继电器开关量直接联动物业值班室声光报警这要求推理设备有 GPIO 输出能力常见做法是边缘盒子通过串口或网口连接一个继电器模块另一种是走 MQTT 推送把告警截图和设备编号发给物业平台由平台决定是否人工介入。我一般两种都做继电器保证现场即时震慑MQTT 保证有记录可追溯。注意继电器联动属于弱电控制范畴现场接线必须和电梯维保单位确认不要在未经允许的情况下直接控制电梯门这个安全责任边界要在项目启动时就写进需求和合同里。5. 电梯场景下的 5 个高频翻车点与排查记录这一章的内容全部来自真实项目里反复出现的坑。每条按现象、原因、解决方法来写每一条都值得在标注和调参阶段提前预防比起事后返工预防的成本低得多。5.1 电梯门开启的瞬间误检率暴增现象白天轿厢门一开模型突然把门口大块白色区域框成目标连续报出不存在的人和车。原因开门瞬间走廊强光涌入画面出现大面积过曝和眩光模型从来没有在训练数据里见过这种“中间状态”的画面。解决抽帧采集时不要只取画面稳定的片段把开门动作那 1 到 2 秒过曝、模糊的帧全部保留并正常标注让人和车在过曝状态下的轮廓也成为训练分布的一部分。如果不想增大标注量也可以在推理侧加一个亮度判断画面整体过曝时降低置信度并延迟告警但这是治标治本还是补数据。5.2 不锈钢轿厢镜面导致同一目标被检测两三次现象推理画面上人和车的位置出现重复框一个在实体内一个在镜面反射里两个框还都满足置信度阈值。原因训练数据里标注了倒影目标模型学到了“同一场景出现两个相似目标”的分布特征。解决回到标注环节删除所有镜面倒影标注把镜面区域视为背景推理阶段可以用基于区域的 NMS 升级策略对位置上呈镜面对称的框做二次抑制。这类问题在标注规范里写清楚“倒影不标注”就能根治最早那个版本因为多人标注时意见不一致漏删了一批倒影框上线后花了一周去调 NMS 参数最后还是靠清洗标注解决的。5.3 婴儿车、轮椅、超市推车不断误报现象模型把婴儿车报成 ebike把轮椅报成 motorcycle物业每天收到几十条假告警。原因这些目标的外形轮廓和两轮车有相似性而训练集里完全没有这类负样本模型“没见过”它们只能按最像的车类去输出。解决做 hard negative mining把婴儿车、轮椅、行李箱、清洁推车的画面单独抽出来标注时故意不标任何框混入训练数据作为背景帧如果客户希望区分婴儿车和电瓶车也可以给这些目标单独建类但通常客户只关心“不能是电瓶车”所以按背景处理是性价比最高的办法。这类误报在第一次上线后一定会出现建议上线后第一周每天收集误报截图攒够几百张就做一次增量训练。5.4 按帧随机划分数据集导致 mAP 虚高换摄像头就翻车现象本地验证集 mAP 到了 0.9现场换一个电梯点位检测率直接跌到不足一半。原因数据集划分按帧随机切训练集和验证集之间存在大量时间差不到 1 秒的相邻帧验证集评估的是“记忆力”而不是“泛化力”。解决回到 2.4 节说的按点位划分原则同时引入一个跨设备测试集用完全没参与训练的一台电梯录像做最终验收。这也是为什么我在第 2 章强调多采集几台不同品牌的电梯不同轿厢的内饰纹理、灯光色温、摄像头安装高度差异很大模型要在这些差异下稳定数据里就必须包含这些差异。5.5 夜间红外画质下的漏检比白天严重得多现象白天检测正常的模型到了夜间红外模式人和车的检出率明显下降红外反光下电动车轮廓和墙面糊在一起。原因训练集中的夜间帧比例太低或者夜间样本在标注时使用了较宽松的框模型对红外画质的特征学习不足。解决训练集里夜间与白天帧比例至少做到 3:7夜间样本不需要对半但绝不能只占 5%推理侧对夜间时段单独做图像预处理例如 CLAHE 对比度增强再送入模型。排查这类问题要按时间段分开评估不要只看总体 mAP# 按小时汇总检测结果定位夜间漏检窗口 for hour in range(24): frames [f for f in records if f[hour] hour] tp sum(f[is_tp] for f in frames) fn sum(f[is_fn] for f in frames) recall tp / (tp fn) if (tp fn) 0 else 0 print(f{hour:02d}:00 TP{tp} FN{fn} recall{recall:.2f})这段脚本按小时汇总测试结果TP 和 FN 由人工回放标注召回率低于 0.8 的时间段就是需要补样本的时段。夜间问题的特征是集中在 20:00 到 06:00 的连续窗口如果脚本输出显示召回率在傍晚骤降基本可以确认是红外画质问题而不是零散噪声。6. 交付前最该做的一件事用历史录像做批量回放验证当模型在标注验证集上分数不错、部署也接通了先别急着签约验收。我给自己定了一条规矩交付前一晚把客户现场一台电梯最近 24 小时的录像按 4 到 8 倍速批量回放用推理服务跑一遍统计每小时误报数和主要漏检时段。这一步能发现很多单帧评估发现不了的问题比如开关门瞬间的连续误报、夜间固定时段的漏检、同一目标反复告警刷屏。回放验证的产出是一张简单表格时段、报警次数、误报次数、漏检目标截图。误报截图单独归档每张写上一句话原因这既是给客户的验收材料也是下一次增量训练的数据源。做这件事不需要额外写复杂平台第 4 章那个推理循环加一个计时器和截图落盘就够用了。进阶一点可以按点位单独统计多台电梯时对比各点位的误报率分布通常能快速暴露某一台电梯的特殊问题比如 3 号梯因为正对消防通道开门时的过曝明显比其它点位严重这时就需要给它单独准备增强样本。这个习惯帮我在交付阶段少吃了很多返工的亏尤其是婴儿车误报那次第一次做完全没有预案被客户用一天几十条假告警的截图找上门才回头补负样本。从那以后我把回放验证写进自己的交付清单宁可多花一晚也不让客户替我发现问题。希望帮到你。本文还有配套的精品资源点击获取