简介一份基于YOLOv8的多端车流检测系统完整项目资料面向人工智能、通信、自动化、电子信息等专业学生与开发者可直接用于毕业设计、课程设计或作为科研项目起点。系统涵盖模型训练、多端部署与可视化检测流程适合已有深度学习基础的学习者进阶。压缩包共397个文件约16.94MB以Python源码150个py文件为核心辅以34个YAML配置、预训练模型pt、UI界面、SQL数据库、环境配置文件及演示视频同时包含大量png/jpg测试图片与pyc运行缓存便于调试与结果验证。已有165人浏览学习项目代码经测试运行成功并获导师指导及答辩评审95分高分认可。资源附带的文档与全套资料可帮助使用者快速掌握YOLOv8车流检测的工程实现尤其适合需要完整项目经验支撑的毕设与课设场景并可在现有代码基础上做二次开发扩展功能。1. 一套YOLOv8多端车流检测系统毕设答辩前你真正需要的是完整闭环毕设季最容易翻车的项目不是模型没训出来而是答辩时被追问“这套系统换一台电脑、换一个路口还能跑吗”。基于YOLOv8的多端车流检测系统正是冲着这个问题去的它把车辆检测、车流统计、视觉展示拆成训练端、边缘端和Web端同一份权重既能在GTX 1660Ti这样的普通显卡上训练也能跑到RK3588这类边缘设备上做实时推理最后用统一界面把车流数据展示出来。这套闭环特别适合急着出完整成果、又不想在部署上失控的本科毕业设计和开源项目。我会按选型、训练、部署、避坑的顺序把能直接抄的命令和参数写出来。2. 为什么是YOLOv8而不是Faster R-CNN网络结构、多端架构与1660Ti环境配置2.1 看清YOLOv8的检测头才知道多端转移为什么省心车流检测的时间背景是白天、黑夜、雨雾、拥堵目标尺度从几十像素到整屏。很多人一上来就选Faster R-CNN理由是两阶段精度高但在GTX 1660Ti上跑实时视频流单帧推理时间很容易突破150 ms处理1080p的车流视频几乎卡成PPT。YOLOv8作为单阶段检测器在同样的硬件上能把延迟压到30到60 ms对车流计数场景已经够用。它更大的价值在于工程生态ultralytics仓库把数据加载、训练、验证、导出串成一条命令后续转ONNX、转RKNN的坑位比传统Detection代码少很多毕设阶段不必去补既有框架的存量债务。从网络结构上看YOLOv8相对YOLOv5的主要改动集中在三处。主干网络用C2f替换了C3把更多的梯度流拆成多条分支再融合同等参数下特征表达能力更好颈部仍是PAN结构深浅层特征交叉融合这对车流里远小目标和近处大目标同时存在的情况很关键检测头从anchor-based改成anchor-free每个位置直接预测四个边框值和类别概率少算了anchor匹配那一步训练目标也更接近真实车流分布。输出层使用DFL和CIOU组合做回归损失训练收敛曲线比早期YOLO好看也更容易在毕设里写清楚。很多论文里的网络结构图把C2f和检测头画得很大但真正影响多端部署的是输入尺寸和输出通道数画图时别漏掉这两个信息。那“多端”到底指哪几端我一般拆成三端训练端是带NVIDIA显卡的PC负责标注、训练、评估边缘端是RK3588这类Arm盒子负责加载RKNN格式的模型做实时推理展示端是一个轻量Web页面负责把车辆框、计数结果和帧率展示出来。这样做的好处是训练和推理解耦不会因为嵌入式端内存不足而反推整个训练策略同一个数据集和同一份best.pt权重通过ONNX和RKNN两级转换就能在不同算力平台上复用。这里要补充一点选型边界如果项目要求的是夜间低光、遮挡严重的特定路口YOLOv8并不天然比Faster R-CNN强真正的差距在训练数据分布和后续优化。如果学校要求必须写清楚改进点可以把YOLOv8的检测头改成动态标签分配或在C2f里引入注意力但这属于加分项先把基线跑通再谈改进否则开题到中期都压着一个跑不动的黑匣子非常难受。2.2 在GTX 1660Ti上把环境一次配好最小命令清单环境配置是新手最容易翻车的地方。常见组合是Python 3.10、PyTorch 2.x、Ultralytics 8.x。不要自己去源码编译直接用pip安装即可conda create -n traffic python3.10 -y conda activate traffic pip install ultralytics这段命令创建名为traffic的虚拟环境Python版本锁定3.10目前PyTorch和OpenCV对它的兼容性都很好。第3行直接用pip装ultralytics它会自动带上torch CPU版但这里有个容易踩的坑如果直接执行上面命令torch会安装CPU版本虽然能训练但速度极慢。必须在装ultralytics之前先装对应CUDA的torch常见的安装方式是pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118在GTX 1660Ti这类6 GB显存卡上我习惯装cu118而不是更高版本原因是cu118对应驱动的兼容范围更宽装完后不容易在import torch时报找不到CUDA的错。如果你的显卡驱动较新也可以选择cu121但不要在还没跑通模型前去升级显卡驱动这是很多血泪经验的来源。环境装好后用一张预训练权重先验证推理链路yolo predict modelyolov8s.pt sourcehttps://ultralytics.com/images/bus.jpg注意这个示例源是ultralytics官方的示例图片。如果网络受限就换成任意一张本地图片路径例如source./test.jpg。命令会自动下载yolov8s.pt权重然后输出预测图。看到bus.jpg里检测出person和bus就说明环境没问题。这里选yolov8s而不是n或m是有原因的8s约11 M参数量在1660Ti上推理帧率接近40 FPS精度适中8n更快但车流小目标检出率不足8m能要到精度但6 GB显存训练时batch会缩得很难受。对毕设而言yolov8s是最小后悔药。装完环境后可以用一条命令确认GPU能真正参与训练python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))如果输出True NVIDIA GeForce GTX 1660 Ti说明推理和训练都会走GPU。如果输出False优先确认是不是装了CPU版torch不要急着重装系统。最后补充一点不要在这个阶段去装很多改进版本的YOLOv8源码。网上那些带注意力机制、偏置解耦的增强版本中间层改动很大一旦开箱跑不通排查成本足够你做两个课题。先用官方ultralytics跑通之后需要改进时再用官方代码里支持的卷积替换方式做增量修改。3. 训练自己的车流数据集从VOC转YOLO到损失曲线把mAP调到能答辩的水平3.1 数据目录与data.yaml公开车流数据和自采路口视频怎么混合车流检测的公开数据集中UA-DETRAC和BDD100K比较常见。前者是固定相机视角、车辆类别和后尾灯场景后者包含驾驶视角天气和时段更全。做毕设时不要贪多我的习惯是从公开数据集抽一个子集再自己架摄像机在路口拍约20到30分钟视频抽帧筛选出300到500张白天和傍晚的图片和公开数据混合成一个小而均衡的数据集。这样做的原因是公开数据集分辨率、相机高度和毕设演示环境差异很大只用公开数据会导致换个路口就漏检只有自己的图片才能让答辩现场的演示视频在同一个场景下表现正常。目录结构我一般建成本地项目下的固定格式traffic_dataset/ ├── images/ │ ├── train/ │ ├── val/ ├── labels/ │ ├── train/ │ ├── val/ └── traffic.yaml这个结构同时也是ultralytics默认支持的格式。images和labels的train/val子目录必须同名一一对应图片后缀和标签后缀分别放在两个根目录下标签文件每行是class_id x_center y_center width height坐标全部归一化到0到1。traffic.yaml内容则是指向这些目录和数据集的元信息path: /home/user/traffic_dataset train: images/train val: images/val names: 0: car 1: bus 2: truck 3: motorcycle 4: bicycle这里path写绝对路径最省事省得train和val写成相对路径时因为工作目录不同而爆红。类别只保留车流场景需要的类不要从COCO全量80类里带过来一堆person、dog之类类别越少同类别在特征空间的区分度越集中训练出来的车流检测模型也越不容易把树干误检成bus。我一般会额外做一次“按时间段划分”而不是随机划分把同一段视频抽出的帧按时间顺序排列前80%作为train后20%作为val。如果随机划分相邻帧几乎重复验证损失会很乐观到了答辩现场换成新视频马上露馅。这是数据层面避坑的关键后面避坑章还会专门展开。3.2 用Python把VOC格式转成YOLO标签的脚本与坐标边界坑公开车流数据通常是VOC格式标注用xml存储。YOLO训练需要txt标签所以需要一个转换脚本。这里给一个可直接使用的版本import os import xml.etree.ElementTree as ET from pathlib import Path classes [car, bus, truck, motorcycle, bicycle] def convert_xml(xml_path, out_txt_path): tree ET.parse(xml_path) root tree.getroot() size root.find(size) w int(size.find(width).text) h int(size.find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in classes: continue cls_id classes.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) x_center (x1 x2) / 2.0 / w y_center (y1 y2) / 2.0 / h bw (x2 - x1) / w bh (y2 - y1) / h x_center min(max(x_center, 0.0), 1.0) y_center min(max(y_center, 0.0), 1.0) bw min(max(bw, 0.0), 1.0) bh min(max(bh, 0.0), 1.0) lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {bw:.6f} {bh:.6f}) with open(out_txt_path, w) as f: f.write(\n.join(lines)) xml_dir Path(Annotations) txt_dir Path(labels/train) txt_dir.mkdir(parentsTrue, exist_okTrue) for xml_file in xml_dir.glob(*.xml): convert_xml(xml_file, txt_dir / (xml_file.stem .txt))这段脚本做了三件事遍历Annotations下的xml读取图片尺寸和每个目标的类别、边框把左上角右下角坐标归一化成YOLO格式的x_center、y_center、width、height最后写入同名txt。需要留意的是坐标钳制到0到1这一步车流数据集里偶尔会有标注框出画面边界的脏数据如果不做钳制训练时损失直接变为nan那种情况极难排查。另一个细节是xml里值经常带换行符这里统一用float()强转但如果文本里混入了不可见字符需要先value .join(value.split())再转换。3.3 在GTX 1660Ti上启动YOLOv8训练并画出损失曲线数据准备好了训练命令非常简单cd /home/user/traffic_dataset/.. yolo train modelyolov8s.pt datatraffic_dataset/traffic.yaml \ epochs100 imgsz640 batch8 device0 \ patience10 projectruns nametraffic_yolov8s这个命令用预训练的yolov8s.pt做迁移学习epochs给100轮输入分辨率640显存6 GB的GTX 1660Ti下batch用8比较稳妥如果中途OOM就降到4。patience是早停轮数连续10轮验证损失不下降就停止不会白跑。训练过程中可以随时查看命令行输出的mAP50、mAP50-95、loss/train_box等指标训练结束后runs/traffic_yolov8s/weights/best.pt和last.pt分别保存最优和最后权重。注意评判优先用best.pt这是默认选择。训练结束后runs/traffic_yolov8s/下会出现results.png里面包含了train和val的box loss、cls loss、mAP50和mAP50-95曲线。很多毕设小组直接把这张图贴到论文里但更值得做的是打开看它的形状如果train loss持续下降、val loss在第40轮后反弹那就是过拟合说明epochs太多或数据量太少如果两条曲线在第80轮还在同步下降可以再把epochs加到150。画图本身不需要额外代码ultralytics已经帮我们产出了答辩中讲清楚每条曲线的含义比贴代码更有加分效果。为了更直观地验证预测效果我还会在训练结束后跑一段验证视频yolo predict modelruns/traffic_yolov8s/weights/best.pt \ sourcetest_video.mp4 \ conf0.35 iou0.45 \ showTrue saveTrueconf和iou是推理阶段最常用的两个参数。conf默认0.25车流场景建议提到0.35减少树影和窗格的误检iou保持0.45到0.5过低会重复框住同一辆车会把车流计数结果放大。这里saveTrue会保存带框的视频用来做演示素材正好。4. 多端部署实战从ONNX导出到RK3588再用Flask做Web演示界面4.1 把训练好的YOLOv8导出ONNX再转成RK3588的RKNN模型训练产出best.pt后离真正跑在一个嵌入式盒子还有两步。第一步是把PyTorch权重导出为ONNXultralytics一条命令就能完成yolo export modelruns/traffic_yolov8s/weights/best.pt formatonnx opset12 simplifyTrueopset设成12RKNN工具链解析ONNX的兼容性较好simplifyTrue会用onnx-simplifier去掉多余节点转换出的模型更小也更不容易在目标平台上报不支持的算子。导出success后同目录下会出现best.onnx可以先在PC上用onnxruntime跑一遍确认输出张量和pt一致再进入RKNN转换。转RKNN的常见做法是使用RKNN-Toolkit2的Python API在PC上完成而不是直接在板子上转。原因是量化阶段需要跑代表性的校准图片PC内存和显存都更充裕。关键脚本如下from rknn.api import RKNN rknn RKNN() ret rknn.config( target_platformrk3588, mean_values[[0, 0, 0]], std_values[[255, 255, 255]], quantized_dtypew8a8, quantized_algorithmnormal, quantized_methodlayer ) print(config:, ret) rknn.load_onnx(modelbest.onnx) rknn.build( do_quantizationTrue, datasetrknn_calib.txt ) rknn.export_rknn(traffic_yolov8s.rknn)这里config中的mean_values和std_values要和训练时保持一致YOLOv8官方预处理是减0除255所以mean为0std为255。quantized_dtypew8a8表示对权重和激活都做8bit量化RK3588的NPU跑得最快quantized_methodlayer逐层决定量化范围是精度和速度之间的折中方案。do_quantizationTrue启用校准量化依赖rknn_calib.txt这个清单test_frames/frame_0001.jpg test_frames/frame_0002.jpg ...每行一张图片路径我一般从验证集按时间均匀抽300张覆盖白天、傍晚、阴天、路灯开启等车流场景。量化后板上推理的精度通常能保留90%以上但如果校准图片只用20张且全是白天夜间mAP会掉得很厉害后面避坑章会专门展开。4.2 在RK3588上跑RKNN推理并把结果回传Web端部署端我通常用RK3588开发板系统自带NPU驱动。推理代码用RKNN Python接口加队列帧读取是最常见的落地写法。这里给一个核心循环说明车流检测和画框流程import cv2 from rknn.api import RKNN rknn RKNN() rknn.load_rknn(traffic_yolov8s.rknn) rknn.init_runtime() capture cv2.VideoCapture(rtsp://edge-camera/stream) while True: ok, frame capture.read() if not ok: break input_frame cv2.resize(frame, (640, 640)) input_frame input_frame[:, :, ::-1] # BGR to RGB outputs rknn.inference(inputs[input_frame]) boxes, classes, scores postprocess(outputs) for box, score, cls in zip(boxes, scores, classes): cv2.rectangle(frame, (box[0], box[1]), (box[2], box[3]), (0, 255, 0), 2) cv2.imshow(traffic, frame)这段代码有两点要重点说明。第一RKNN推理前要把BGR转成RGB并缩放到训练时相同的640x640如果不转色模型输出的置信度会整体偏低且类别错乱。第二outputs从RKNN返回后通常是原始层的feature map还需要在Python里做一次解码头、聚类和NMS这部分逻辑在训练后的模型导出阶段会自动附在ONNX里但RKNN工具链不会自动补齐所以要自己在项目里维护一个后处理模块。这也是RK3588部署YOLOv8最大的工作量很多人以为做完RKNN转换就万事大吉其实后处理才是真正的坑。如果是毕设演示我更推荐先做一个Flask轻量Web端而不是桌面PyQt界面原因是Web端可以让老师和评委在手机、平板上同时看到检测视频流演示效果更直观。代码简化为from flask import Flask, render_template, Response import cv2 from ultralytics import YOLO app Flask(__name__) model YOLO(runs/traffic_yolov8s/weights/best.pt) def generate_frames(): cap cv2.VideoCapture(0) while True: ok, frame cap.read() if not ok: break results model(frame, verboseFalse) annotated results[0].plot() ret, buffer cv2.imencode(.jpg, annotated) yield (b--frame\r\n bContent-Type: image/jpeg\r\n\r\n buffer.tobytes() b\r\n) app.route(/video_feed) def video_feed(): return Response(generate_frames(), mimetypemultipart/x-mixed-replace; boundaryframe) if __name__ __main__: app.run(host0.0.0.0, port8000)这个Web端虽然简单但足以把检测结果实时推送到浏览器且不依赖桌面环境适合部署在RK3588板子上配合前面的RKNN推理做演示。如果要加车流计数只需要在results[0].boxes里拿到每个目标的类别然后对视频帧中的每辆车做框中心点跟踪这里可以用最简单的按IoU匹配相邻帧的方式毕设答辩时能讲清楚“我按帧差IoU做轻量跟踪”比直接调用DeepSORT更有可信度。如果演示机上没有NVIDIA显卡Flask用CPU跑YOLOv8s速度只有5到8 FPS画面会很卡。因此部署端和展示端最好分开RK3588做NPU推理Flask只做Web流转发和统计展示否则现场容易翻车。5. 车流检测落地中的5个避坑点从夜间漏检到RK3588量化掉分5.1 夜间黑色轿车漏检加暗化增强反而更差现象白天场景mAP50接近0.93一到夜间视频黑色轿车直接消失bus和truck还能检测到。原因最直接的原因是训练集中夜间样本太少模型把近黑色区域和路面纹理混在一起。有人会在训练时把所有图片随机调暗期望提高鲁棒性结果发现夜间目标不仅没召回白天背景也被压低这是“增强策略和真实场景不匹配”导致的翻车。解决我先按时间线从测试视频抽帧标注出100到200张夜间图片放到训练集里重新训练而不是统一做亮度增强。增强参数只开HSV扰动和轻微曝光在ultralytics里通过hsv_h、hsv_s、hsv_v控制例如hsv_h0.015、hsv_s0.7、hsv_v0.4同时不要加过大的随机暗化保持光照分布的原始性。重新训练后夜间车漏检减少最明显的是黑色轿车。5.2 远处小目标车流漏检换大模型不如提高输入分辨率现象在高速高架场景远处车辆只有约20乘20像素用yolov8s在640分辨率下mAP50不错但实拍视频里超过50米的目标全部跳过。原因YOLOv8默认下采样到640乘640输入远处车辆的特征经过多次池化后只剩几个像素后面的脖子和头部很难从中恢复语义。很多同学第一反应是换yolov8m或者yolov8l但6 GB显存下训练不动而且大模型对本就稀疏的小目标特征增益有限。解决在测试阶段对视频做ROI切片把远处车道区域在原图中截取出来放大到640后再送入模型检测框再映射回原图坐标。实在不想做切片可以训练时imgsz960、模型用yolov8n显存开销可控但推理延迟会增加。对于毕设用ROI切片策略性价比最高只需要在视频里框一个固定车道区域不会引入太多新代码。5.3 RK3588量化后精度掉了10个点校准集要按场景抽现象PyTorch模型在PC上mAP50为0.90转换RKNN后在板子上只有0.80尤其夜间和雨天掉得更狠。原因量化是把FP32权重压缩成INT8精度损失本身可控翻车大多出在校准集。有人图省事从训练集随机抽20张图片里面几乎全是白天量化统计出的激活范围对夜间场景完全不适用等于用白天数据定义了整个动态范围。解决校准集应该从验证集按场景和时间抽取300到500张覆盖白天、傍晚、夜间、阴天和雨天且每张图片都要是模型接受的原图尺寸或经过和训练相同的缩放。在RKNN的config里quantized_algorithm可以用mmse代替normal当正常量化掉点严重时mmse会为了保精度小幅增加量化误差分布的计算量如果单层量化导致个别层输出异常再把关键层指定为float16保留。量化后一定要在板子上重复验证夜间视频不要在PC上只测一张白天图就宣布完成。5.4 毕设翻车训练和测试用了同一段视频的相邻帧现象训练时mAP50-95接近0.75换一段新路口的视频后掉到0.5答辩时被老师质疑工作是否真实。原因很多开源车流项目演示视频只有几分钟直接把整段视频抽帧后随机分train/val相邻帧高度相似等于让模型“背”了验证帧。最终得到的优异mAP是数据泄漏的假成绩不是模型的泛化能力。解决数据划分必须按时间顺序而不是随机划分。我会取同一摄像头连续视频前8分钟抽帧做训练最后2分钟抽帧做验证中间空出30秒过渡保证没有相邻帧泄漏。如果混合了多个路口那么每个路口都要各取独立时间段进验证集。这个习惯写进毕设的“实验设计”里答辩时非常加印象分。5.5 GTX 1660Ti训练OOM不是模型选错是batch和缓存策略没调整现象训练启动后不到10秒报CUDA out of memory甚至把浏览器都卡死。原因1660Ti只有6 GB显存训练时若采用默认的batch16很容易爆掉。部分教程默认读者用的是3090、4090照抄batch数值是OOM最直接的原因。有时候不是batch而是在Windows下同时开了视频解码和浏览器显存和内存都被占了一部分。解决把batch降到8或4并在训练命令中显式加workers2降低数据加载线程压力。如果还想稳一点直接换yolov8n模型输入分辨率保持6406 GB显存下训练batch可以回到16。同时关闭其他GPU程序不要一边训练一边在浏览器里播放高码率视频这是最容易忽略的习惯问题。6. 验收技巧把损失曲线、视频回放和计数误差放在一张表里判断模型训练完后不要只贴mAP。我会做一次“三件套”验证第一件看runs下的results.png里val loss有没有反常回升第二件把best.pt跑三段不同时段的视频输出带框视频用肉眼确认有没有把树影、路灯当车第三件在每段视频里人工数一遍真实车数和模型计的数对比。为了不让计数过程太枯燥我通常写个简单脚本把每类计数结果输出到csv然后手工汇总成验证表。实际执行时我用一个很简单的统计脚本import cv2 from ultralytics import YOLO model YOLO(best.pt) counts {car: 0, bus: 0, truck: 0, motorcycle: 0, bicycle: 0} for video in [day.mp4, night.mp4, rain.mp4]: cap cv2.VideoCapture(video) frame_id 0 while cap.isOpened(): ok, frame cap.read() if not ok: break if frame_id % 5 0: result model(frame, verboseFalse)[0] for box in result.boxes: cls_name result.names[int(box.cls)] if cls_name in counts: counts[cls_name] 1 frame_id 1 cap.release() print(video, counts)注意这是“按帧累计”的近似统计不是真正的目标计数因为同一辆车会出现在多帧里。但用于验证检测器“有没有把类别认错”已经够用。我在毕设演示里会把这个脚本的结果做成一张表白天、夜间、雨天三段视频分别统计真实车辆数、检测数、单帧推理时间并标注漏检最多的是哪一类然后用文字解释漏检原因。这个习惯帮我在答辩前提前发现过夜间黑色轿车漏检也避免了现场被问到遮挡场景时无话可说。最后说一个我的习惯无论换多少次参数都要把改过的数据集划分和时间戳记录在实验笔记里不要只记录最终命令。否则一周后你自己也说不清当前权重是用哪些图片训出来的这比模型本身不work更让人崩溃。希望这篇笔记能把你在车流检测毕设里的坑提前扫掉少走几段弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 11:57:51 · 阅读 1.2k YOLOv8多端车流检测系统实战：从训练部署到避坑全攻略
简介一份基于YOLOv8的多端车流检测系统完整项目资料面向人工智能、通信、自动化、电子信息等专业学生与开发者可直接用于毕业设计、课程设计或作为科研项目起点。系统涵盖模型训练、多端部署与可视化检测流程适合已有深度学习基础的学习者进阶。压缩包共397个文件约16.94MB以Python源码150个py文件为核心辅以34个YAML配置、预训练模型pt、UI界面、SQL数据库、环境配置文件及演示视频同时包含大量png/jpg测试图片与pyc运行缓存便于调试与结果验证。已有165人浏览学习项目代码经测试运行成功并获导师指导及答辩评审95分高分认可。资源附带的文档与全套资料可帮助使用者快速掌握YOLOv8车流检测的工程实现尤其适合需要完整项目经验支撑的毕设与课设场景并可在现有代码基础上做二次开发扩展功能。1. 一套YOLOv8多端车流检测系统毕设答辩前你真正需要的是完整闭环毕设季最容易翻车的项目不是模型没训出来而是答辩时被追问“这套系统换一台电脑、换一个路口还能跑吗”。基于YOLOv8的多端车流检测系统正是冲着这个问题去的它把车辆检测、车流统计、视觉展示拆成训练端、边缘端和Web端同一份权重既能在GTX 1660Ti这样的普通显卡上训练也能跑到RK3588这类边缘设备上做实时推理最后用统一界面把车流数据展示出来。这套闭环特别适合急着出完整成果、又不想在部署上失控的本科毕业设计和开源项目。我会按选型、训练、部署、避坑的顺序把能直接抄的命令和参数写出来。2. 为什么是YOLOv8而不是Faster R-CNN网络结构、多端架构与1660Ti环境配置2.1 看清YOLOv8的检测头才知道多端转移为什么省心车流检测的时间背景是白天、黑夜、雨雾、拥堵目标尺度从几十像素到整屏。很多人一上来就选Faster R-CNN理由是两阶段精度高但在GTX 1660Ti上跑实时视频流单帧推理时间很容易突破150 ms处理1080p的车流视频几乎卡成PPT。YOLOv8作为单阶段检测器在同样的硬件上能把延迟压到30到60 ms对车流计数场景已经够用。它更大的价值在于工程生态ultralytics仓库把数据加载、训练、验证、导出串成一条命令后续转ONNX、转RKNN的坑位比传统Detection代码少很多毕设阶段不必去补既有框架的存量债务。从网络结构上看YOLOv8相对YOLOv5的主要改动集中在三处。主干网络用C2f替换了C3把更多的梯度流拆成多条分支再融合同等参数下特征表达能力更好颈部仍是PAN结构深浅层特征交叉融合这对车流里远小目标和近处大目标同时存在的情况很关键检测头从anchor-based改成anchor-free每个位置直接预测四个边框值和类别概率少算了anchor匹配那一步训练目标也更接近真实车流分布。输出层使用DFL和CIOU组合做回归损失训练收敛曲线比早期YOLO好看也更容易在毕设里写清楚。很多论文里的网络结构图把C2f和检测头画得很大但真正影响多端部署的是输入尺寸和输出通道数画图时别漏掉这两个信息。那“多端”到底指哪几端我一般拆成三端训练端是带NVIDIA显卡的PC负责标注、训练、评估边缘端是RK3588这类Arm盒子负责加载RKNN格式的模型做实时推理展示端是一个轻量Web页面负责把车辆框、计数结果和帧率展示出来。这样做的好处是训练和推理解耦不会因为嵌入式端内存不足而反推整个训练策略同一个数据集和同一份best.pt权重通过ONNX和RKNN两级转换就能在不同算力平台上复用。这里要补充一点选型边界如果项目要求的是夜间低光、遮挡严重的特定路口YOLOv8并不天然比Faster R-CNN强真正的差距在训练数据分布和后续优化。如果学校要求必须写清楚改进点可以把YOLOv8的检测头改成动态标签分配或在C2f里引入注意力但这属于加分项先把基线跑通再谈改进否则开题到中期都压着一个跑不动的黑匣子非常难受。2.2 在GTX 1660Ti上把环境一次配好最小命令清单环境配置是新手最容易翻车的地方。常见组合是Python 3.10、PyTorch 2.x、Ultralytics 8.x。不要自己去源码编译直接用pip安装即可conda create -n traffic python3.10 -y conda activate traffic pip install ultralytics这段命令创建名为traffic的虚拟环境Python版本锁定3.10目前PyTorch和OpenCV对它的兼容性都很好。第3行直接用pip装ultralytics它会自动带上torch CPU版但这里有个容易踩的坑如果直接执行上面命令torch会安装CPU版本虽然能训练但速度极慢。必须在装ultralytics之前先装对应CUDA的torch常见的安装方式是pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118在GTX 1660Ti这类6 GB显存卡上我习惯装cu118而不是更高版本原因是cu118对应驱动的兼容范围更宽装完后不容易在import torch时报找不到CUDA的错。如果你的显卡驱动较新也可以选择cu121但不要在还没跑通模型前去升级显卡驱动这是很多血泪经验的来源。环境装好后用一张预训练权重先验证推理链路yolo predict modelyolov8s.pt sourcehttps://ultralytics.com/images/bus.jpg注意这个示例源是ultralytics官方的示例图片。如果网络受限就换成任意一张本地图片路径例如source./test.jpg。命令会自动下载yolov8s.pt权重然后输出预测图。看到bus.jpg里检测出person和bus就说明环境没问题。这里选yolov8s而不是n或m是有原因的8s约11 M参数量在1660Ti上推理帧率接近40 FPS精度适中8n更快但车流小目标检出率不足8m能要到精度但6 GB显存训练时batch会缩得很难受。对毕设而言yolov8s是最小后悔药。装完环境后可以用一条命令确认GPU能真正参与训练python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))如果输出True NVIDIA GeForce GTX 1660 Ti说明推理和训练都会走GPU。如果输出False优先确认是不是装了CPU版torch不要急着重装系统。最后补充一点不要在这个阶段去装很多改进版本的YOLOv8源码。网上那些带注意力机制、偏置解耦的增强版本中间层改动很大一旦开箱跑不通排查成本足够你做两个课题。先用官方ultralytics跑通之后需要改进时再用官方代码里支持的卷积替换方式做增量修改。3. 训练自己的车流数据集从VOC转YOLO到损失曲线把mAP调到能答辩的水平3.1 数据目录与data.yaml公开车流数据和自采路口视频怎么混合车流检测的公开数据集中UA-DETRAC和BDD100K比较常见。前者是固定相机视角、车辆类别和后尾灯场景后者包含驾驶视角天气和时段更全。做毕设时不要贪多我的习惯是从公开数据集抽一个子集再自己架摄像机在路口拍约20到30分钟视频抽帧筛选出300到500张白天和傍晚的图片和公开数据混合成一个小而均衡的数据集。这样做的原因是公开数据集分辨率、相机高度和毕设演示环境差异很大只用公开数据会导致换个路口就漏检只有自己的图片才能让答辩现场的演示视频在同一个场景下表现正常。目录结构我一般建成本地项目下的固定格式traffic_dataset/ ├── images/ │ ├── train/ │ ├── val/ ├── labels/ │ ├── train/ │ ├── val/ └── traffic.yaml这个结构同时也是ultralytics默认支持的格式。images和labels的train/val子目录必须同名一一对应图片后缀和标签后缀分别放在两个根目录下标签文件每行是class_id x_center y_center width height坐标全部归一化到0到1。traffic.yaml内容则是指向这些目录和数据集的元信息path: /home/user/traffic_dataset train: images/train val: images/val names: 0: car 1: bus 2: truck 3: motorcycle 4: bicycle这里path写绝对路径最省事省得train和val写成相对路径时因为工作目录不同而爆红。类别只保留车流场景需要的类不要从COCO全量80类里带过来一堆person、dog之类类别越少同类别在特征空间的区分度越集中训练出来的车流检测模型也越不容易把树干误检成bus。我一般会额外做一次“按时间段划分”而不是随机划分把同一段视频抽出的帧按时间顺序排列前80%作为train后20%作为val。如果随机划分相邻帧几乎重复验证损失会很乐观到了答辩现场换成新视频马上露馅。这是数据层面避坑的关键后面避坑章还会专门展开。3.2 用Python把VOC格式转成YOLO标签的脚本与坐标边界坑公开车流数据通常是VOC格式标注用xml存储。YOLO训练需要txt标签所以需要一个转换脚本。这里给一个可直接使用的版本import os import xml.etree.ElementTree as ET from pathlib import Path classes [car, bus, truck, motorcycle, bicycle] def convert_xml(xml_path, out_txt_path): tree ET.parse(xml_path) root tree.getroot() size root.find(size) w int(size.find(width).text) h int(size.find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in classes: continue cls_id classes.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) x_center (x1 x2) / 2.0 / w y_center (y1 y2) / 2.0 / h bw (x2 - x1) / w bh (y2 - y1) / h x_center min(max(x_center, 0.0), 1.0) y_center min(max(y_center, 0.0), 1.0) bw min(max(bw, 0.0), 1.0) bh min(max(bh, 0.0), 1.0) lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {bw:.6f} {bh:.6f}) with open(out_txt_path, w) as f: f.write(\n.join(lines)) xml_dir Path(Annotations) txt_dir Path(labels/train) txt_dir.mkdir(parentsTrue, exist_okTrue) for xml_file in xml_dir.glob(*.xml): convert_xml(xml_file, txt_dir / (xml_file.stem .txt))这段脚本做了三件事遍历Annotations下的xml读取图片尺寸和每个目标的类别、边框把左上角右下角坐标归一化成YOLO格式的x_center、y_center、width、height最后写入同名txt。需要留意的是坐标钳制到0到1这一步车流数据集里偶尔会有标注框出画面边界的脏数据如果不做钳制训练时损失直接变为nan那种情况极难排查。另一个细节是xml里值经常带换行符这里统一用float()强转但如果文本里混入了不可见字符需要先value .join(value.split())再转换。3.3 在GTX 1660Ti上启动YOLOv8训练并画出损失曲线数据准备好了训练命令非常简单cd /home/user/traffic_dataset/.. yolo train modelyolov8s.pt datatraffic_dataset/traffic.yaml \ epochs100 imgsz640 batch8 device0 \ patience10 projectruns nametraffic_yolov8s这个命令用预训练的yolov8s.pt做迁移学习epochs给100轮输入分辨率640显存6 GB的GTX 1660Ti下batch用8比较稳妥如果中途OOM就降到4。patience是早停轮数连续10轮验证损失不下降就停止不会白跑。训练过程中可以随时查看命令行输出的mAP50、mAP50-95、loss/train_box等指标训练结束后runs/traffic_yolov8s/weights/best.pt和last.pt分别保存最优和最后权重。注意评判优先用best.pt这是默认选择。训练结束后runs/traffic_yolov8s/下会出现results.png里面包含了train和val的box loss、cls loss、mAP50和mAP50-95曲线。很多毕设小组直接把这张图贴到论文里但更值得做的是打开看它的形状如果train loss持续下降、val loss在第40轮后反弹那就是过拟合说明epochs太多或数据量太少如果两条曲线在第80轮还在同步下降可以再把epochs加到150。画图本身不需要额外代码ultralytics已经帮我们产出了答辩中讲清楚每条曲线的含义比贴代码更有加分效果。为了更直观地验证预测效果我还会在训练结束后跑一段验证视频yolo predict modelruns/traffic_yolov8s/weights/best.pt \ sourcetest_video.mp4 \ conf0.35 iou0.45 \ showTrue saveTrueconf和iou是推理阶段最常用的两个参数。conf默认0.25车流场景建议提到0.35减少树影和窗格的误检iou保持0.45到0.5过低会重复框住同一辆车会把车流计数结果放大。这里saveTrue会保存带框的视频用来做演示素材正好。4. 多端部署实战从ONNX导出到RK3588再用Flask做Web演示界面4.1 把训练好的YOLOv8导出ONNX再转成RK3588的RKNN模型训练产出best.pt后离真正跑在一个嵌入式盒子还有两步。第一步是把PyTorch权重导出为ONNXultralytics一条命令就能完成yolo export modelruns/traffic_yolov8s/weights/best.pt formatonnx opset12 simplifyTrueopset设成12RKNN工具链解析ONNX的兼容性较好simplifyTrue会用onnx-simplifier去掉多余节点转换出的模型更小也更不容易在目标平台上报不支持的算子。导出success后同目录下会出现best.onnx可以先在PC上用onnxruntime跑一遍确认输出张量和pt一致再进入RKNN转换。转RKNN的常见做法是使用RKNN-Toolkit2的Python API在PC上完成而不是直接在板子上转。原因是量化阶段需要跑代表性的校准图片PC内存和显存都更充裕。关键脚本如下from rknn.api import RKNN rknn RKNN() ret rknn.config( target_platformrk3588, mean_values[[0, 0, 0]], std_values[[255, 255, 255]], quantized_dtypew8a8, quantized_algorithmnormal, quantized_methodlayer ) print(config:, ret) rknn.load_onnx(modelbest.onnx) rknn.build( do_quantizationTrue, datasetrknn_calib.txt ) rknn.export_rknn(traffic_yolov8s.rknn)这里config中的mean_values和std_values要和训练时保持一致YOLOv8官方预处理是减0除255所以mean为0std为255。quantized_dtypew8a8表示对权重和激活都做8bit量化RK3588的NPU跑得最快quantized_methodlayer逐层决定量化范围是精度和速度之间的折中方案。do_quantizationTrue启用校准量化依赖rknn_calib.txt这个清单test_frames/frame_0001.jpg test_frames/frame_0002.jpg ...每行一张图片路径我一般从验证集按时间均匀抽300张覆盖白天、傍晚、阴天、路灯开启等车流场景。量化后板上推理的精度通常能保留90%以上但如果校准图片只用20张且全是白天夜间mAP会掉得很厉害后面避坑章会专门展开。4.2 在RK3588上跑RKNN推理并把结果回传Web端部署端我通常用RK3588开发板系统自带NPU驱动。推理代码用RKNN Python接口加队列帧读取是最常见的落地写法。这里给一个核心循环说明车流检测和画框流程import cv2 from rknn.api import RKNN rknn RKNN() rknn.load_rknn(traffic_yolov8s.rknn) rknn.init_runtime() capture cv2.VideoCapture(rtsp://edge-camera/stream) while True: ok, frame capture.read() if not ok: break input_frame cv2.resize(frame, (640, 640)) input_frame input_frame[:, :, ::-1] # BGR to RGB outputs rknn.inference(inputs[input_frame]) boxes, classes, scores postprocess(outputs) for box, score, cls in zip(boxes, scores, classes): cv2.rectangle(frame, (box[0], box[1]), (box[2], box[3]), (0, 255, 0), 2) cv2.imshow(traffic, frame)这段代码有两点要重点说明。第一RKNN推理前要把BGR转成RGB并缩放到训练时相同的640x640如果不转色模型输出的置信度会整体偏低且类别错乱。第二outputs从RKNN返回后通常是原始层的feature map还需要在Python里做一次解码头、聚类和NMS这部分逻辑在训练后的模型导出阶段会自动附在ONNX里但RKNN工具链不会自动补齐所以要自己在项目里维护一个后处理模块。这也是RK3588部署YOLOv8最大的工作量很多人以为做完RKNN转换就万事大吉其实后处理才是真正的坑。如果是毕设演示我更推荐先做一个Flask轻量Web端而不是桌面PyQt界面原因是Web端可以让老师和评委在手机、平板上同时看到检测视频流演示效果更直观。代码简化为from flask import Flask, render_template, Response import cv2 from ultralytics import YOLO app Flask(__name__) model YOLO(runs/traffic_yolov8s/weights/best.pt) def generate_frames(): cap cv2.VideoCapture(0) while True: ok, frame cap.read() if not ok: break results model(frame, verboseFalse) annotated results[0].plot() ret, buffer cv2.imencode(.jpg, annotated) yield (b--frame\r\n bContent-Type: image/jpeg\r\n\r\n buffer.tobytes() b\r\n) app.route(/video_feed) def video_feed(): return Response(generate_frames(), mimetypemultipart/x-mixed-replace; boundaryframe) if __name__ __main__: app.run(host0.0.0.0, port8000)这个Web端虽然简单但足以把检测结果实时推送到浏览器且不依赖桌面环境适合部署在RK3588板子上配合前面的RKNN推理做演示。如果要加车流计数只需要在results[0].boxes里拿到每个目标的类别然后对视频帧中的每辆车做框中心点跟踪这里可以用最简单的按IoU匹配相邻帧的方式毕设答辩时能讲清楚“我按帧差IoU做轻量跟踪”比直接调用DeepSORT更有可信度。如果演示机上没有NVIDIA显卡Flask用CPU跑YOLOv8s速度只有5到8 FPS画面会很卡。因此部署端和展示端最好分开RK3588做NPU推理Flask只做Web流转发和统计展示否则现场容易翻车。5. 车流检测落地中的5个避坑点从夜间漏检到RK3588量化掉分5.1 夜间黑色轿车漏检加暗化增强反而更差现象白天场景mAP50接近0.93一到夜间视频黑色轿车直接消失bus和truck还能检测到。原因最直接的原因是训练集中夜间样本太少模型把近黑色区域和路面纹理混在一起。有人会在训练时把所有图片随机调暗期望提高鲁棒性结果发现夜间目标不仅没召回白天背景也被压低这是“增强策略和真实场景不匹配”导致的翻车。解决我先按时间线从测试视频抽帧标注出100到200张夜间图片放到训练集里重新训练而不是统一做亮度增强。增强参数只开HSV扰动和轻微曝光在ultralytics里通过hsv_h、hsv_s、hsv_v控制例如hsv_h0.015、hsv_s0.7、hsv_v0.4同时不要加过大的随机暗化保持光照分布的原始性。重新训练后夜间车漏检减少最明显的是黑色轿车。5.2 远处小目标车流漏检换大模型不如提高输入分辨率现象在高速高架场景远处车辆只有约20乘20像素用yolov8s在640分辨率下mAP50不错但实拍视频里超过50米的目标全部跳过。原因YOLOv8默认下采样到640乘640输入远处车辆的特征经过多次池化后只剩几个像素后面的脖子和头部很难从中恢复语义。很多同学第一反应是换yolov8m或者yolov8l但6 GB显存下训练不动而且大模型对本就稀疏的小目标特征增益有限。解决在测试阶段对视频做ROI切片把远处车道区域在原图中截取出来放大到640后再送入模型检测框再映射回原图坐标。实在不想做切片可以训练时imgsz960、模型用yolov8n显存开销可控但推理延迟会增加。对于毕设用ROI切片策略性价比最高只需要在视频里框一个固定车道区域不会引入太多新代码。5.3 RK3588量化后精度掉了10个点校准集要按场景抽现象PyTorch模型在PC上mAP50为0.90转换RKNN后在板子上只有0.80尤其夜间和雨天掉得更狠。原因量化是把FP32权重压缩成INT8精度损失本身可控翻车大多出在校准集。有人图省事从训练集随机抽20张图片里面几乎全是白天量化统计出的激活范围对夜间场景完全不适用等于用白天数据定义了整个动态范围。解决校准集应该从验证集按场景和时间抽取300到500张覆盖白天、傍晚、夜间、阴天和雨天且每张图片都要是模型接受的原图尺寸或经过和训练相同的缩放。在RKNN的config里quantized_algorithm可以用mmse代替normal当正常量化掉点严重时mmse会为了保精度小幅增加量化误差分布的计算量如果单层量化导致个别层输出异常再把关键层指定为float16保留。量化后一定要在板子上重复验证夜间视频不要在PC上只测一张白天图就宣布完成。5.4 毕设翻车训练和测试用了同一段视频的相邻帧现象训练时mAP50-95接近0.75换一段新路口的视频后掉到0.5答辩时被老师质疑工作是否真实。原因很多开源车流项目演示视频只有几分钟直接把整段视频抽帧后随机分train/val相邻帧高度相似等于让模型“背”了验证帧。最终得到的优异mAP是数据泄漏的假成绩不是模型的泛化能力。解决数据划分必须按时间顺序而不是随机划分。我会取同一摄像头连续视频前8分钟抽帧做训练最后2分钟抽帧做验证中间空出30秒过渡保证没有相邻帧泄漏。如果混合了多个路口那么每个路口都要各取独立时间段进验证集。这个习惯写进毕设的“实验设计”里答辩时非常加印象分。5.5 GTX 1660Ti训练OOM不是模型选错是batch和缓存策略没调整现象训练启动后不到10秒报CUDA out of memory甚至把浏览器都卡死。原因1660Ti只有6 GB显存训练时若采用默认的batch16很容易爆掉。部分教程默认读者用的是3090、4090照抄batch数值是OOM最直接的原因。有时候不是batch而是在Windows下同时开了视频解码和浏览器显存和内存都被占了一部分。解决把batch降到8或4并在训练命令中显式加workers2降低数据加载线程压力。如果还想稳一点直接换yolov8n模型输入分辨率保持6406 GB显存下训练batch可以回到16。同时关闭其他GPU程序不要一边训练一边在浏览器里播放高码率视频这是最容易忽略的习惯问题。6. 验收技巧把损失曲线、视频回放和计数误差放在一张表里判断模型训练完后不要只贴mAP。我会做一次“三件套”验证第一件看runs下的results.png里val loss有没有反常回升第二件把best.pt跑三段不同时段的视频输出带框视频用肉眼确认有没有把树影、路灯当车第三件在每段视频里人工数一遍真实车数和模型计的数对比。为了不让计数过程太枯燥我通常写个简单脚本把每类计数结果输出到csv然后手工汇总成验证表。实际执行时我用一个很简单的统计脚本import cv2 from ultralytics import YOLO model YOLO(best.pt) counts {car: 0, bus: 0, truck: 0, motorcycle: 0, bicycle: 0} for video in [day.mp4, night.mp4, rain.mp4]: cap cv2.VideoCapture(video) frame_id 0 while cap.isOpened(): ok, frame cap.read() if not ok: break if frame_id % 5 0: result model(frame, verboseFalse)[0] for box in result.boxes: cls_name result.names[int(box.cls)] if cls_name in counts: counts[cls_name] 1 frame_id 1 cap.release() print(video, counts)注意这是“按帧累计”的近似统计不是真正的目标计数因为同一辆车会出现在多帧里。但用于验证检测器“有没有把类别认错”已经够用。我在毕设演示里会把这个脚本的结果做成一张表白天、夜间、雨天三段视频分别统计真实车辆数、检测数、单帧推理时间并标注漏检最多的是哪一类然后用文字解释漏检原因。这个习惯帮我在答辩前提前发现过夜间黑色轿车漏检也避免了现场被问到遮挡场景时无话可说。最后说一个我的习惯无论换多少次参数都要把改过的数据集划分和时间戳记录在实验笔记里不要只记录最终命令。否则一周后你自己也说不清当前权重是用哪些图片训出来的这比模型本身不work更让人崩溃。希望这篇笔记能把你在车流检测毕设里的坑提前扫掉少走几段弯路。本文还有配套的精品资源点击获取