尧图网页设计 
简介这份基于YOLO的安全监控系统设计压缩包面向毕业设计、课程设计与期末大作业场景借助深度学习目标检测技术解决实时视频流中的物体识别与安全预警问题适合具备一定Python与神经网络基础的学习者。包内共15个文件以7个Python脚本为主体涵盖视频流采集、实时检测、危险识别与消息通知等核心模块另有3个JSON配置、3个Markdown说明文档以及环境变量示例和权限管理文件整体大小仅28KB。目前已有46人学习下载。项目配有详细的说明文档从环境配置到使用步骤一目了然危险检测与消息发送脚本清晰呈现了告警逻辑和通知实现便于读者理解YOLO在真实监控系统中的落地流程。无论是用于课程设计报告还是想扩展为更完善的智能监控原型这份轻量级资源都能提供直接可用的代码骨架和设计思路。1. 安全监控里 YOLO 能扛住什么先把边界说清楚当接到一个安全监控系统设计的任务时最先被喊出来的往往是 YOLO。它能在单张 GPU 上跑到几十毫秒一帧把行人和异常区域框出来但真正把它做成能 7×24 小时跑的监控系统你还会撞上数据标注、夜间漏检、边缘设备误检率高、告警风暴这些破事。这套方案面向做毕设、做园区安防 Demo、或在小算力设备上落地监控的工程师先讲清 YOLO 在监控里的定位和选型再给一套能照做的数据集转换、训练调参、部署排查流程最后用时间序列把单帧检测变成可用的告警事件。它不是一个“装个 YOLO 就能报警”的魔术而是一条能把误检压到可接受范围的实际路线。2. 拆系统从摄像头到告警的链路与模型选型安全监控系统如果只放一个 YOLO它其实只能做“框出物体”。真正的系统要把拉流、抽帧、推理、过滤、告警这些环节串起来。我见过不少新人把训练好的权重直接塞给 OpenCV然后对着 30 路摄像头反复重启服务问题出在系统根本没有设计而不是模型不好。2.1 监控系统的四个环节一套典型的 YOLO 安全监控系统可以拆成四段视频接入摄像头通过 RTSP 或 ONVIF 出流也可能直接读 mp4 文件做离线分析。这里要处理断流、编码格式、时间戳对齐RTSP 的 TCP/UDP 传输模式会影响花屏行为。抽帧与缩放监控是 7×24 小时不可能每帧都送模型。通常每秒取 15 帧再缩放到模型输入尺寸。抽太密浪费算力抽太稀会漏掉快跑的人所以要根据摄像头覆盖范围定。推理YOLO 输出 bbox、类别、置信度。在 GPU 服务器上可以做 batch 推理在边缘盒子上通常只做单帧流式推理。事件生成这一步不是把框画在画面上就完事而是把检测结果和规则结合是不是进了禁区、是不是同一目标重复报警、要不要联动塞选库。真正影响用户体感的是这里不是模型精度。安全监控的“实时”实际是“在一小段时间内抓住目标”而不是逐帧告警。理解这一点后续所有设计都不会跑偏。2.2 选 YOLO 还是 YOLO慢模型按帧率和误检率权衡面对监控误检率高第一反应往往是升级大模型从 s 换到 l再从 l 换到 x。结果就是单路推理慢多路摄像头排队最后每秒钟只看得到两三帧。更合理的方案是分层YOLO 做第一级快筛把可能是人的目标框出来如果对准确率要求高再用第二个慢模型对候选框做确认。例如工地安全帽识别先用 YOLO 框出人头再用一个轻量分类器判断有没有戴帽。入侵监控同理先用 YOLO 框出人形再用姿态或行为模型判断是不是在异常运动。这样做的理由是监控画面背景相对固定误检大多来自光影、树枝、飞虫这些非目标物第一级让 YOLO 把候选区域送出来第二级专门做“像不像真人”的判断比单独调大 YOLO 更可控。96 路摄像头同时接入时单模型就算再快也扛不住每帧全跑必须给每路分配推理预算。下面是一个典型处理循环骨架可以后续慢慢填import time def pipeline_loop(capture, model, frame_interval3): frame_id 0 while True: ok, frame capture.read() if not ok: reconnect(capture) # 断流时重连避免服务空转 time.sleep(2) continue frame_id 1 if frame_id % frame_interval ! 0: # 每 3 帧抽 1 帧省算力 continue dets model(frame, imgsz1280, conf0.25, iou0.45) for det in dets.boxes: box det.xyxy[0].tolist() if in_roi(frame, box): # 只在监控区域内产生告警 push_event(frame, box)这段代码里的frame_interval是抽帧间隔我一般默认 3也就是每 3 帧推理一次如果场景里人走得快改成 1。imgsz是推理分辨率监控小目标多时至少 960下面会细说。in_roi是区域规则比如用多边形画一块禁区检测框中心落在里面才上报。push_event负责写事件表、存截图、发通知。系统要稳定重点在reconnect和事件去重而不是模型本身。2.3 版本选择YOLOv5 / YOLOv8 / YOLOv10 的适用边界很多读者会问“到底选哪个版本”。从落地角度看版本不是越新越好而是看部署生态和你的维护能力。下面是我在监控项目里的选择习惯选项优点注意点监控场景建议YOLOv5部署资料多TensorRT 示例多旧代码兼容好官方维护进入平缓期老项目维护、离线小工具YOLOv8API 统一支持分割/姿态导出顺手导出 ONNX 时要注意 opset 版本新项目默认选择YOLOv10去掉 NMS后处理省时间生态还在迭代部分部署库适配慢边缘算力紧张时可试跑在服务器上我推荐直接 YOLOv8因为它的 Python 接口和导出链路最干净。在 RK3588、Jetson 这类边缘设备上YOLOv10 的免 NMS 设计确实省一点时间但最终还是要看转换工具链是否支持别只看指标。选型的核心原则是先确定你的部署推理框架再定模型版本顺序反了容易白训。3. 建数据集监控画面和公开数据集差在哪监控落地时模型好坏七成在数据三成在调参。很多人直接下载预训练模型去跑监控视频结果是办公室场景检测得挺好到了园区广场就开始乱框。原因很直接监控摄像头是固定俯视视角车辆行人以小目标出现公开数据集里这种样本占比太少。3.1 监控场景和公开数据集的三点差异第一是视角。COCO 里的行人大多是平视视角人体占画面比例大监控摄像头往往挂在 36 米高度画面里的人是斜俯视占比小还可能被栏杆、绿化带遮挡。第二是光照。监控要覆盖白天、夜晚、逆光、雨天公开数据集几乎没有按时间段切分。第三是负样本。监控里大量画面是没人没车的空场景如果训练集里全是正样本模型遇到栏杆阴影就会“硬凑”一个目标出来。应对办法是在部署点位真实采集 37 天数据覆盖早中晚和天气变化。如果只是做毕设至少要找一个与最终场景类似的角度不要用随手拍的短视频。采集后按时间段分文件夹白天一部分、夜间一部分防止训练集单一日间导致夜间翻车。3.2 把 VOC 标注转成 YOLO 格式转换脚本与四个边界坑公开数据集和采集来的标注常见的是 VOC 格式也就是一个 XML 文件对应一张图。YOLO 训练需要的是每个图片一个 txt每行写class_id x_center y_center width height坐标全部归一化到 01。下面是一个能直接用的小转换脚本import xml.etree.ElementTree as ET from pathlib import Path def voc2yolo(xml_path: Path, save_dir: Path, class_names: tuple): root ET.parse(xml_path).getroot() # 原图宽高必须来自 XML 里的 size不能自己猜 img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) txt_path save_dir / (xml_path.stem .txt) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_names: continue # 忽略没有在配置里的类别避免训练报错 cls_id class_names.index(name) box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) cx ((x1 x2) / 2) / img_w cy ((y1 y2) / 2) / img_h bw (x2 - x1) / img_w bh (y2 - y1) / img_h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) txt_path.write_text(\n.join(lines))这里有几个边界坑一是xmin/ymin是左上角中心点要先加再除二别直接用xmin当中心二是某些标注工具会导出一个difficult标签如果不想让难样本参与训练要加判断过滤三是图片如果被旋转过标注坐标会失效训练前先统一方向四是归一化后的width和height是相对原图的不要乘回像素再写进 txt否则训练时框会飞出去。转换完成后抽查几张图最好画框可视化一次这一步能拦住 80% 的标注错误。3.3 数据增强与负样本处理监控场景里我常用的增强有三类颜色抖动亮度饱和度各调 ±20%模拟不同时段的曝光Mosaic 拼图把四张图拼成一张增加小目标密度和上下文多样性随机透视对画面做轻微拉伸模拟摄像头角度偏差。增强幅度不要过大不然模型学到的是“扭曲的画面”到了真实监控反而失控。负样本必须单独处理。我在工地监控项目里花了一天时间从 24 小时录像里抽出来上千张“空场景”帧没人的路面、树荫下的墙壁、夜晚灯光下的操场。把这些帧混进训练集模型才学会“什么都没发生的时候别输出”。比例上我按正负样本 8:2 来配负样本太少误检高太多则模型变得保守真实目标也漏掉。如果你发现误检集中在某个背景区域就针对性多抽那个区域的空间帧这个操作对误检率的改善比换模型还明显。4. 训练落地参数怎么设、损失怎么盯、崩在哪里数据集整理好之后接下来就是训练。这一章是最容易“看着教程走实际翻车”的部分。我会按环境、命令、崩溃排查三个层次讲最后单独说混淆矩阵总和不为 1 的问题。4.1 环境配置与一键部署脚本拿到项目压缩包后第一件事是建独立环境。Python 版本我建议 3.10PyTorch 按你的 GPU 驱动版本装。下面是一个最小可用的环境安装脚本# 解压项目包先看有没有 requirements.txt unzip -q based_on_yolo_monitor.zip -d yolo_monitor cd yolo_monitor # 创建独立环境避免污染服务器上的其他项目 conda create -n yolo_monitor python3.10 -y conda activate yolo_monitor # 先装 PyTorch再装 YOLO 训练工具 conda install pytorch torchvision pytorch-cuda12.1 -c pytorch -c nvidia pip install -r requirements.txt # 如果包里有 requirements.txt没有就 pip install ultralytics这里的关键是pytorch-cuda版本要和你的 NVIDIA 驱动匹配。如果驱动只支持 CUDA 11.x就不要硬装 12.1否则torch.cuda.is_available()返回 False你会在 CPU 上白白训几天。装完后执行python -c import torch; print(torch.cuda.is_available())看到 True 再往下走。4.2 训练自己的数据集三条命令和必调参数YOLOv8 的训练入口统一是yolo命令。先写一个数据描述文件放在项目datasets/monitor/下path: ./datasets/monitor train: images/train val: images/val nc: 3 names: [person, car, fire]然后启动训练yolo train datamonitor.yaml modelyolov8s.pt epochs120 imgsz960 batch16 device0imgsz是训练分辨率监控小目标多我建议至少 960有显存直接上 1280。batch看显存V100 32G 可以开到 64普通 12G 显卡开 16 到 24。epochs我一般先跑 100120如果 val loss 已经收敛就提前停监控场景不是叠 epoch 越多越好超过 200 反而容易过拟合背景纹理。训练过程中要盯两个曲线train/loss是否平滑下降metrics/precision(B)和metrics/recall(B)是否同步上升。如果 precision 涨 recall 掉就是阈值偏好问题了先别慌看测试时的混淆矩阵再决定。4.3 损失函数和训练中 BN 崩溃现象与处理训练中常见的一个翻车是 loss 突然变成 NaN或者显存占用没变但精度曲线断崖。有一个专门名词叫“BN 崩溃”BatchNorm 层的均值方差被极端值带飞后面所有层输出都变成 NaN。常见触发原因是学习率太大、batch 太小、或者混合精度在个别层上不稳定。解决办法按优先级来# 降低学习率 用 AdamW 拉长 warmup yolo train datamonitor.yaml modelyolov8s.pt epochs120 imgsz960 batch16 \ optimizerAdamW lr00.001 warmup_epochs5 device0如果这样还炸就关掉混合精度yolo train datamonitor.yaml modelyolov8s.pt epochs120 imgsz960 batch16 ampFalse device0我的经验是 batch 小于 8 时优先关 AMPbatch 能开到 16 以上再尝试 AMP。BN 崩溃还有一种表现是 loss 周期性尖峰比如每几十步跳一下这通常是数据批次里偶发一张异常图全黑或全白建议把那批图找出来删掉比调参更快。4.4 混淆矩阵总和为什么不为 1别再被这个现象卡住训练结束后你会在验证输出目录里看到confusion_matrix.png很多新同学数格子发现每行加起来不是 1担心模型有问题。实际上这是归一化方式造成的YOLO 的混淆矩阵按“真实类别”那一行做归一化因此每行总和是 1但列总和不一定有的版本还会把 background 作为额外一类格子里有被当成背景的目标会让数字更“对不上”。真正要关心的是对角线数值你把每类错到了哪里。比如person行里background列的值高说明“人没被框出来”已经变成背景漏检反过来background行里person列值高就是树影被当成人。我一般在训练后跑一次yolo val把输出的混淆矩阵和 curves 图翻一遍确认误检的主要方向再决定是加负样本还是调阈值。5. 部署与边缘排查监控误检率高的 4 个排查方向模型训练得漂亮到了边缘设备上又是另一回事。无论是 RK3588 盒子、Jetson Nano 还是树莓派都会遇到同一个问题单帧跑起来没问题连着跑两个小时误检率高到告警刷屏。这一章是我认为整个监控项目最值钱的部分。5.1 现象误检率高先分清是误报还是漏报误检率高先不要急着改模型先把告警记录和视频回放对一下告警里真正是人/车的比例有多高把“没人报成人”和“有人没报出来”分开统计。很多情况下是同一目标被连续几十帧重复告警看起来是误检率高其实只是事件去重没做。我见过最夸张的一次一个路灯在阳光下被当成 15 个“人”告警系统 5 分钟发了 80 条消息纯粹是缺了持续帧确认和多目标跟踪。5.2 排查方向一推理分辨率跟不上小目标现象监控画面里人只有三四十像素高预览框里有截图里也有就是模型不输出或者树的纹理被细节放大后反被误认为人。原因通常是推理分辨率被锁在 640。YOLO 训练用的imgsz960部署时就必须用同一个尺寸如果边缘设备跑不动宁可降低抽帧频率也要保持分辨率。推理分辨率调整一行代码就能看效果results model(frame, imgsz1280, conf0.25, iou0.45)imgsz提升后小目标在原图上对应的像素更多特征更明显。代价是耗时增加Jetson 这类设备上可能从 20ms 涨到 60ms但监控场景每 3 帧抽一次完全扛得住。如果 1280 还是跑不出小目标就该考虑 SAHI 切片推理了把原图切成 640 的块分别检测再合并结果这是工程上对付小目标的最后手段。5.3 排查方向二NMS 阈值和类别不均衡现象一个行人身上同时出现三四个框或者两个人走近被框成一个。原因是 NMS 的iou阈值没调好。iou太低会把重叠框都保留太高会合并掉相邻真实目标。我一般的起点是conf0.25, iou0.45监控场景如果误检多先把conf拉到 0.35看漏检涨不涨。参数对应关系可以参考参数值调大值调小conf误检少漏检多漏检少误检多iou重叠框合并少可能多框重叠框合并多可能漏小目标类别不均衡也会在 NMS 这里暴露。安全帽检测项目中head 类别样本远多于 helmet模型会把“没戴帽子的人头”也拼命输出。解决不是只调阈值而是去数据集里给少数类补样本或者对少数类做重复采样让 loss 不那么偏向多数类。5.4 排查方向三输入源与光照切换现象白天一切正常晚上或傍晚误检突然变多画面明显偏暗噪点变大。这是监控最容易翻车的场景训练集里白天帧太多模型学到的是“明亮环境下的人形纹理”到了夜间就开始猜。摄像头自身的自动白平衡、自动曝光会让同一位置在不同时段呈现完全不同色调这加剧了分布偏移。我的处理分两步。第一步采集数据时专门抽出夜间帧加进训练集第二步部署时如果摄像头支持把曝光模式固定让画面亮度不要频繁跳变。夜间误检高还有一个常见来源飞虫和雨滴。给 YOLO 送帧前可以把小面积高速目标过滤掉但这个不能靠阈值瞎试最好结合帧间差来判断目标是否在相邻帧连续移动。夜间帧采集可以用 ffmpeg 定时截帧省得写脚本# 每 30 秒存一帧连续存 1 小时覆盖天黑到更黑的过程 ffmpeg -rtsp_transport tcp -i rtsp://camera_ip -vf fps1/30 -t 3600 night_frames/%06d.jpg-rtsp_transport tcp很重要UDP 传输在弱网下会产生花屏和丢帧截出来的图脏反而污染训练集。5.5 排查方向四TensorRT/ONNX 量化的校准集没覆盖夜间现象导出 FP16 后精度正常转成 INT8 后误检率飙升甚至有些类别完全不输出。这是量化校准集与真实场景不匹配。INT8 量化需要几百张“有代表性”的图片计算激活值分布我见过有人用 COCO 图片做校准集最后监控画面里的树影全部被量化噪声放大成了人形。先导出 FP16 的 ONNX确认精度没问题再做 INT8 校准yolo export modelbest.pt formatonnx dynamicFalse opset12导出后如果要在 TensorRT 里转 engine校准集一定要从监控视频里抽并且白天、傍晚、夜间各占三分之一数量 300 到 500 张足够。如果在 RK3588 的 NPU 上跑优先用 FP16别为了省那点带宽硬上 INT8监控告警是三秒的事不是跑大模型推理服务量化的收益不值得拿误检率换。我的血泪经验是边缘设备上大部分误检都不是模型问题而是量化后特征分布彻底变了。6. 进阶用法把单帧检测变成监控事件最后这一步是把“框”变成“事件”。单帧检测结果永远是上下文无关的而监控系统需要的是“有人进入仓库”“在门口逗留太久”这样的事件。做法是给检测结果加一个轻量跟踪器和持续帧确认。我用一个简单的 IOU 跟踪器给每个检测框分配 ID然后要求同一 ID 连续出现至少 5 帧才触发。触发后进入 10 秒静默期这期间不再重复告警。事件确认逻辑可以浓缩成if det.conf 0.35 and track.age 5 and roi.contains(det.center): if time.time() - last_fire_at 10: fire_event(det) last_fire_at time.time()track.age是跟踪器维护的连续帧数roi.contains判断检测中心是否落在告警区域。这里的关键是last_fire_at静默期能有效防止告警风暴。我最早图省事单帧直接告警晚上树影一晃就给我框出几十个“人”加了 5 帧确认和静默期后误报量降到原来的十分之一。验证这套规则也很直接把录好的 24 小时监控视频离线重放统计每个阈值下的 precision 和 recall画一条 F1 随conf变化的曲线选 F1 最高的点作为上线参数。不要只看单帧 AP监控用户在意的是“一天收到几条假告警、漏掉几条真告警”这两个数字只有跑完一整天视频才能算出来。按这个流程做完方案里的模型、阈值、告警规则就都有一组可解释的数字支撑后续改摄像头位置或换设备也能快速复现。希望帮到你。本文还有配套的精品资源点击获取 YOLO安全监控系统落地：从数据集构建到告警事件生成
简介这份基于YOLO的安全监控系统设计压缩包面向毕业设计、课程设计与期末大作业场景借助深度学习目标检测技术解决实时视频流中的物体识别与安全预警问题适合具备一定Python与神经网络基础的学习者。包内共15个文件以7个Python脚本为主体涵盖视频流采集、实时检测、危险识别与消息通知等核心模块另有3个JSON配置、3个Markdown说明文档以及环境变量示例和权限管理文件整体大小仅28KB。目前已有46人学习下载。项目配有详细的说明文档从环境配置到使用步骤一目了然危险检测与消息发送脚本清晰呈现了告警逻辑和通知实现便于读者理解YOLO在真实监控系统中的落地流程。无论是用于课程设计报告还是想扩展为更完善的智能监控原型这份轻量级资源都能提供直接可用的代码骨架和设计思路。1. 安全监控里 YOLO 能扛住什么先把边界说清楚当接到一个安全监控系统设计的任务时最先被喊出来的往往是 YOLO。它能在单张 GPU 上跑到几十毫秒一帧把行人和异常区域框出来但真正把它做成能 7×24 小时跑的监控系统你还会撞上数据标注、夜间漏检、边缘设备误检率高、告警风暴这些破事。这套方案面向做毕设、做园区安防 Demo、或在小算力设备上落地监控的工程师先讲清 YOLO 在监控里的定位和选型再给一套能照做的数据集转换、训练调参、部署排查流程最后用时间序列把单帧检测变成可用的告警事件。它不是一个“装个 YOLO 就能报警”的魔术而是一条能把误检压到可接受范围的实际路线。2. 拆系统从摄像头到告警的链路与模型选型安全监控系统如果只放一个 YOLO它其实只能做“框出物体”。真正的系统要把拉流、抽帧、推理、过滤、告警这些环节串起来。我见过不少新人把训练好的权重直接塞给 OpenCV然后对着 30 路摄像头反复重启服务问题出在系统根本没有设计而不是模型不好。2.1 监控系统的四个环节一套典型的 YOLO 安全监控系统可以拆成四段视频接入摄像头通过 RTSP 或 ONVIF 出流也可能直接读 mp4 文件做离线分析。这里要处理断流、编码格式、时间戳对齐RTSP 的 TCP/UDP 传输模式会影响花屏行为。抽帧与缩放监控是 7×24 小时不可能每帧都送模型。通常每秒取 15 帧再缩放到模型输入尺寸。抽太密浪费算力抽太稀会漏掉快跑的人所以要根据摄像头覆盖范围定。推理YOLO 输出 bbox、类别、置信度。在 GPU 服务器上可以做 batch 推理在边缘盒子上通常只做单帧流式推理。事件生成这一步不是把框画在画面上就完事而是把检测结果和规则结合是不是进了禁区、是不是同一目标重复报警、要不要联动塞选库。真正影响用户体感的是这里不是模型精度。安全监控的“实时”实际是“在一小段时间内抓住目标”而不是逐帧告警。理解这一点后续所有设计都不会跑偏。2.2 选 YOLO 还是 YOLO慢模型按帧率和误检率权衡面对监控误检率高第一反应往往是升级大模型从 s 换到 l再从 l 换到 x。结果就是单路推理慢多路摄像头排队最后每秒钟只看得到两三帧。更合理的方案是分层YOLO 做第一级快筛把可能是人的目标框出来如果对准确率要求高再用第二个慢模型对候选框做确认。例如工地安全帽识别先用 YOLO 框出人头再用一个轻量分类器判断有没有戴帽。入侵监控同理先用 YOLO 框出人形再用姿态或行为模型判断是不是在异常运动。这样做的理由是监控画面背景相对固定误检大多来自光影、树枝、飞虫这些非目标物第一级让 YOLO 把候选区域送出来第二级专门做“像不像真人”的判断比单独调大 YOLO 更可控。96 路摄像头同时接入时单模型就算再快也扛不住每帧全跑必须给每路分配推理预算。下面是一个典型处理循环骨架可以后续慢慢填import time def pipeline_loop(capture, model, frame_interval3): frame_id 0 while True: ok, frame capture.read() if not ok: reconnect(capture) # 断流时重连避免服务空转 time.sleep(2) continue frame_id 1 if frame_id % frame_interval ! 0: # 每 3 帧抽 1 帧省算力 continue dets model(frame, imgsz1280, conf0.25, iou0.45) for det in dets.boxes: box det.xyxy[0].tolist() if in_roi(frame, box): # 只在监控区域内产生告警 push_event(frame, box)这段代码里的frame_interval是抽帧间隔我一般默认 3也就是每 3 帧推理一次如果场景里人走得快改成 1。imgsz是推理分辨率监控小目标多时至少 960下面会细说。in_roi是区域规则比如用多边形画一块禁区检测框中心落在里面才上报。push_event负责写事件表、存截图、发通知。系统要稳定重点在reconnect和事件去重而不是模型本身。2.3 版本选择YOLOv5 / YOLOv8 / YOLOv10 的适用边界很多读者会问“到底选哪个版本”。从落地角度看版本不是越新越好而是看部署生态和你的维护能力。下面是我在监控项目里的选择习惯选项优点注意点监控场景建议YOLOv5部署资料多TensorRT 示例多旧代码兼容好官方维护进入平缓期老项目维护、离线小工具YOLOv8API 统一支持分割/姿态导出顺手导出 ONNX 时要注意 opset 版本新项目默认选择YOLOv10去掉 NMS后处理省时间生态还在迭代部分部署库适配慢边缘算力紧张时可试跑在服务器上我推荐直接 YOLOv8因为它的 Python 接口和导出链路最干净。在 RK3588、Jetson 这类边缘设备上YOLOv10 的免 NMS 设计确实省一点时间但最终还是要看转换工具链是否支持别只看指标。选型的核心原则是先确定你的部署推理框架再定模型版本顺序反了容易白训。3. 建数据集监控画面和公开数据集差在哪监控落地时模型好坏七成在数据三成在调参。很多人直接下载预训练模型去跑监控视频结果是办公室场景检测得挺好到了园区广场就开始乱框。原因很直接监控摄像头是固定俯视视角车辆行人以小目标出现公开数据集里这种样本占比太少。3.1 监控场景和公开数据集的三点差异第一是视角。COCO 里的行人大多是平视视角人体占画面比例大监控摄像头往往挂在 36 米高度画面里的人是斜俯视占比小还可能被栏杆、绿化带遮挡。第二是光照。监控要覆盖白天、夜晚、逆光、雨天公开数据集几乎没有按时间段切分。第三是负样本。监控里大量画面是没人没车的空场景如果训练集里全是正样本模型遇到栏杆阴影就会“硬凑”一个目标出来。应对办法是在部署点位真实采集 37 天数据覆盖早中晚和天气变化。如果只是做毕设至少要找一个与最终场景类似的角度不要用随手拍的短视频。采集后按时间段分文件夹白天一部分、夜间一部分防止训练集单一日间导致夜间翻车。3.2 把 VOC 标注转成 YOLO 格式转换脚本与四个边界坑公开数据集和采集来的标注常见的是 VOC 格式也就是一个 XML 文件对应一张图。YOLO 训练需要的是每个图片一个 txt每行写class_id x_center y_center width height坐标全部归一化到 01。下面是一个能直接用的小转换脚本import xml.etree.ElementTree as ET from pathlib import Path def voc2yolo(xml_path: Path, save_dir: Path, class_names: tuple): root ET.parse(xml_path).getroot() # 原图宽高必须来自 XML 里的 size不能自己猜 img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) txt_path save_dir / (xml_path.stem .txt) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_names: continue # 忽略没有在配置里的类别避免训练报错 cls_id class_names.index(name) box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) cx ((x1 x2) / 2) / img_w cy ((y1 y2) / 2) / img_h bw (x2 - x1) / img_w bh (y2 - y1) / img_h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}) txt_path.write_text(\n.join(lines))这里有几个边界坑一是xmin/ymin是左上角中心点要先加再除二别直接用xmin当中心二是某些标注工具会导出一个difficult标签如果不想让难样本参与训练要加判断过滤三是图片如果被旋转过标注坐标会失效训练前先统一方向四是归一化后的width和height是相对原图的不要乘回像素再写进 txt否则训练时框会飞出去。转换完成后抽查几张图最好画框可视化一次这一步能拦住 80% 的标注错误。3.3 数据增强与负样本处理监控场景里我常用的增强有三类颜色抖动亮度饱和度各调 ±20%模拟不同时段的曝光Mosaic 拼图把四张图拼成一张增加小目标密度和上下文多样性随机透视对画面做轻微拉伸模拟摄像头角度偏差。增强幅度不要过大不然模型学到的是“扭曲的画面”到了真实监控反而失控。负样本必须单独处理。我在工地监控项目里花了一天时间从 24 小时录像里抽出来上千张“空场景”帧没人的路面、树荫下的墙壁、夜晚灯光下的操场。把这些帧混进训练集模型才学会“什么都没发生的时候别输出”。比例上我按正负样本 8:2 来配负样本太少误检高太多则模型变得保守真实目标也漏掉。如果你发现误检集中在某个背景区域就针对性多抽那个区域的空间帧这个操作对误检率的改善比换模型还明显。4. 训练落地参数怎么设、损失怎么盯、崩在哪里数据集整理好之后接下来就是训练。这一章是最容易“看着教程走实际翻车”的部分。我会按环境、命令、崩溃排查三个层次讲最后单独说混淆矩阵总和不为 1 的问题。4.1 环境配置与一键部署脚本拿到项目压缩包后第一件事是建独立环境。Python 版本我建议 3.10PyTorch 按你的 GPU 驱动版本装。下面是一个最小可用的环境安装脚本# 解压项目包先看有没有 requirements.txt unzip -q based_on_yolo_monitor.zip -d yolo_monitor cd yolo_monitor # 创建独立环境避免污染服务器上的其他项目 conda create -n yolo_monitor python3.10 -y conda activate yolo_monitor # 先装 PyTorch再装 YOLO 训练工具 conda install pytorch torchvision pytorch-cuda12.1 -c pytorch -c nvidia pip install -r requirements.txt # 如果包里有 requirements.txt没有就 pip install ultralytics这里的关键是pytorch-cuda版本要和你的 NVIDIA 驱动匹配。如果驱动只支持 CUDA 11.x就不要硬装 12.1否则torch.cuda.is_available()返回 False你会在 CPU 上白白训几天。装完后执行python -c import torch; print(torch.cuda.is_available())看到 True 再往下走。4.2 训练自己的数据集三条命令和必调参数YOLOv8 的训练入口统一是yolo命令。先写一个数据描述文件放在项目datasets/monitor/下path: ./datasets/monitor train: images/train val: images/val nc: 3 names: [person, car, fire]然后启动训练yolo train datamonitor.yaml modelyolov8s.pt epochs120 imgsz960 batch16 device0imgsz是训练分辨率监控小目标多我建议至少 960有显存直接上 1280。batch看显存V100 32G 可以开到 64普通 12G 显卡开 16 到 24。epochs我一般先跑 100120如果 val loss 已经收敛就提前停监控场景不是叠 epoch 越多越好超过 200 反而容易过拟合背景纹理。训练过程中要盯两个曲线train/loss是否平滑下降metrics/precision(B)和metrics/recall(B)是否同步上升。如果 precision 涨 recall 掉就是阈值偏好问题了先别慌看测试时的混淆矩阵再决定。4.3 损失函数和训练中 BN 崩溃现象与处理训练中常见的一个翻车是 loss 突然变成 NaN或者显存占用没变但精度曲线断崖。有一个专门名词叫“BN 崩溃”BatchNorm 层的均值方差被极端值带飞后面所有层输出都变成 NaN。常见触发原因是学习率太大、batch 太小、或者混合精度在个别层上不稳定。解决办法按优先级来# 降低学习率 用 AdamW 拉长 warmup yolo train datamonitor.yaml modelyolov8s.pt epochs120 imgsz960 batch16 \ optimizerAdamW lr00.001 warmup_epochs5 device0如果这样还炸就关掉混合精度yolo train datamonitor.yaml modelyolov8s.pt epochs120 imgsz960 batch16 ampFalse device0我的经验是 batch 小于 8 时优先关 AMPbatch 能开到 16 以上再尝试 AMP。BN 崩溃还有一种表现是 loss 周期性尖峰比如每几十步跳一下这通常是数据批次里偶发一张异常图全黑或全白建议把那批图找出来删掉比调参更快。4.4 混淆矩阵总和为什么不为 1别再被这个现象卡住训练结束后你会在验证输出目录里看到confusion_matrix.png很多新同学数格子发现每行加起来不是 1担心模型有问题。实际上这是归一化方式造成的YOLO 的混淆矩阵按“真实类别”那一行做归一化因此每行总和是 1但列总和不一定有的版本还会把 background 作为额外一类格子里有被当成背景的目标会让数字更“对不上”。真正要关心的是对角线数值你把每类错到了哪里。比如person行里background列的值高说明“人没被框出来”已经变成背景漏检反过来background行里person列值高就是树影被当成人。我一般在训练后跑一次yolo val把输出的混淆矩阵和 curves 图翻一遍确认误检的主要方向再决定是加负样本还是调阈值。5. 部署与边缘排查监控误检率高的 4 个排查方向模型训练得漂亮到了边缘设备上又是另一回事。无论是 RK3588 盒子、Jetson Nano 还是树莓派都会遇到同一个问题单帧跑起来没问题连着跑两个小时误检率高到告警刷屏。这一章是我认为整个监控项目最值钱的部分。5.1 现象误检率高先分清是误报还是漏报误检率高先不要急着改模型先把告警记录和视频回放对一下告警里真正是人/车的比例有多高把“没人报成人”和“有人没报出来”分开统计。很多情况下是同一目标被连续几十帧重复告警看起来是误检率高其实只是事件去重没做。我见过最夸张的一次一个路灯在阳光下被当成 15 个“人”告警系统 5 分钟发了 80 条消息纯粹是缺了持续帧确认和多目标跟踪。5.2 排查方向一推理分辨率跟不上小目标现象监控画面里人只有三四十像素高预览框里有截图里也有就是模型不输出或者树的纹理被细节放大后反被误认为人。原因通常是推理分辨率被锁在 640。YOLO 训练用的imgsz960部署时就必须用同一个尺寸如果边缘设备跑不动宁可降低抽帧频率也要保持分辨率。推理分辨率调整一行代码就能看效果results model(frame, imgsz1280, conf0.25, iou0.45)imgsz提升后小目标在原图上对应的像素更多特征更明显。代价是耗时增加Jetson 这类设备上可能从 20ms 涨到 60ms但监控场景每 3 帧抽一次完全扛得住。如果 1280 还是跑不出小目标就该考虑 SAHI 切片推理了把原图切成 640 的块分别检测再合并结果这是工程上对付小目标的最后手段。5.3 排查方向二NMS 阈值和类别不均衡现象一个行人身上同时出现三四个框或者两个人走近被框成一个。原因是 NMS 的iou阈值没调好。iou太低会把重叠框都保留太高会合并掉相邻真实目标。我一般的起点是conf0.25, iou0.45监控场景如果误检多先把conf拉到 0.35看漏检涨不涨。参数对应关系可以参考参数值调大值调小conf误检少漏检多漏检少误检多iou重叠框合并少可能多框重叠框合并多可能漏小目标类别不均衡也会在 NMS 这里暴露。安全帽检测项目中head 类别样本远多于 helmet模型会把“没戴帽子的人头”也拼命输出。解决不是只调阈值而是去数据集里给少数类补样本或者对少数类做重复采样让 loss 不那么偏向多数类。5.4 排查方向三输入源与光照切换现象白天一切正常晚上或傍晚误检突然变多画面明显偏暗噪点变大。这是监控最容易翻车的场景训练集里白天帧太多模型学到的是“明亮环境下的人形纹理”到了夜间就开始猜。摄像头自身的自动白平衡、自动曝光会让同一位置在不同时段呈现完全不同色调这加剧了分布偏移。我的处理分两步。第一步采集数据时专门抽出夜间帧加进训练集第二步部署时如果摄像头支持把曝光模式固定让画面亮度不要频繁跳变。夜间误检高还有一个常见来源飞虫和雨滴。给 YOLO 送帧前可以把小面积高速目标过滤掉但这个不能靠阈值瞎试最好结合帧间差来判断目标是否在相邻帧连续移动。夜间帧采集可以用 ffmpeg 定时截帧省得写脚本# 每 30 秒存一帧连续存 1 小时覆盖天黑到更黑的过程 ffmpeg -rtsp_transport tcp -i rtsp://camera_ip -vf fps1/30 -t 3600 night_frames/%06d.jpg-rtsp_transport tcp很重要UDP 传输在弱网下会产生花屏和丢帧截出来的图脏反而污染训练集。5.5 排查方向四TensorRT/ONNX 量化的校准集没覆盖夜间现象导出 FP16 后精度正常转成 INT8 后误检率飙升甚至有些类别完全不输出。这是量化校准集与真实场景不匹配。INT8 量化需要几百张“有代表性”的图片计算激活值分布我见过有人用 COCO 图片做校准集最后监控画面里的树影全部被量化噪声放大成了人形。先导出 FP16 的 ONNX确认精度没问题再做 INT8 校准yolo export modelbest.pt formatonnx dynamicFalse opset12导出后如果要在 TensorRT 里转 engine校准集一定要从监控视频里抽并且白天、傍晚、夜间各占三分之一数量 300 到 500 张足够。如果在 RK3588 的 NPU 上跑优先用 FP16别为了省那点带宽硬上 INT8监控告警是三秒的事不是跑大模型推理服务量化的收益不值得拿误检率换。我的血泪经验是边缘设备上大部分误检都不是模型问题而是量化后特征分布彻底变了。6. 进阶用法把单帧检测变成监控事件最后这一步是把“框”变成“事件”。单帧检测结果永远是上下文无关的而监控系统需要的是“有人进入仓库”“在门口逗留太久”这样的事件。做法是给检测结果加一个轻量跟踪器和持续帧确认。我用一个简单的 IOU 跟踪器给每个检测框分配 ID然后要求同一 ID 连续出现至少 5 帧才触发。触发后进入 10 秒静默期这期间不再重复告警。事件确认逻辑可以浓缩成if det.conf 0.35 and track.age 5 and roi.contains(det.center): if time.time() - last_fire_at 10: fire_event(det) last_fire_at time.time()track.age是跟踪器维护的连续帧数roi.contains判断检测中心是否落在告警区域。这里的关键是last_fire_at静默期能有效防止告警风暴。我最早图省事单帧直接告警晚上树影一晃就给我框出几十个“人”加了 5 帧确认和静默期后误报量降到原来的十分之一。验证这套规则也很直接把录好的 24 小时监控视频离线重放统计每个阈值下的 precision 和 recall画一条 F1 随conf变化的曲线选 F1 最高的点作为上线参数。不要只看单帧 AP监控用户在意的是“一天收到几条假告警、漏掉几条真告警”这两个数字只有跑完一整天视频才能算出来。按这个流程做完方案里的模型、阈值、告警规则就都有一组可解释的数字支撑后续改摄像头位置或换设备也能快速复现。希望帮到你。本文还有配套的精品资源点击获取