简介这份基于YOLOv8的旅游景区人流预警系统完整项目面向计算机视觉、人工智能及电子信息等专业的在校学生适用于毕业设计、课程设计与初期项目演示解决景区重点区域行人密度实时检测与超限预警问题。压缩包共97个文件以70个Python源码文件为主覆盖模型训练、检测服务、UI可视化页面等完整功能模块另含训练好的pt模型权重、配置xml文件、数据集说明txt及演示mp4视频整体约24.21MB按功能目录组织简单配置即可运行。现有41人学习使用。项目附带完整数据集与部署教程运行后可直接产出核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图等评价结果涵盖从数据准备、模型训练到可视化呈现的全流程闭环既适合答辩展示也便于在源码基础上替换数据集或调整网络结构做进一步算法优化。1. 基于YOLOv8的旅游景区人流预警系统毕设选题里的硬骨头还是能跑通的真项目游客密度过大引发踩踏风险是景区管理一直想解决又很难落地的老问题。摄像头到处都是但值班员盯着几十路画面根本看不过来。市面上所谓人流统计系统要么是红外对射只能数通道人数要么依赖手机信令数据滞后十分钟。直到YOLOv8这类端侧目标检测模型成熟才让“画面里到底有多少人”这件事有了低成本实时解。这套《基于YOLOv8的旅游景区人流预警系统》解决的正是这个问题用普通摄像头画面做实时行人检测与计数超过预设阈值就触发告警把“事后看录像”变成“事发前干预”。它适合两类人——做毕设或课程设计的学生以及真的想在小规模景区、园区试水智能安防的从业者。难点不在模型本身而在数据集清洗、计数逻辑和可视化联调这三道坎。2. 选型逻辑与部署环境为什么是YOLOv8以及从裸机到跑通第一帧推理2.1 为什么是yolov8而不是更早的v5或更新的v11目标检测模型迭代很快单论精度和速度YOLOv8在2024年之后已经不是绝对榜首v11、v12都有各自的改进。但选型不能只看跑分要看生态完整度和踩坑成本。YOLOv8最大的优势是Ultralytics官方把训练、验证、导出、部署的工具链全打通了一个pip install ultralytics就能拿到预训练权重和完整的API这对毕设项目来说是决定性的——你不需要自己写非极大值抑制NMS的后处理逻辑也不用为数据集格式适配折腾太久。v5的代码风格偏工程化但API不够统一v11虽有新特性但社区积累的教程、踩坑笔记、数据集转换脚本远不如v8丰富。一套系统要在一个月内从零跑到界面演示选v8是最稳的路径这也是标题里点名yolov8的原因。从模型体量看官方提供n/s/m/l/x五档。做景区人流预警我建议直接选yolov8n.pt或yolov8s.pt。景区摄像头通常架在高处俯拍行人目标小、密度大照理说模型容量越大越好但人流预警追求的是“每秒能处理几帧”而不是“单帧精度多两个点”。n模型在CPU上能跑到约10-15 FPSs模型在GTX 1660 Ti这类显卡上能到30 FPS以上。如果部署机器是老式工控机n是唯一现实的选择。2.2 从裸机到能跑yolov8的最小环境配置环境配置是这套系统第一个劝退点。很多人卡在CUDA、cuDNN、PyTorch版本不匹配上实际上yolov8环境配置比早期版本宽容得多。PyTorch 2.x对CUDA版本要求已经放宽只要显卡驱动够新用默认的cu121轮子基本能跑。纯CPU环境也一样Ultralytics官方在Ubuntu 20.04上CPU版本实测可用只是推理速度掉到每秒两三帧。# 创建独立虚拟环境避免把系统Python搞乱 conda create -n yolo python3.10 -y conda activate yolo # GPU版根据显卡驱动选CUDA轮子12.1是兼容性最好的版本 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # CPU版直接装默认包即可无需额外参数 pip install torch torchvision # 安装ultralytics本体会自动带起opencv、numpy等依赖 pip install ultralytics装完先跑一个最小验证确认模型文件和推理链路没问题再碰自己的业务代码。from ultralytics import YOLO # 首次运行会自动下载yolov8n.pt国内网络可能较慢 model YOLO(yolov8n.pt) # 用官方示例图跑一次推理source可以是图片路径、视频路径或摄像头ID results model.predict( sourcehttps://ultralytics.com/images/bus.jpg, imgsz640, conf0.25, verboseFalse, ) print(len(results[0].boxes)) # 检测到的目标数量这里三个参数值得说透。imgsz640表示输入分辨率景区俯拍画面中行人占的像素很少如果整帧缩到640远处的人可能只有十几个像素后面会专门讲怎么调整。conf0.25是置信度阈值低于这个值的目标会被丢弃。verboseFalse关闭逐帧日志不然跑视频流时终端会被刷爆。GPU和CPU环境差异很大习惯上先跑这张图确认后端是CUDA还是CPU。2.3 判断推理速度是否达标的基准测试方法环境装好了不等于能上线。部署前必须做一次基准测试搞清楚这台机器在什么分辨率下能跑多少帧不然界面做完了才发现卡成PPT返工成本极高。# 用自带benchmark命令测速会自动尝试多种输入尺寸和半精度 yolo benchmark modelyolov8n.pt imgsz640 halfFalse # 更直观的方式直接压一段本地视频看实测耗时 python - EOF import time from ultralytics import YOLO model YOLO(yolov8n.pt) cap cv2.VideoCapture(test.mp4) start time.time() frame_count 0 while True: ret, frame cap.read() if not ret: break model.predict(frame, imgsz640, verboseFalse) frame_count 1 end time.time() print(f实测FPS: {frame_count / (end - start):.2f}) EOF测速结果直接决定视觉方案的调整方向。如果是GTX 1660 Ti及以上显卡yolov8s在1280分辨率下能稳定跑到20 FPS以上如果只有CPU就老老实实用yolov8n加640分辨率。这个决策要在写代码之前做而不是等项目框架搭好再回头换模型。另外注意halfFalse半精度推理在部分老显卡上会掉精度甚至报错只有TensorRT部署时才值得开。3. 数据集准备与训练参数景区人流场景需要什么样的标注数据3.1 直接下载现成数据集还是自建标注标题里带了“完整数据集”但拿到手的zip文件大概率是通用行人检测数据比如COCO的子集或者某公开行人数据集。直接拿来训练能不能用能用但效果会打折扣。景区摄像头是俯视角度而COCO数据集大多是平视角度的行人照片目标姿态、遮挡形态、光照条件差异很大。我一般会建议混合策略用现成数据集做首轮训练让模型先学会“人”的基本形态然后去景区场景截取半小时监控画面用labelme标注两三百张俯拍行人图片合并进原数据集做二次训练。这样才能真正解决俯拍场景下模型把头顶、背包误检成人的问题。数据集目录结构按YOLO格式组织dataset/ ├── images/ │ ├── train/ # 训练图片 │ └── val/ # 验证图片 ├── labels/ │ ├── train/ # 与图片同名的txt标注文件 │ └── val/ └── data.yaml # 数据集配置文件每张图片对应一个txt文件每行格式是类别 x_center y_center width height坐标全部归一化到0到1。只有一个人体类别的话txt里每行就是0 0.5 0.4 0.05 0.1这种形式。data.yaml内容如下path: dataset train: images/train val: images/val names: 0: person3.2 用labelme标注数据并转成yolov8训练格式很多人标注完才开始查转换脚本浪费时间。正确流程是先定好labelme的标注规范再批量导出。labelme标注用于yolov8训练的转换脚本并不复杂自己写一版最稳妥。import json import os from pathlib import Path def labelme_to_yolo(labelme_dir, output_dir, class_map): labelme的json标注转YOLO txt格式 class_map: {person: 0} 类别名到id的映射 for json_path in Path(labelme_dir).glob(*.json): with open(json_path, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] txt_path Path(output_dir) / f{json_path.stem}.txt with open(txt_path, w, encodingutf-8) as out: for shape in data[shapes]: if shape[label] not in class_map: continue points shape[points] # labelme的点格式是[[x1,y1],[x2,y2]]转成左上右下 x_min min(p[0] for p in points) x_max max(p[0] for p in points) y_min min(p[1] for p in points) y_max max(p[1] for p in points) # 归一化到0-1区间 x_center (x_min x_max) / 2 / img_w y_center (y_min y_max) / 2 / img_h width (x_max - x_min) / img_w height (y_max - y_min) / img_h cls_id class_map[shape[label]] out.write(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}\n) class_map {person: 0} labelme_to_yolo(labelme_annotations, dataset/labels/train, class_map)这段转换逻辑有四个边界坑。一是labelme允许画多边形框转换时只取了外接矩形如果标注时框得松训练时会把周边的背景也学进去二是imageWidth和imageHeight必须从json里读不能假设和图片实际尺寸一致有些工具会自动缩放三是坐标值必须是浮点数写成整数会导致归一化出错四是txt文件名必须和图片完全一致包括不带后缀的主名否则训练时匹配不上。标注建议从密集人群区域开始因为稀疏区域模型本来就容易检对密集遮挡才是俯拍场景的难点。3.3 训练命令中必调的参数与损失曲线判断标准训练命令本身不长但参数含义不搞清楚训练完也只会看个acc出了问题不知道怎么调。yolo detect train \ datadata.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16 \ patience15 \ optimizerAdamW \ lr00.001 \ augmentTrue \ projectruns/train \ namescenic_densitypatience15是早停机制连续15轮验证集损失没下降就自动停止防止过拟合。imgsz640要和后续部署推理时保持一致训练和推理分辨率不一致会导致精度下降。batch16受显存限制12G显存跑yolov8n一般能到32以上显存不够就调低。augmentTrue对行人检测很有用尤其是随机翻转和HSV变换能缓解景区早晚光照差异大的问题。训练结束后看runs/train/scenic_density/results.png里的三张曲线。第一张是train和val的box_loss正常情况两条线都下降且最终贴近如果train降而val曲线反弹是过拟合信号此时应该加大数据增强或者减少epochs。第二张是cls_loss这个类别只有一类不太会出问题。第三张是mAP50曲线关注最终值是否达到0.6以上——俯拍小目标的mAP通常偏低0.6已经能支撑预警系统不用追求0.9。4. 从检测到计数预警的完整链路区域过滤、人数统计与阈值分级4.1 在检测框之上叠加区域规则不是画面里所有人都算数模型输出的是一堆(x1, y1, x2, y2, conf, cls)检测框但景区预警的逻辑不是“画面里有人就告警”而是“核心区域人流密度超标才告警”。比如检票口、观景台、狭窄栈道需要重点监控而停车场、办公楼区域根本不用管。实现方式是预定义ROI多边形只统计检测框中心点落在区域内的行人。所有配置写在一个JSON里避免硬编码。import json import numpy as np def load_config(config_pathalert_config.json): with open(config_path, encodingutf-8) as f: return json.load(f) def point_in_roi(point, roi_polygon): point: (x, y) 检测框中心点 roi_polygon: [[x1,y1],[x2,y2],...] 区域多边形顶点 return cv2.pointPolygonTest(roi_polygon, point, False) 0 def filter_by_roi(detections, roi_polygons): detections: 模型输出的检测框列表每项是[x1,y1,x2,y2,conf,cls] 只保留中心点在任意ROI区域内的检测框 valid [] for det in detections: x1, y1, x2, y2, conf, cls det cx (x1 x2) / 2 cy (y1 y2) / 2 for polygon in roi_polygons: if point_in_roi((cx, cy), np.array(polygon, dtypenp.float32)): valid.append(det) break return validROI坐标用原图像素坐标因为YOLO输出的检测框坐标默认就是原图尺寸。实际部署时要注意摄像头画面可能带黑边或裁剪ROI必须在真实可见区域内否则统计结果会异常。另一个细节是检测框只被一个ROI捕获处理重叠区域时避免重复计数——上面代码里命中一个区域就break不会重复追加。4.2 人数平滑与阈值分级直接拿单帧计数会把人吓死单帧计数的抖动非常剧烈一个人弯腰系鞋带、一帧遮挡人数可能从80瞬间跌到60。如果直接用原始帧数做预警值班室的告警声会响成连续剧。常规做法是维护一个滑动窗口取最近N帧计数的中位数或指数移动平均作为“当前人数”。用中位数比均值更抗噪但延迟略高指数移动平均响应快且平滑用它的居多。from collections import deque class PeopleCounter: def __init__(self, window_size15, alpha0.6): window_size: 滑动窗口帧数 alpha: 指数平滑系数越大越跟手越小越平滑 self.window deque(maxlenwindow_size) self.smooth_count 0 self.alpha alpha def update(self, raw_count): 每帧调用一次传入该帧检测出的人数 self.window.append(raw_count) median_count sorted(self.window)[len(self.window) // 2] # 中位数和指数平滑结合兼顾快速响应与抗抖动 self.smooth_count self.alpha * raw_count (1 - self.alpha) * self.smooth_count return int(self.smooth_count) counter PeopleCounter(window_size15, alpha0.6) for detection_count in frame_counts: alert_count counter.update(detection_count) # 三级预警黄色60人橙色100人红色150人 if alert_count 150: level red elif alert_count 100: level orange elif alert_count 60: level yellow else: level green阈值参数不是拍脑袋定的。正确姿势是拿一周监控视频离线回放统计每个ROI在不同时段的实际人数分布取峰值的80%作为黄色线峰值的110%作为红色线。alpha同样需要现场调0.6适合人流量快速变化的出入口0.3更适合缓慢积压的观景平台。平滑处理后从“红色告警”恢复到“绿色”也需要一个滞后时间我一般在代码里加3分钟的冷却期避免反复抖动。4.3 视频流接入RTSP还是本地视频帧率缓冲如何处理景区摄像头一般是RTSP流。接入时最大的坑不是协议本身而是RTSP拉流不稳定——网络抖动导致cv2.VideoCapture.read()阻塞或返回空帧。方案是加一个独立的拉流线程把帧放入带长度的缓冲队列检测线程从队列取帧两者解耦。队列满时丢最老的帧保证检测永远处理最新画面。import threading import queue import cv2 class StreamReader: def __init__(self, rtsp_url, queue_size3): self.cap cv2.VideoCapture(rtsp_url) self.frame_queue queue.Queue(maxsizequeue_size) self.running True self.thread threading.Thread(targetself._read_loop, daemonTrue) def _read_loop(self): while self.running: ret, frame self.cap.read() if not ret: # 拉流失败重连sleep防止死循环刷屏 self.cap.release() self.cap cv2.VideoCapture(self.cap.getBackendName()) threading.Event().wait(1.0) continue if self.frame_queue.full(): try: self.frame_queue.get_nowait() # 丢最老的帧 except queue.Empty: pass self.frame_queue.put(frame) def get_frame(self): try: return self.frame_queue.get_nowait() except queue.Empty: return None def start(self): self.thread.start()queue_size3意味着最多缓存3帧检测速度慢的时候自动丢帧保证界面显示延迟最低。这个参数很关键调大了内存占用高且画面延迟严重调小了网络抖动时队列容易空。5. 避坑指南景区人流预警系统最常见的5个翻车现场5.1 远处人群糊成一团计数结果比实际少一半现象摄像头装在制高点俯拍广场远景人群是一个密集的点群模型只检出三五个人但现场实际有五六十人。原因YOLOv8默认输入分辨率640远景行人只有十几个像素特征信息严重不足。这不算模型bug是输入分辨率与目标尺寸不匹配。解决推理时把imgsz调到1280甚至1536会显著改善小目标召回率但推理时间会翻倍。实操中先用脚本对比640和1280在同一视频上的检测框数量如果提升明显考虑降级用yolov8s配合1280分辨率如果提升不明显说明问题不在分辨率而在数据集里小目标样本太少需要补充标注远景密集人群图片。5.2 夕阳逆光时画面全是“幽灵人”现象傍晚太阳直射摄像头画面整体泛白模型把光影斑驳的地面、树叶影子误检成人人数突然暴涨触发误报。原因景区摄像头逆光场景的对比度极低训练数据里缺少这类光照样本模型学到了纹理特征却没学会“人的形状约束”。解决数据层面从监控录像里截取早晚各一小时画面标注后加入训练集并开启augment的HSV扰动。工程层面在检测前加一步简易白平衡或者调高conf阈值到0.35过滤低置信度误检。最立竿见影的是后者但治标不治本最终还得靠数据补强。5.3 人群遮挡严重时同一人反复计数现象人流密集时一个人被前面的人挡住两三秒重新出现后又被计了一次导致人数缓慢爬升30分钟比实际多算20%。原因纯帧级检测没有跨帧关联意识每帧都独立判断“这是新的人还是刚才那个人”。解决引入跟踪器如ByteTrack或StrongSORT对检测框做ID关联ROI计数改为统计“去重后的唯一ID数量”。注意ByteTrack在密集场景下帧率损耗约5-10%但为了消除重复计数值得。如果不想引入跟踪可以降低采样频率到每2秒检测一次并做相邻帧检测框IoU去重误计率也能压下一半。5.4 视频流丢帧导致计数曲线阶梯状跳变现象界面显示人数不是平滑曲线而是每隔几秒突然跳一下曲线呈阶梯状。原因RTSP流本身丢帧或者检测线程来不及处理每处理一帧实际间隔不固定人数按帧累计后呈现锯齿。解决不要把检测帧率和计数逻辑绑定。计数模块应该拿时间戳而非帧号做基准人数变化速率按时间归一化。另外把前端曲线改为每5秒聚合一次取平均画出来的图会平滑很多。如果丢帧严重先检查交换机端口是否是百兆视频流码率超了就会周期性丢包。5.5 导出ONNX到部署端后精度莫名其妙掉了现象Python环境里跑得好好的导出ONNX后用ONNX Runtime推理同一段视频人数少了8%。原因PyTorch和ONNX Runtime的算子实现有细微差异归一化、Resize插值算法不一致也可能是 exported模型默认开启了dynamicTrue导致输入形状变化时某些算子走了慢速分支。解决导出时固定输入尺寸并开启opset12以避开低版本算子问题导出后用模型自带的val命令重新评估mAP和PyTorch结果对比确认无损再部署。TensorRT部署时尤其注意要重新跑一次校准数据集不要直接拿.engine文件当黑匣子用。6. 可视化界面与部署实操Qt界面线程卡顿的解法以及这个方向值不值得投入可视化界面看起来是最容易的部分实际是最容易翻车的部分。用PyQt5或PySide6做实时画面和人数曲线展示核心问题只有一个检测是CPU/GPU密集型操作不能放在UI主线程里执行否则窗口拖动时画面冻结、人数曲线不刷新。标准解法是拆三条线程——拉流线程只管取帧检测线程只管推理并把结果放进队列UI线程通过QTimer每隔50毫秒从结果队列取一次最新数据刷新界面。跨线程用信号槽通信而不是共享可变变量。class DetectWorker(QObject): result_ready pyqtSignal(dict) def __init__(self, model_path, rtsp_url): super().__init__() self.model YOLO(model_path) self.stream StreamReader(rtsp_url) def run(self): self.stream.start() while True: frame self.stream.get_frame() if frame is None: threading.Event().wait(0.1) continue detections self.model.predict(frame, imgsz1280, conf0.25, verboseFalse) # 组装人数统计和预警等级通过信号发到UI线程 self.result_ready.emit({frame: frame, count: len(detections[0].boxes), level: green})UI线程收到信号后更新QLabel和曲线控件如此GTX 1660 Ti上跑1280分辨率约0.03秒一帧界面每秒刷新约20次交互流畅不卡顿。如果嫌PyQt5布局麻烦也可以改成Flask加WebSocket的方案后端跑检测线程前端用ECharts画人数曲线浏览器直接访问免安装客户端更适合课设演示。这套系统值不值得做我的判断是作为毕设它技术栈完整、演示效果好从模型训练到系统集成的链路清晰比做一个纯算法demo的答辩素材厚实得多。作为实际产品它仍只是预警中台的一个感知层距离真正可商用还差事件归档、多摄像头联动、广播疏散联动这些业务模块。如果你打算把它改成生产级系统优先补跟踪器的跨镜重识别和告警的语音播报联动这两块的业务价值比继续磨精度更大。做这类项目我的个人习惯是先在服务器上跑通一次完整的离线回放测试再进现场联调现场摄像头角度、光线、人流密度跟自己的测试环境永远不一样留半天时间做参数调整是必须的。希望这些落地的细节能帮你在做这个项目时少走几段弯路。本文还有配套的精品资源点击获取