简介基于YOLOv8的社区高空抛物监测系统是一份面向计算机视觉方向毕业设计、课程设计及项目初期演示的完整源码包主要解决高空抛物实时检测与可视化监测问题适合有一定Python和深度学习基础的学生或开发者直接部署也支持在此基础上二次扩展。压缩包总大小15.91MB共包含8个文件其中3个Python脚本分别对应可视化页面、视频检测和模型训练3个模型权重文件可用于推理或继续训练另有2个文本说明提供部署教程与项目描述整体结构清晰便于快速定位。目前已有31人学习使用。作者测试运行无误项目可输出核心指标曲线、混淆矩阵、F1曲线、精确率-召回率曲线、验证集预测结果及标签分布图能为毕业设计答辩提供完整实验证据同时部署说明有助于解决环境配置与训练细节问题是拿来即可运行的实用型资料。1. 社区高空抛物监测系统为什么它比普通检测告警难做一个量级YOLOv8 做社区高空抛物监测第一反应都是「拿模型识别个物体有什么难的」真正把摄像头装到楼顶往下拍才知道这个场景的坑有多深检测目标通常只有几十个像素、仰拍视角下物体形变严重、白天逆光晚上噪点、楼下还有行人车辆树木当背景。偏光片、红外补光、长焦镜头这些硬件问题先放一边单说软件侧一个能真正跑起来的社区高空抛物监测系统至少包含四块能训练的数据集、调过参数的 YOLOv8 模型、把检测结果接住的后处理逻辑、以及一个让人看得懂结果的可视化界面。这套东西做完既是一个能落地的监控系统也是一份结构完整的毕设或课程设计。本文沿着这个标题把方案拆开讲数据集怎么从零攒出来训练参数按什么逻辑调模型怎么导出成能接摄像头的推理服务可视化界面怎么把「第几秒有东西掉下来」变成一条可查的记录。最后用一整章写排查记录每一条都是实际跑系统时踩过的坑。2. 用 YOLOv8 检测高空抛物先解决两个比模型更关键的选型问题2.1 用目标检测还是视频异常检测为什么我选 YOLOv8高空抛物在计算机视觉里有两个技术路线一是把它当异常事件做视频帧预测、光流突变检测二是把它当目标检测做识别「画面里有一个下落物体」。异常检测方案的优点是理论上能捕获「没见过的东西」但实际落地会翻车——社区场景里树叶飘落、飞鸟掠过、晾晒衣物被风吹动都会触发误报光流法对静止摄像头还勉强可用稍微有点风就满屏告警。目标检测方案的优势是可控只识别我标注过的类别比如瓶、盒、袋、衣物把「天空中的坠落物」当成一类目标来训练。YOLOv8 选它的理由很直接——生态完整训练一条命令搞定导出 ONNX 后接部署没有心智负担社区里遇到的绝大多数报错都有现成解决方案适合教学也适合快速验证。白天误报还能通过阈值调晚上才是真正的问题。抛物物体在夜间几乎没有颜色信息只有轮廓和运动这时单帧检测根本不可靠我会在推理侧做「连续多帧追踪确认」而不是改模型结构——这个思路后面单开一节讲。如果你做的是毕设建议优先保证白天场景效果夜间做成「检测 追踪 告警确认」的加分项不要在夜间精度上死磕。注意别一上来就追求旋转框检测比如 mmrotate 里的 DOTA 系列方案。高空抛物物体在画面里确实是任意角度下落的但 YOLOv8 的水平框在目标只有几十像素时完全够用旋转框训练成本高、部署麻烦留着做论文创新点可以做系统主力不合适。2.2 YOLOv8 选哪个规格n/s/m 的取舍逻辑同样是 YOLOv8选错规格会让整个系统前功尽弃不是模型不准是「重了跑不动轻了压不住」。我一般按部署设备分三档部署设备规格理由树莓派 4B / 老 CPU 工控机YOLOv8n1080P 下勉强实时只能做低帧率巡检普通台式机GTX 1660Ti 级别/ Jetson Orin NanoYOLOv8s性价比最高单帧 20ms 以内毕设最常用服务器级别 GPU / 多路视频流YOLOv8m 及以上多路并发时 m 的精度优势能体现出来实测下来YOLOv8s 在高空抛物场景的性价比明显高于 n——n 在极小目标的检测上丢框严重而 m 在 1080P 输入下推理耗时翻倍精度提升却很有限。做毕设或课程设计YOLOv8s 是默认选项如果你打算部署到 rk3588 这类边缘设备n 的量化友好度更好但这是后面的优化方向先别影响当前选型。3. 高空抛物数据集自己做视角、清晰度与负样本决定了模型上限3.1 公开数据集为什么用不上自建数据要拍什么高空抛物没有像 COCO 或 ImageNet 那样的现成公开数据集。你查得到的高空抛物相关数据集要么是论文里的内部数据不公开要么是俯拍视角的室内模拟场景和真实社区楼顶摄像头的机位完全不同。这里直接说结论模型能不能用取决于你有没有按「真实机位视角」采集数据。真实社区的高空抛物摄像头通常装在楼顶边缘朝下斜拍仰角大、距离远、物体小。你拿手机站在楼上往下扔手机拍视频拍一两个下午就能攒出第一批素材——这不是学术方案是社区监控项目里最常用的做法。拍摄时注意三点。第一机位尽量模拟真实部署从 10 层以上往下拍拍到完整楼面物体从窗台出现到落地全程在画面里。第二覆盖不同光照上午顺光、中午顶光、傍晚逆光都要拍不然模型会在某个时段集体失效。第三物体类别按社区实际来最常见的是生活垃圾袋、饮料瓶、烟盒、用过的纸巾、衣物不要拍一堆钢材砖头——那更像工地场景。我一般建议至少覆盖 5 类目标其中「袋装垃圾」单独一类因为它在画面里占像素最多、也最容易识别错。提示拍摄时背景里的行人、车辆不用刻意避开。真实运行时的背景不会比拍摄时更干净把复杂背景当作数据的一部分比拍「干净素材」更有用。3.2 标注格式与 LabelImg 操作要点拍完视频后抽帧标注。抽帧时别每帧都标画面里物体几乎没动相邻帧的标注高度重复我一般按 10 到 15 帧抽一帧保证物体位置有变化就行。标注工具用 LabelImgYOLO 格式这是这类项目的主流搭配。具体操作步骤# 安装 LabelImgPython 3 环境 pip install labelImg labelImg # 启动后设置 YOLO 格式 # 打开标注界面后先在左侧选择 YOLO 格式再打开图片目录 # 快捷键 w 画框a/d 切换上一张下一张CtrlS 保存。 # 标注完会生成同名 .txt 文件内容是类别id 中心x 中心y 框宽 框高标注逻辑里有个细节对象坠落过程中画面里可能有虚影或残影特别是帧率低的时候物体拖出很长的轨迹。规则是「框住当前帧中最清晰的主轮廓」不要把残影包进去否则模型学到的特征会被拖影污染。标注完成后把图片和 txt 按 YOLO 目录结构组织。# 数据集目录结构YOLO 训练标准布局 dataset/ ├── images/ │ ├── train/ │ ├── val/ └── labels/ ├── train/ └── val/ # 在项目根目录写一个 data.yaml内容如下 train: ./dataset/images/train val: ./dataset/images/val nc: 5 names: [bottle, bag, box, cloth, other]3.3 用 SAHI 切片解决「目标太小」的硬伤高空抛物物体在 1080P 画面里经常只有 20×20 像素直接丢给 YOLOv8s 训练和推理效果很差。常见做法是引入 SAHISlicing Aided Hyper Inference把图切成重叠的小块分别检测再合并结果。训练侧可以先用 SAHI 切片后再训练推理侧集成 SAHI 做切片推理。from sahi import AutoDetectionModel from sahi.predict import get_sliced_prediction detection_model AutoDetectionModel.from_pretrained( model_typeyolov8, model_pathbest.pt, confidence_threshold0.4, devicecuda, ) result get_sliced_prediction( imageframe_0123.jpg, detection_modeldetection_model, slice_height512, slice_width512, overlap_height_ratio0.2, overlap_width_ratio0.2, )SAHI 的核心参数就三个切片尺寸、重叠率、置信度阈值。切片越小小目标越清晰但耗时成倍增加。我常用 512×512 配 0.2 重叠率在 1080P 图上约 9 个切片单张推理耗时约 60ms。如果你做实时视频流这个耗时不太乐观但做「事件触发后的二次确认」绰绰有余。注意切片后推理完会有一个「合并重复框」的过程SAHI 默认用 NMS 合并重叠区域的多余框。重叠率设得过高比如 0.5会导致同一个目标被多次检测框包围合并不当会出现框抖动所以别贪心0.2 够用。4. 训练与推理参数调优这几个参数决定系统翻不翻车4.1 用 Ultralytics 跑通训练yaml 配置与启动命令环境配置按下述步骤来假设你已有 CUDA 显卡环境且 PyTorch 已安装。# 安装 UltralyticsYOLOv8 官方训练框架 pip install ultralytics # 启动训练。关键参数已注释按自己的数据集规模调整 yolo detect train \ datadata.yaml \ # 数据配置指向 3.2 节的结构 modelyolov8s.pt \ # 预训练权重不要从零开始练 epochs100 \ imgsz1280 \ # 高空抛物是小目标图幅不要用默认 640 batch8 \ patience15 \ projectruns/detect \ nameparapet_exp1这里必须解释两个参数imgsz和patience。高空抛物目标小图像尺寸从 640 提升到 1280小目标的特征保留程度完全不同——代价是显存翻了约四倍8GB 显存只能勉强跑 batch8。如果显存不够优先降 batch不要降 imgsz这是血泪经验。patience是早停轮数15 轮没有提升就停避免无效训练浪费时间。训练完成后看三个指标就够了验证集 mAP0.5 有没有到 0.85 以上、小目标类别比如烟盒的 mAP 是不是显著低于其他类别、loss 曲线有没有在最后 20 轮还剧烈震荡。最后一个情况说明学习率太大或数据集噪声高先降到lr00.005再练一次。4.2 数据增强怎么调Mosaic 关闭与 Augment 参数Ultralytics 默认开了 Mosaic 增强这个参数在常规检测里是个好东西但高空抛物场景它反而是负优化——Mosaic 把四张图拼在一起训练目标会被进一步缩小而高空抛物的目标本来就只剩几十像素。我一般这样设置# augment.yaml训练时通过 cfgaugment.yaml 传入 mosaic: 0.0 # 直接关掉小目标经不起缩小 mixup: 0.0 # 同理关闭 hsv_h: 0.015 # 轻微色相扰动不要开大 hsv_s: 0.4 # 饱和度扰动模拟逆光/顺光变化 degrees: 10.0 # 轻微旋转模拟物体旋转下落 translate: 0.1 scale: 0.2 fliplr: 0.5有一个血泪参数degrees不要设超过 15。物体在下落时确实会旋转但旋转角度会在后续帧中连续变化模型看到了大角度旋转样本后会把「形状异常」也当成特征在背景噪点上产生大量误检。同样scale不要设成默认的 0.5高空抛物物体在下落中确实会变大靠近镜头但 YOLO 本身对多尺度有自适应过大的 scale 只会让模型更难学。提示训练集如果只有几百张图数据增强再精巧也救不回来。对高空抛物这种目标极小、场景单一的任务我更建议多拍几段视频抽帧而不是迷信增强。增强是「锦上添花」不是「雪中送炭」。4.3 损失函数和损失曲线怎么看、怎么改Ultralytics 在cfg/default.yaml里可以调分类损失和回归损失的权重但我不建议毕设阶段动它们。真正值得做的是记录并对比每次实验的损失曲线# 训练日志里能看到损失曲线的原始数据 # runs/detect/parapet_exp1/results.csv import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/detect/parapet_exp1/results.csv) plt.plot(df[epoch], df[train/box_loss], labelbox_loss) plt.plot(df[epoch], df[train/cls_loss], labelcls_loss) plt.legend() plt.savefig(loss_curve.png)有一个判断标准如果cls_loss到后期还在持续下降但box_loss已经走平说明模型在学「类别区分」而没在学「框得准不准」。这时候要去检查标注是否有大量偏移框而不是调损失权重——标注问题靠换损失函数是救不回来的。5. 把模型接进真实系统ONNX 导出、后处理与部署边界5.1 训练好的模型导出 ONNX 与推理脚本训练完得到的 best.pt 是 PyTorch 权重最终部署建议转 ONNX理由是不依赖 PyTorch 运行环境、CPU 推理也能跑、后续换 TensorRT 或 OpenVINO 方便。命令行导出yolo export modelruns/detect/parapet_exp1/weights/best.pt formatonnx \ imgsz1280 opset12 simplifyTrueopset别用太新12 即可兼容性更好simplify会去掉一些冗余计算图节点。导出后用 ONNX Runtime 推理import cv2 import numpy as np import onnxruntime as ort session ort.InferenceSession(best.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider]) input_name session.get_inputs()[0].name def infer(frame): img cv2.resize(frame, (1280, 1280)) blob img[:, :, ::-1].transpose(2, 0, 1)[None] / 255.0 outputs session.run(None, {input_name: blob.astype(np.float32)}) # YOLOv8 输出形状为 [1, 4nc, 8400]需要做转置后解析 preds outputs[0].transpose(0, 2, 1)[0] return predsYOLOv8 的输出是[batch, 4类别数, 8400]其中 8400 是三个尺度特征图的总预测框数。转置后每一行是[cx, cy, w, h, cls0_score, cls1_score, ...]。后续要做的是置信度过滤和 NMS非极大值抑制。Ultralytics 的推理脚本里自带后处理但如果走 ONNX 自己解析这两个逻辑必须自己实现或复用其它人的工具函数。常见做法是导出一个带 NMS 的 ONNX 版本或直接用 ultralytics 自带的 ONNX 推理封装。毕设阶段不建议纯手工实现 NMS除非你要写论文讲优化的故事。5.2 后处理如何用「连续帧确认」压住误报模型在单帧上的预测天然有抖动——行人手臂甩过、树叶挡了一下、云影扫过都可能导致单帧框出现所以系统后端必须有一个「确认机制」否则告警能把自己吵死。我常用的做法是目标追踪 帧数计数class ParapetTracker: def __init__(self, min_hits3, max_miss2): self.min_hits min_hits # 连续出现多少帧才触发告警 self.max_miss max_miss # 中间丢多少帧还能续上 self.tracks {} def update(self, detections, frame_id): alerts [] for det in detections: box det[:4] center ((box[0]box[2])/2, (box[1]box[3])/2) # 用中心点位置 框高做简单的跨帧关联 matched_id self._match(center) if matched_id is None: self.tracks[frame_id] {center: center, hits: 1, miss: 0} continue self.tracks[matched_id][hits] 1 if self.tracks[matched_id][hits] self.min_hits: alerts.append(self.tracks[matched_id]) return alerts这套逻辑里关键的两个参数是min_hits和max_miss。min_hits3表示物体在连续 3 帧里都被检测到才算一次有效事件max_miss2允许中间有两帧丢失适用于物体被窗台或晾衣杆短暂遮挡的情况。这两参数的值我建议从真实视频里测调min_hits5你会发现大多数真实抛物都被漏了因为小物体在快速下落中本来就会有丢帧。可以先用 1 跑一段视频看每帧检测结果再决定阈值。这个机制不是 YOLO 的检测模块但它是系统「可用」和「不可用」的分界线。5.3 部署到边缘设备要考虑的边界如果你要把系统部署到 Jetson Orin 或 rk3588 这类边缘设备能提前做的工作只有两个量化模型到 FP16 或 INT8以及优化预处理到推理到后处理的管线。GTX 1660Ti 这类消费级显卡上YOLOv8s ONNX Runtime 跑 1280 输入大约 30ms 一帧是流畅的但边缘设备上同样配置可能是 150ms 一帧这时要么降输入尺寸到 960、要么换 YOLOv8n、要么接受「每 5 帧推理一次」的低频巡检模式。毕设阶段建议先把推理、可视化在电脑上跑通部署优化当作加分章节写——先跑通再谈优化别把两个问题混在一起。6. 高空抛物系统的 5 条排查记录现象、原因与解决办法6.1 白天一切正常傍晚和晚上检测率骤降现象白天测试视频里能稳定检出的物体日落之后开始漏检真实抛物事件有接近一半没告警。 原因数据集里顺光和中 light 样本占绝对多数黄昏逆光和夜间低照度场景几乎没有覆盖。目标检测模型对光照分布极其敏感这不是模型结构的问题是训练分布问题。 解决补拍傍晚和夜间的数据并加入训练。如果夜间实在拍不到把白天图像做亮度扰动hsv_h 调高亮度只能算心理安慰不如接受「系统夜间降级运行」这个现实——把夜间置信度阈值从 0.4 降到 0.25提高召回、容忍误报靠连续帧确认机制压误报。6.2 误报扎堆出现在「行人手臂挥动」和「飞鸟掠过」现象系统每天误报三四十次回放告警截图发现大部分不是抛物。 原因连续帧确认机制只看「检测框有没有连续出现」没考虑「物体是否真的在下落」。手臂挥动产生的检测框位置几乎不动飞鸟轨迹是横向或斜向上的和抛物下落轨迹特征不符。 解决在后处理里加一个方向判断——连续帧中心点的 y 坐标必须递增向下移动且 x 方向偏移不超过一定比例。这个逻辑改动很小但能把误报数量削掉七成以上。具体阈值我常用 y 方向每帧位移至少 2 像素x 方向占比不超过 0.5你可以按自己的帧率调。6.3 训练时 CUDA 显存溢出out of memory现象batch16 直接报 CUDA OOM只能把 batch 降到 4 才能跑。 原因高空抛物场景里我建议的 imgsz1280 会让显存占用成倍上涨很多人忘了同步调整 batch 和 workers。 解决如果机器显存只有 8GBbatch8imgsz1280是安全配置想保持批量大把imgsz降到 960 或换 m 系列预训练权重注权重本身不省显存但可以让 loss 收敛更平滑从而允许提前早停减少后续实验次数。另外检查一下是否同时开了多个训练进程这种情况在实验室机器上很常见。6.4 模型训练完 loss 很低但实际视频里几乎检测不到小物体现象验证集 mAP 挺高但随手拍一段真实视频测小物体根本没框出来。 原因验证集和训练集来自同一批视频的抽帧机位、 时间段、背景都高度相关mAP 虚高。真实场景的背景、光照、目标尺度跟训练集有偏移。 解决留出「完全独立的测试视频」——可以是不同时段、不同楼栋方向拍的视频不能参与训练和验证。拿独立视频测才算数否则训练过程只是自嗨。这也是毕设答辩时最容易被人问倒的点你的模型换个场景还行不行6.5 中文路径导致的部署翻车现象推理脚本在 Windows 上跑报路径错误或者导出的 ONNX 加载失败。 原因Ultralytics 的缓存机制和 ONNX 加载在某些版本里对中文路径支持不友好路径里带中文就可能在某个隐蔽环节出问题。 解决项目路径全部用英文。这不是玄学是我在多个 YOLO 项目里踩到的共性坑包括训练、导出、PyQt 界面里加载模型每层都可能被中文路径坑一次。项目根目录直接放在D:\parapet_project下不要在桌面跑。7. 可视化界面与整系统验证把「能跑」变成「能演示、能交付」可视化界面我常用 PyQt5 搭配 OpenCV 实现。界面需要做到的几件事打开本地视频或连接摄像头、逐帧显示推理画面、实时标注检测框、抛物事件触发时保存告警截图和视频片段、统计今日告警次数。核心代码结构如下import sys import cv2 from PyQt5.QtWidgets import QApplication, QMainWindow, QLabel, QPushButton from PyQt5.QtCore import QTimer from PyQt5.QtGui import QImage, QPixmap class MainWindow(QMainWindow): def __init__(self): super().__init__() self.timer QTimer() self.timer.timeout.connect(self.process_frame) self.cap None self.model load_onnx_model(best.onnx) # 按钮绑定和布局代码省略核心是下面这层循环 self.timer.start(33) # 约 30FPS def process_frame(self): ok, frame self.cap.read() if not ok: self.timer.stop() return dets infer(self.model, frame) # 走 5.1 节的推理函数 frame draw_boxes(frame, dets) # 画框和置信度 self.show_frame(frame) # QLabel 显示这个界面里值得琢磨的是「告警联动」。当抛物事件触发时只弹一个框和声音提示远远不够降落地面的范围和抛物楼层是不存在的。更好的做法是触发告警时自动保存从事件开始前 2 秒到事件结束后的 2 秒片段同时截取首帧图存入告警列表供事后回查。这个功能在毕设答辩时非常加分因为它体现的是「系统思维」而不仅是「模型调参」——你告诉评委的不只是检测得准不准而是这件事从发生到取证是一整条链路。系统的验证方法也值得说清楚。训练完成后不要只用 mAP 自证我建议用一条 10 分钟的真实社区视频做端到端验证人工数出视频里实际发生的抛物次数比如 12 次系统检出 10 次算出召回率再统计误报次数比如 6 次算出每小时的虚警率。这两组数字比模型单帧 mAP 更能说明问题。这也是部署交付时双方都认可的标准。个人习惯上我做这类项目会先把「连续帧确认 方向判断」这个后处理逻辑当作项目的心脏模型反而是可替换的零件——哪天上更好的模型把权重文件一换后处理和界面原封不动。这个思路可以让你的系统不绑死在某个具体框架版本上。希望帮到你。本文还有配套的精品资源点击获取