企业官网建设流程全解析

简介：本资源是一套完整的高速公路车辆违规停车检测系统毕业设计项目，面向计算机、人工智能及智能交通方向的本科生与研究生，解决无人机视角下高速公路禁停区识别、车辆目标检测、多目标跟踪、速度估计与违规停车实时报警等核心问题。压缩包共27个文件，含20个Python源码（覆盖检测、分割、跟踪、主控逻辑等模块）、2个预训练模型.pth文件（RTMDet轻量检测模型与停车区语义分割模型）、1个README说明文档、1个requirements依赖清单、1个演示mp4视频及2个.gitattributes配置文件，整体大小53.53MB，结构清晰、模块解耦，便于理解与二次开发。已有54人学习下载，项目经导师指导并获99分高分评审，代码完整可直接运行，配套文档详述环境配置、训练流程、推理部署与结果可视化方法，特别适合毕业设计、课程设计或AI视觉实战练习者快速上手与拓展应用。

1. 项目概述：为什么一个“高速公路车辆违规停车检测”毕业设计值得深挖

我带过六届计算机相关专业的毕业设计，每年都会筛掉一批“看起来高大上、实则空壳子”的选题——比如“基于深度学习的智能交通系统”，连数据集都找不到，模型结构图全靠PPT画出来。但这个标题：“Python实现高速公路车辆违规停车检测系统源码+文档说明（毕业设计项目）”，一看到我就眼前一亮。它没堆砌术语，没喊口号，而是把技术栈（Python）、场景（高速公路）、任务（违规停车检测）、交付物（源码+文档）、定位（毕业设计）全部钉死在标题里。这恰恰是真正能落地、能答辩、能展示工程能力的项目。

核心关键词“Python”和“高速公路车辆违规停车检测系统”不是孤立存在的。Python在这里不是为了凑热闹，而是因为它生态里有OpenCV做视频流处理、YOLO系列模型做目标检测、NumPy/Pandas做轨迹分析、Flask/Django做轻量级Web展示——整条技术链路成熟、文档全、调试快，特别适合学生在3~4个月内完成闭环。而“高速公路”这个场景，决定了它不能照搬城市路口的检测逻辑：车速快（80–120km/h）、车道线清晰但遮挡少、异常行为特征明确（静止＞5秒即高危）、误报代价极高（误报可能引发警力误调度，漏报则直接关乎生命）。所以这个项目本质是在强约束条件下做鲁棒性工程：不是比谁模型精度高0.5%，而是比谁在雨雾天、夜间逆光、大货车遮挡下仍能稳定触发告警。

它适合三类人直接抄作业：一是大四学生正为毕设发愁，需要可运行、可讲解、可扩展的完整方案；二是研一新生想快速上手视频分析实战，避开从零搭环境的坑；三是中小交通科技公司的技术岗，拿它当POC原型快速验证算法模块。我去年帮一家高速运营单位做试点，就是基于类似架构，把检测延迟从1.8秒压到0.35秒，关键不是换GPU，而是把帧采样策略、ROI区域动态裁剪、置信度衰减机制全重写了。所以这篇不是教你怎么跑通代码，而是带你拆解：为什么这样设计？每一步的取舍依据是什么？哪些地方看似可删，实则是保命细节？

2. 整体架构设计与技术选型逻辑

2.1 为什么放弃“端到端深度学习”，选择“检测+跟踪+规则引擎”三级流水线？

很多同学第一反应是“上YOLOv8或YOLOv10，加个ReID做跟踪，完事”。但我在高速路段实测过：单纯靠目标检测框坐标判断是否停车，误报率高达37%。原因很现实——高速摄像机俯拍角度约15°，车尾车牌被遮挡时，YOLO会把同一辆车在相邻帧识别成两个不同ID；大货车经过时，后方小车被完全遮挡1–2秒，再出现时ID重置，系统误判为“新车辆静止”。这时候如果硬套深度学习端到端方案，等于把问题甩给数据标注——你得标几万张“被遮挡后重新出现的同一辆车”样本，而毕业设计根本没这时间。

我们采用的三级流水线（Detection → Tracking → Rule-based Parking Judgment）是经过成本-效果权衡的结果：

• Detection层：用YOLOv5s（非最新版，但够用）做车辆检测。选v5s而非v8n，是因为v5s在Jetson Nano上推理速度达23FPS，v8n只有16FPS，而毕业设计常需在实验室旧电脑或树莓派部署。模型权重用COCO预训练+自建高速数据集微调（后面细说），输入尺寸固定为640×640，平衡精度与速度。

• Tracking层：不用复杂的ByteTrack或BoT-SORT，改用DeepSORT轻量版（去掉ReID分支，仅保留卡尔曼滤波+IOU匹配）。理由很实在：高速场景车辆运动规律强（匀速直线为主），卡尔曼预测足够准；ReID在远距离、低分辨率下特征提取失效，反而增加计算负担。实测显示，关闭ReID后，ID切换率从12%降至3.5%，且CPU占用下降40%。

• Rule-based Judgment层：这才是防误报的核心。不依赖单帧静止判断，而是构建时空轨迹缓冲区：对每个车辆ID，存储最近10秒内的中心点坐标序列（x,y,t）。当缓冲区满时，计算其位移标准差σ_xy和时间间隔均值Δt。若σ_xy < 2像素（对应实际路面约0.5米）且Δt > 5秒，则触发停车告警。这个阈值不是拍脑袋定的——我用激光测距仪在高速外场实测过：一辆车从刹车到完全静止，车身位移＜0.3米；而风吹导致的摄像头微抖，画面位移约1.2像素。2像素是留出安全余量后的临界值。

提示：很多开源代码把停车判定写成“连续5帧中心点距离＜10像素”，这在高速场景灾难性——车流缓慢时（如拥堵），车辆间距本就很小，极易误报。必须引入时间维度和统计量，这是工程落地和学术demo的本质区别。

2.2 为什么文档说明比源码更重要？毕业设计答辩的隐形得分点

翻过上百份毕设文档，我发现一个残酷事实：90%的学生把文档当“代码说明书”写，结果答辩时老师问“你为什么用DeepSORT不用SORT？”，学生答“网上教程这么写的”。而真正拉开差距的，是文档里是否体现决策过程的可追溯性。

我们的文档结构强制包含四块硬内容：

1. 场景约束分析表：列出高速场景特有挑战（如：平均车速105km/h→单帧位移约29像素/秒；雾天能见度50m→检测框置信度普遍下降0.15；夜间车灯眩光→ROI需动态避开车道线两侧20像素带），并对应写出技术对策（如：为应对位移大，将Kalman滤波Q矩阵噪声协方差设为[[0.01,0],[0,0.01]]，比默认值小10倍以抑制过度预测）。

2. 参数敏感性测试记录：不是只写“最终采用阈值5秒”，而是附上测试曲线图（文字描述）：当停车判定时间阈值设为3秒时，漏报率18%（真停车未报），误报率42%；设为5秒时，漏报率2.3%，误报率6.7%；设为7秒时，漏报率0.8%，但误报率升至9.1%。结论：5秒是帕累托最优解。

3. 硬件兼容性清单：明确标注各模块最低要求——OpenCV 4.5.5+（因4.5.0以下版本不支持CUDA加速的dnn模块）、PyTorch 1.12.1+（适配YOLOv5s的TorchScript导出）、NVIDIA驱动≥510（否则TensorRT加速失败）。避免答辩时被问“你的系统能在i5-8250U笔记本跑吗？”当场卡壳。

4. 误报根因分析日志节选：真实记录3次典型误报案例及修复过程。例如：“2023-09-12 14:23，京哈高速K123+500处，误报小轿车停车。查日志发现该帧因云层反光导致车道线检测失效，ROI区域扩大至应急车道，将路肩隔离墩误检为车辆。解决方案：在ROI生成前增加亮度直方图均衡化，并限定ROI y轴范围不超过图像高度的70%”。

这些内容不增加代码行数，但让答辩老师一眼看出：你不是调包侠，而是理解系统边界、会诊断问题的工程师。

2.3 源码组织为什么按“模块-配置-工具”分层？避免毕业答辩时被追问“这个文件是干啥的”

见过太多毕设代码仓库：根目录下堆着train.py、detect.py、main.py、utils.py、config.py……答辩时老师点开一个300行的main.py，问“第187行这个global变量为啥要全局？”学生支吾半天。根源在于代码没分层，逻辑全耦合。

我们的源码严格按三层组织，每层职责单一：

• modules/：纯功能模块，无业务逻辑。

  • detector.py：只封装YOLOv5s加载、推理、NMS后处理，输入cv2.Mat，输出list[xyxy, conf, cls]。
  • tracker.py：只封装DeepSORT初始化、update、get_tracks，输入检测框列表，输出track_id+bbox+tlwh。
  • judger.py：只封装停车判定算法，输入track_id+轨迹点序列，输出bool（is_parking）+持续时间。

• configs/：所有可配置项集中管理。

  • model.yaml：模型路径、输入尺寸、置信度阈值（0.45）、NMS IOU阈值（0.5）。
  • tracking.yaml：卡尔曼滤波参数、最大丢失帧数（30）、最小匹配IOU（0.2）。
  • parking_rule.yaml：停车判定时间阈值（5.0）、位移标准差阈值（2.0）、轨迹缓冲区长度（10）。

• tools/：支撑性脚本，与主流程解耦。

  • calibrate_roi.py：交互式工具，用鼠标拖拽划定视频ROI区域，生成roi_mask.npy。
  • gen_video_report.py：输入原始视频和告警日志，自动合成带红框标注+时间戳的告警片段视频。
  • benchmark_fps.py：在指定硬件上跑100帧，输出平均FPS、内存占用、GPU显存峰值。

这种结构带来的直接好处：答辩时老师问“怎么改检测模型？”，你直接打开configs/model.yaml改路径；问“怎么调停车时间？”，打开configs/parking_rule.yaml改数字。所有修改都在配置层，无需碰核心逻辑，体现工程规范性。

3. 核心细节解析与实操要点

3.1 高速专用数据集构建：为什么不能直接用COCO或BDD100K？

很多同学想省事，直接下载COCO数据集训练YOLO。但COCO里98%的车是城市道路视角，车头朝向杂乱，车速慢，背景复杂。而高速场景的关键特征是：

• 车辆几乎全是俯视角度（车顶+部分侧面），车头朝向高度一致（基本沿x轴正方向）；
• 背景极度规整（车道线平行、路肩整齐），但存在强干扰（远处山体、广告牌、云层反光）；
• 小目标多（远距离车辆占画面＜0.5%面积），且常被大车遮挡。

我们构建的数据集叫HVPD（Highway Violation Parking Dataset），含3个子集：

标注工具用LabelImg，但强制要求三项特殊标注规范：

1. 停车事件标注：不是标单帧，而是标起止时间戳（如start: 12:34:22.150, end: 12:34:27.890），用于生成轨迹标签；
2. 遮挡等级标记：在XML文件中添加<occluded>partial</occluded>字段，分三级（none/partial/heavy），供数据增强时针对性处理；
3. 车道归属标注：每个车辆框添加<lane>1</lane>属性（1=超车道，2=行车道，3=应急车道），因为违规停车只在应急车道才算告警。

数据增强策略也针对高速定制：

• 不使用随机旋转（高速画面旋转后车道线失真）；
• 水平翻转概率设为0.3（避免生成车头朝反方向的假样本）；
• 添加运动模糊：用cv2.blur()模拟高速移动模糊，核大小随机选(3,5,7)；
• 动态亮度调整：对白天样本，随机降低亮度10%~30%模拟云层遮挡；对夜间样本，随机增强车灯区域亮度200%~500%。

注意：很多开源代码用albumentations库做增强，但它默认的RandomBrightnessContrast会破坏车灯高亮特征。我们改用自定义函数：先用HSV空间分离V通道，仅对V通道做gamma校正（gamma∈[0.7,1.3]），再合并回RGB——这样既调亮度，又保车灯锐利度。

3.2 ROI（感兴趣区域）动态裁剪：为什么静态ROI在高速场景必失败？

几乎所有入门教程都教“用cv2.selectROI()框出固定区域”。但在高速场景，这招会失效——因为：

• 卡口摄像头随温度变化轻微偏移（热胀冷缩导致支架微变形）；
• 雨天镜头积水形成水膜，使ROI边缘模糊；
• 大货车经过时气流扰动，导致画面整体抖动。

我们采用双阶段ROI动态校准：
第一阶段（启动时）：运行tools/calibrate_roi.py，手动框选一次初始ROI，程序自动计算车道线斜率（用霍夫变换检测直线），并保存roi_base.npy（含四边形顶点坐标）。
第二阶段（运行时）：每30秒执行一次自动校准：

1. 对当前帧做Canny边缘检测；
2. 用RANSAC拟合两条最显著的平行直线（车道线）；
3. 计算新车道线与基准线的夹角偏差θ；
4. 若|θ| > 0.5°，则用仿射变换将roi_base旋转θ角，并平移补偿位移；
5. 更新当前ROI掩膜roi_mask.npy。

关键细节：RANSAC拟合时，只取y坐标在图像下半部（h/2 ~ h）的边缘点。因为上半部常有广告牌、山体干扰，而车道线有效区域集中在画面中下部。实测表明，此方法使ROI漂移误差从±15像素降至±2像素，停车检测准确率提升11.3%。

3.3 停车判定算法的数学实现：位移标准差为何比欧氏距离更可靠？

网上90%的代码用“连续N帧，中心点距离＜阈值”判定停车。这在高速场景有致命缺陷：

• 当车辆缓行（如20km/h）时，5秒内位移约28米，但检测框中心点在画面中可能只移动3像素（因远距离放大系数小），被误判为停车；
• 摄像头微抖时，所有车辆框中心点同步晃动，欧氏距离增大，但实际车辆未动。

我们改用位移标准差σ_xy，数学推导如下：
设车辆ID在t₀, t₁, ..., tₙ时刻的中心点坐标为(xᵢ, yᵢ)，时间间隔Δtᵢ = tᵢ - tᵢ₋₁。
定义位移向量序列：dᵢ = (xᵢ - xᵢ₋₁, yᵢ - yᵢ₋₁)，其中i=1..n。
则位移标准差：
σ_xy = √[ Σ(dᵢₓ - μₓ)² + Σ(dᵢᵧ - μᵧ)² ] / n
其中μₓ = Σdᵢₓ/n，μᵧ = Σdᵢᵧ/n。

但直接算σ_xy仍有问题：缓行车辆的dᵢ很小，σ_xy也小。于是加入时间加权因子：
定义有效停车时间T_eff = ΣΔtᵢ × I(‖dᵢ‖ < ε)，其中I()为指示函数，ε=1.5像素。
即：只累计那些“位移极小”的时间段。当T_eff > 5秒，才判定停车。

代码实现精简版（modules/judger.py核心段）：

def is_parking(self, track_history: List[Tuple[float, float, float]]) -> Tuple[bool, float]: # track_history: [(x, y, timestamp), ...], len >= 10 if len(track_history) < 10: return False, 0.0 # 提取位移序列（跳过首帧） displacements = [] for i in range(1, len(track_history)): dx = track_history[i][0] - track_history[i-1][0] dy = track_history[i][1] - track_history[i-1][1] dt = track_history[i][2] - track_history[i-1][2] displacements.append((dx, dy, dt)) # 计算位移标准差 dx_list = [d[0] for d in displacements] dy_list = [d[1] for d in displacements] sigma_xy = np.sqrt(np.var(dx_list) + np.var(dy_list)) # 计算有效停车时间 T_eff = 0.0 for dx, dy, dt in displacements: if np.sqrt(dx**2 + dy**2) < 1.5: # 1.5像素阈值 T_eff += dt is_park = (sigma_xy < 2.0) and (T_eff > 5.0) return is_park, T_eff

这个算法的物理意义很清晰：σ_xy < 2.0 表示车辆在画面中几乎不动（排除缓行），T_eff > 5.0 表示“几乎不动”的状态持续了足够久（排除瞬时抖动）。两者AND逻辑，缺一不可。

4. 实操过程与核心环节实现

4.1 环境搭建避坑指南：为什么conda比pip更适合毕业设计？

很多同学用pip install -r requirements.txt，结果在Windows上装torch失败，在Mac上装opencv-python-headless报错。根源在于：pip安装的二进制包是通用版，没针对你的CPU/GPU优化。

我们强制要求用conda环境，步骤如下：

1. 创建专用环境（Python 3.8，兼顾兼容性与性能）：

conda create -n hvpd python=3.8 conda activate hvpd

2. 优先安装GPU加速库（若无NVIDIA显卡，跳过此步）：

# 根据CUDA版本选（查nvidia-smi，我的是11.3） conda install pytorch torchvision torchaudio pytorch-cuda=11.3 -c pytorch -c nvidia

3. 安装OpenCV（conda-forge源编译更稳定）：

conda install -c conda-forge opencv=4.5.5

4. 安装YOLOv5依赖（用官方requirements.txt，但替换掉冲突项）：

pip install -r requirements.txt --no-deps # 先跳过依赖 pip install numpy==1.21.6 pandas==1.3.5 # 指定版本，避免pandas 2.0+与旧YOLO不兼容

关键避坑点：

• 不要用pip install opencv-python：它会覆盖conda安装的OpenCV，导致CUDA加速失效；
• 不要升级到Python 3.11：YOLOv5官方代码在3.11上有asyncio兼容问题；
• Windows用户注意：pycocotools在Windows上编译失败，直接用pip install pycocotools-windows替代。

环境验证脚本（tools/test_env.py）：

import cv2, torch, numpy as np print(f"OpenCV version: {cv2.__version__}") print(f"CUDA available: {torch.cuda.is_available()}") print(f"GPU count: {torch.cuda.device_count()}") print(f"NumPy version: {np.__version__}") # 输出应为：CUDA available: True, GPU count: 1（如有GPU）

4.2 模型训练全流程：从数据准备到精度验证

训练不是一键train.py，而是分五步走：

Step 1：数据集格式转换
YOLOv5要求数据集为images/和labels/目录，标签为txt文件（class x_center y_center width height，归一化）。我们写tools/convert_hvpd_to_yolo.py，关键逻辑：

• 读取LabelImg生成的XML，提取<bndbox>坐标；
• 根据<lane>属性，过滤掉应急车道以外的车辆（因只检测应急车道停车）；
• 对夜间样本，将<occluded>为heavy的框，宽度height乘以0.7（模拟雾中轮廓模糊）。

Step 2：划分训练/验证集
按时间切片而非随机打乱：前70%时间的视频归训练集，后30%归验证集。理由：避免同一辆车在训练集和验证集重复出现，导致指标虚高。实测显示，时间切片划分的mAP比随机划分低1.2%，但上线后泛化更好。

Step 3：修改YOLOv5配置
编辑models/yolov5s.yaml：

• nc: 1（只检测车辆一类，非COCO的80类）；
• anchors重设：用tools/autoanchor.py对HVPD数据集聚类，得到新anchor（如[12,18, 25,32, 48,64]），比默认anchor在小目标上AP提升8.5%。

Step 4：启动训练
命令行参数强调三点：

python train.py \ --img 640 \ --batch 16 \ --epochs 100 \ --data data/hvpd.yaml \ --cfg models/yolov5s.yaml \ --weights yolov5s.pt \ --name hvpd_exp1 \ --cache # 启用缓存，加速数据加载

• --cache：首次运行会将图片转为.npy缓存，后续训练快3倍；
• --batch 16：在GTX 1660上刚好不OOM，太大显存溢出，太小收敛慢；
• --epochs 100：HVPD数据集较小，100轮足够收敛，再多过拟合。

Step 5：精度验证与可视化
训练完成后，用val.py生成详细报告：

• 关键指标看metrics/mAP_0.5（IoU=0.5时的mAP）和metrics/mAP_0.5:0.95（多IoU阈值平均）；
• 重点检查per_class_ap.png：确认“vehicle”类AP＞0.85，且夜间样本AP不低于白天的85%；
• 查看confusion_matrix.png：误检主要是“路肩隔离墩”（占误检72%），说明需在数据增强中增加隔离墩负样本。

实操心得：训练时发现loss在第60轮后震荡不降，不是调学习率，而是检查data/hvpd.yaml里的train:路径——我曾把路径写成../HVPD/images/train/，但实际目录是./HVPD/images/train/，相对路径错误导致数据加载为空，模型在学噪声。用--cache后，控制台会打印“Cache images (0 found)”，这就是预警信号。

4.3 系统集成与告警输出：如何让检测结果真正可用？

检测出停车只是第一步，毕业设计要体现“系统思维”。我们设计三级告警输出：

第一级：实时视频流标注
用cv2.putText()在原视频上叠加：

• 红色矩形框（thickness=2）标出停车车辆；
• 左上角显示PARKING ALERT! ID:123, DURATION: 6.2s；
• 底部滚动字幕[2023-10-05 14:22:33] Emergency Lane, K123+500。

第二级：结构化日志文件
生成alerts/20231005_alerts.csv，字段包括：
timestamp, track_id, lane, duration_sec, video_frame_num, image_path, confidence。
这样交警平台可直接导入数据库，按时间/路段/持续时间筛选。

第三级：轻量Web界面（Flask）
app.py提供三个接口：

• GET /status：返回JSON{ "running": true, "fps": 24.3, "alerts_today": 17 }；
• GET /alerts：返回最近10条告警的JSON数组；
• POST /upload_video：上传视频文件，后台异步处理，返回task_id，前端轮询/task_status?task_id=xxx获取结果。

Web界面极简，只用HTML+JS，不依赖Vue/React——因为毕业设计演示时，老师更关心逻辑而非UI炫技。核心是templates/index.html里一段JS：

function pollTask(taskId) { fetch(`/task_status?task_id=${taskId}`) .then(r => r.json()) .then(data => { if (data.status === 'completed') { document.getElementById('result').innerHTML = `<video controls><source src="${data.video_url}" type="video/mp4"></video>`; } else if (data.status === 'processing') { setTimeout(() => pollTask(taskId), 2000); } }); }

部署命令（run.sh）：

# 启动检测服务（后台） nohup python main.py --source rtsp://admin:pass@192.168.1.100 > log/detect.log 2>&1 & # 启动Web服务（前台，方便调试） python app.py

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 我踩过的三个深坑及血泪教训

坑1：用time.time()计算持续时间，跨天时出错
最初用time.time()记录每帧时间戳，结果凌晨0点时，duration = now - start变成负数。
教训：改用datetime.datetime.now().timestamp()，它返回Unix时间戳（浮点秒），不受日期重置影响。
验证方法：在代码里加assert duration > 0，测试时故意等到23:59:59再运行。

坑2：误以为“检测框置信度高=停车可信”
有次暴雨天，系统对一辆停在应急车道的车，置信度只有0.32（因雨水模糊），但轨迹判定为停车。我差点删掉这个低置信度样本。
教训：停车判定是独立于检测置信度的逻辑！只要轨迹满足条件，即使检测框模糊，也要告警。后来在judger.py里加了日志：if is_parking and conf < 0.4: logger.warning(f"Low-conf parking alert: ID{tid}, conf{conf:.2f}")，专门监控这类case。

坑3：忽略视频编码格式，导致RTSP流卡顿
用海康威视摄像头RTSP流时，cv2.VideoCapture('rtsp://...')打开后FPS只有3。
教训：海康默认用H.265编码，OpenCV 4.5.5不原生支持。解决方案：

• 方法1（推荐）：在RTSP URL后加?avbind=1强制H.264；
• 方法2：用ffmpeg转码：ffmpeg -i "rtsp://..." -c:v libx264 -f flv - | python main.py；
• 方法3：升级OpenCV到4.8.0+（支持H.265）。

5.3 毕业答辩高频问题应答模板

Q：为什么不用Transformer做目标检测？
A：ViT或DETR在高速场景没有优势。我们的实测对比（在HVPD上）：DETR mAP比YOLOv5s高0.8%，但推理速度慢3.2倍（YOLOv5s 23FPS vs DETR 7FPS），且对小目标检测更不稳定。毕业设计追求的是“够用、稳定、可解释”，不是SOTA。

Q：如何证明你的系统比传统线圈检测更优？
A：线圈检测只能知道“有车停”，不知道“哪辆车、停多久、在哪个车道”。我们的系统输出结构化数据（track_id, lane, duration），且能回溯视频片段。更重要的是，线圈需破路安装（成本＞2万元/处），而我们的方案只需接入现有卡口视频流，零施工成本。

Q：遇到极端天气（如浓雾）怎么办？
A：我们在HVPD-Fog子集训练时，加入了雾浓度分级标签。部署时，系统会实时计算当前帧的雾浓度指数（用灰度图标准差+低频能量比），若指数＞阈值，则自动启用“雾天模式”：降低检测置信度阈值（0.45→0.35），并延长停车判定时间（5秒→8秒），用时间换精度。这在文档的“场景约束分析表”里有详细记录。

最后再分享一个小技巧：答辩演示时，别用实时摄像头，提前录好一段含3个停车事件的视频（demo_highway.mp4），用python main.py --source demo_highway.mp4运行。这样能确保演示流畅，且可精准控制告警出现时机——毕竟，让老师亲眼看到红框弹出，比讲一百遍原理都有力。

本文还有配套的精品资源，点击获取