简介这份PDF教程面向智能交通领域开发者、计算机视觉学习者与自动驾驶方向研究人员围绕YOLOv11在实时车辆速度估计与轨迹追踪中的落地应用展开帮助读者从算法原理走向工程实战。文档共45页支持目录章节跳转与阅读器左侧大纲快速定位内容完整、条理清晰图表与文字显示正常。资源包为单一PDF文件大小约2.29MB轻量便携适合随时查阅。教程从智能交通需求分析切入依次讲解YOLOv11网络架构、预测机制与损失函数并延伸至系统架构设计、数据采集与处理、模型训练优化、速度估计算法实现及轨迹追踪算法实现等模块涵盖SIFT与ORB特征点匹配、Lucas-Kanade光流法、卡尔曼滤波、匈牙利算法、SORT与DeepSORT等关键技术同时涉及多传感器融合、抗遮挡处理与实时性优化思路。目前已有77人学习适合希望系统掌握YOLOv11智能交通实战方案、对照代码理解算法细节的读者参考。1. YOLOv11 做实时车辆测速为什么“检测准”不等于“速度准”很多人第一次用 YOLOv11 做智能交通项目都会卡在同一个地方检测框画得挺漂亮车辆 ID 也跟得住但速度一出来就飘得离谱。问题不在 YOLOv11 本身而在于速度估计是一条完整的测量链路——检测、追踪、像素到米的标定、帧间位移、时间戳对齐任何一环出问题最后那个 km/h 数字就是错的。YOLOv11 在这里的角色是“眼睛”它负责每帧给出车辆位置真正决定速度精度的是你如何把像素位移换算成真实位移以及如何处理追踪 ID 跳变和帧率抖动。这篇内容面向已经跑通 YOLOv11 推理、想把它落到交通视频测速场景的工程师从环境配置、追踪器选型、标定方法一路写到避坑和验证代码可直接复现。2. 环境配置与最小推理链路先把 YOLOv11 跑起来2.1 安装 ultralytics 与验证 GPU 推理YOLOv11 通过 ultralytics 包调用环境配置本身不复杂但版本和 CUDA 匹配是第一个容易翻车的地方。我一般用 conda 建独立环境避免和系统里的 torch 打架。conda create -n yolo11 python3.10 -y conda activate yolo11 # 按本机 CUDA 版本装 torch这里以 CUDA 12.1 为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install ultralytics opencv-python numpy装完后先验证 GPU 是否被 torch 识别再跑一次官方权重推理。权重文件在首次调用时会自动下载到本地缓存目录不需要手动找下载链接。import torch from ultralytics import YOLO print(CUDA available:, torch.cuda.is_available()) print(Device:, torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU) # 加载 YOLOv11 检测权重首次运行会自动下载 model YOLO(yolo11n.pt) # 对单张图推理conf 控制置信度阈值 results model.predict(test.jpg, conf0.4, device0, verboseFalse) for r in results: print(检测框数量:, len(r.boxes)) print(类别:, r.boxes.cls.tolist())逻辑说明YOLO(yolo11n.pt)加载的是 nano 版本适合先跑通链路conf0.4是检测置信度阈值交通场景建议 0.350.5太低会引入大量误检太高会漏掉远处小车。device0指定第一块 GPU没有 GPU 就删掉这个参数走 CPU但实时性会差很多。参数选择上n/s/m/l/x 五个规格里实时测速场景我一般选yolo11s或yolo11mn 太快但小目标召回不够l/x 精度好但单帧耗时上去了追踪和测速环节还要占时间。如果做的是 yolov11 小目标优化可以在推理时把imgsz从默认 640 提到 960 或 1280代价是速度下降需要根据你的帧率预算权衡。2.2 视频流读取与逐帧推理骨架测速必须按帧处理并且要拿到每帧的时间戳。很多人直接用cv2.VideoCapture的帧序号除以 FPS 当时间这在固定帧率视频上勉强能用但监控视频经常有丢帧或变帧率必须用真实时间戳。import cv2 import time from ultralytics import YOLO model YOLO(yolo11s.pt) cap cv2.VideoCapture(traffic.mp4) fps cap.get(cv2.CAP_PROP_FPS) print(视频标称 FPS:, fps) frame_id 0 while True: ret, frame cap.read() if not ret: break t time.time() # 实际处理时间戳用于后续速度计算 results model.track(frame, persistTrue, conf0.4, trackerbytetrack.yaml, verboseFalse) # results[0].boxes.id 是追踪 IDNone 表示该帧没跟上 frame_id 1 cap.release()逻辑说明model.track是 ultralytics 内置的追踪接口persistTrue让追踪器在帧间保持状态trackerbytetrack.yaml指定用 ByteTrack。这一步同时完成检测和追踪输出里boxes.id就是每个目标的追踪 ID。注意time.time()取的是处理时刻如果你要精确测速应该用视频本身的 PTS 时间戳后面标定章节会讲怎么处理。3. 轨迹追踪与 ID 稳定性ByteTrack 够不够用3.1 ByteTrack 与 BoT-SORT 在交通场景的差异ultralytics 内置了 ByteTrack 和 BoT-SORT 两种追踪器配置文件在包目录的cfg/trackers/下。交通场景我实测下来ByteTrack 速度快、对遮挡恢复一般BoT-SORT 带 ReID 特征ID 切换少但每帧多一次特征提取帧率会掉 15%30%。追踪器优点缺点适用场景ByteTrack轻量、速度快遮挡后易换 ID车流稀疏、帧率优先BoT-SORTID 稳定、抗遮挡计算量大车流密集、精度优先选型建议如果你只是做演示或车流不密集ByteTrack 足够如果要统计每辆车的完整轨迹做测速BoT-SORT 更稳。切换只需要改tracker参数results model.track(frame, persistTrue, conf0.4, trackerbotsort.yaml, verboseFalse)3.2 用追踪 ID 维护轨迹字典测速需要每辆车的历史位置序列所以必须自己维护一个track_id - [(timestamp, cx, cy), ...]的字典。这里有个血泪经验追踪 ID 会在目标消失几帧后重新出现时变成新 ID如果不做处理同一辆车会被算成两段轨迹速度直接断掉。from collections import defaultdict, deque # 每辆车保留最近 30 帧的位置deque 自动丢弃旧数据 tracks defaultdict(lambda: deque(maxlen30)) def update_tracks(results, timestamp): boxes results[0].boxes if boxes.id is None: return ids boxes.id.int().cpu().tolist() xyxy boxes.xyxy.cpu().numpy() for tid, box in zip(ids, xyxy): cx (box[0] box[2]) / 2 cy (box[1] box[3]) / 2 tracks[tid].append((timestamp, cx, cy))逻辑说明deque(maxlen30)限制每辆车只保留最近 30 帧防止内存无限增长也保证速度计算只用近期位移。cx, cy取检测框中心点比用框角点稳定因为框的宽高会随视角变化抖动。时间戳用视频 PTS 而不是处理时间后面会讲怎么取。参数上maxlen的选择取决于你的帧率和测速窗口30 帧在 30fps 下是 1 秒足够算瞬时速度如果你要算更平滑的平均速度可以加到 60 或 90。但窗口太长会把加减速过程抹平交通测速一般 0.51.5 秒窗口比较合适。4. 像素到米的标定速度估计的精度命门4.1 逆透视变换做路面标定这是整个项目最容易翻车的地方。YOLOv11 给你的是像素坐标速度要的是米/秒中间必须有一个像素到米的映射。常见做法有两种一是用已知长度的参照物比如车道线标准宽度做比例尺二是用逆透视变换IPM把路面投影成俯视图在俯视图里像素和米是线性关系。我一般用四点标定法在画面里选一个矩形路面的四个角点对应真实世界里的一个矩形区域用cv2.getPerspectiveTransform求变换矩阵。import cv2 import numpy as np # 画面中路面矩形的四个角点像素坐标需按你的视频手动标 src_pts np.float32([[320, 480], [960, 480], [1200, 720], [80, 720]]) # 真实世界对应的矩形单位米假设宽 14 米、长 20 米 dst_pts np.float32([[0, 0], [14, 0], [14, 20], [0, 20]]) M cv2.getPerspectiveTransform(src_pts, dst_pts) def pixel_to_meter(px, py): # 把像素点映射到俯视图的米制坐标 pt np.array([[[px, py]]], dtypenp.float32) mapped cv2.perspectiveTransform(pt, M) return mapped[0][0][0], mapped[0][0][1]逻辑说明src_pts是你在画面上量出来的四个点dst_pts是你假设的真实尺寸。这里的关键是dst_pts的宽高必须和实际路面吻合否则速度会整体偏大或偏小。标定一次可以用很久但相机一动就得重标。参数说明src_pts的顺序必须是左上、右上、右下、左下和dst_pts一一对应顺序错了变换矩阵就废了。真实尺寸的获取方式用车道线标准宽度一般 3.5 米或路面已知标记物反推。如果实在没有参照可以用一辆已知车长的车做标定误差能控制在 5% 以内。4.2 速度计算与平滑有了米制坐标速度就是位移除以时间。但逐帧算速度噪声极大必须做平滑。我一般用最近 N 帧的位移做线性拟合斜率就是速度。import numpy as np def estimate_speed(track, M): if len(track) 5: return None pts [] for ts, cx, cy in track: mx, my pixel_to_meter(cx, cy) pts.append((ts, mx, my)) pts np.array(pts) # 对 x 和 y 分别做一次线性拟合斜率即速度分量 vx np.polyfit(pts[:, 0], pts[:, 1], 1)[0] vy np.polyfit(pts[:, 0], pts[:, 2], 1)[0] speed np.sqrt(vx**2 vy**2) # 米/秒 return speed * 3.6 # 转 km/h逻辑说明np.polyfit对时间-位移做一次拟合斜率就是平均速度比逐帧差分稳定得多。要求至少 5 个点是为了保证拟合有意义。vx和vy是速度在俯视图两个方向的分量合成后乘 3.6 得到 km/h。参数上拟合窗口就是track的长度前面设了 30 帧。如果你的场景车速变化快可以缩短到 15 帧如果噪声大加到 45 帧。注意polyfit对异常点敏感如果追踪框某几帧跳了速度会瞬间飙高所以后面避坑章节会讲怎么做异常值剔除。5. 避坑与排查测速翻车的五个真实原因5.1 速度整体偏大或偏小现象所有车速度都偏高 20% 或偏低。原因标定用的真实尺寸和实际路面不符或者src_pts点选得不准。解决用一辆已知车长的车验证调整dst_pts的宽高比例直到已知车速和估计值吻合。5.2 追踪 ID 频繁跳变导致速度断点现象同一辆车速度曲线出现尖峰或归零。原因遮挡或检测漏帧导致 ByteTrack 分配了新 ID。解决换 BoT-SORT或者在轨迹字典里做 ID 合并——如果新 ID 的起始位置和某个消失 ID 的末尾位置在时空上接近就合并成同一条轨迹。5.3 帧时间戳不准导致速度抖动现象速度值在相邻帧之间大幅波动。原因用处理时间time.time()当帧时间GPU 推理耗时不稳定。解决用cv2.CAP_PROP_POS_MSEC取视频真实时间戳或者对处理时间做滑动平均后再用。5.4 远处车辆速度误差大现象近处车速度准远处车速度离谱。原因透视变换在画面远端像素密度低一个像素对应的实际距离很大检测框几个像素的抖动就被放大成几 km/h。解决对远处目标降低权重或者只对画面中下部区域做测速远端只做追踪不做速度输出。5.5 置信度阈值设太低引入误检现象速度列表里出现不存在的车。原因conf设太低路面反光或阴影被当成车。解决把conf提到 0.45 以上同时加类别过滤只保留 car、bus、truck 这几类。6. 验证与进阶怎么确认你的速度是可信的测速做完怎么知道准不准我一般用两个方法交叉验证。第一个是定速巡航参照找一段已知限速的路段或者用一辆带 GPS 的车跑一遍对比估计值和 GPS 速度误差在 10% 以内算合格。第二个是帧率一致性检查同一辆车在视频不同时间段的速度应该连续如果出现跳变说明追踪或标定有问题。进阶用法上如果你要做多摄像头接力测速核心是统一时间基准和坐标系。每个相机单独标定输出世界坐标下的轨迹再按时间戳融合。这时候 YOLOv11 的推理结果要保存成结构化数据方便后续处理import json def save_frame_result(frame_id, timestamp, tracks, out_file): record {frame: frame_id, ts: timestamp, vehicles: []} for tid, track in tracks.items(): if len(track) 2: continue ts, cx, cy track[-1] record[vehicles].append({ id: tid, cx: cx, cy: cy, speed_kmh: estimate_speed(track, M) }) out_file.write(json.dumps(record) \n)逻辑说明每帧存一条 JSON包含帧号、时间戳和每辆车的 ID、位置、速度。这样后续做轨迹回放、多相机融合、或者离线调参都不用重新跑推理。estimate_speed返回 None 时 JSON 里就是 null下游处理时跳过即可。参数上保存频率建议每帧都存文件会大但信息完整如果只做统计可以每 5 帧存一次。JSON Lines 格式比单个大 JSON 好处理可以流式读取不会一次性吃满内存。最后说个我自己的习惯每次调完标定参数我都会拿同一段视频跑三遍看速度曲线的重合度。如果三遍差异超过 5%说明链路里还有随机因素没控住通常是追踪 ID 不稳定或者时间戳抖动。这个习惯帮我省了很多次返工。希望帮到你。本文还有配套的精品资源点击获取 YOLOv11实时车辆测速实战：从检测到速度估计的完整链路与避坑指南
简介这份PDF教程面向智能交通领域开发者、计算机视觉学习者与自动驾驶方向研究人员围绕YOLOv11在实时车辆速度估计与轨迹追踪中的落地应用展开帮助读者从算法原理走向工程实战。文档共45页支持目录章节跳转与阅读器左侧大纲快速定位内容完整、条理清晰图表与文字显示正常。资源包为单一PDF文件大小约2.29MB轻量便携适合随时查阅。教程从智能交通需求分析切入依次讲解YOLOv11网络架构、预测机制与损失函数并延伸至系统架构设计、数据采集与处理、模型训练优化、速度估计算法实现及轨迹追踪算法实现等模块涵盖SIFT与ORB特征点匹配、Lucas-Kanade光流法、卡尔曼滤波、匈牙利算法、SORT与DeepSORT等关键技术同时涉及多传感器融合、抗遮挡处理与实时性优化思路。目前已有77人学习适合希望系统掌握YOLOv11智能交通实战方案、对照代码理解算法细节的读者参考。1. YOLOv11 做实时车辆测速为什么“检测准”不等于“速度准”很多人第一次用 YOLOv11 做智能交通项目都会卡在同一个地方检测框画得挺漂亮车辆 ID 也跟得住但速度一出来就飘得离谱。问题不在 YOLOv11 本身而在于速度估计是一条完整的测量链路——检测、追踪、像素到米的标定、帧间位移、时间戳对齐任何一环出问题最后那个 km/h 数字就是错的。YOLOv11 在这里的角色是“眼睛”它负责每帧给出车辆位置真正决定速度精度的是你如何把像素位移换算成真实位移以及如何处理追踪 ID 跳变和帧率抖动。这篇内容面向已经跑通 YOLOv11 推理、想把它落到交通视频测速场景的工程师从环境配置、追踪器选型、标定方法一路写到避坑和验证代码可直接复现。2. 环境配置与最小推理链路先把 YOLOv11 跑起来2.1 安装 ultralytics 与验证 GPU 推理YOLOv11 通过 ultralytics 包调用环境配置本身不复杂但版本和 CUDA 匹配是第一个容易翻车的地方。我一般用 conda 建独立环境避免和系统里的 torch 打架。conda create -n yolo11 python3.10 -y conda activate yolo11 # 按本机 CUDA 版本装 torch这里以 CUDA 12.1 为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install ultralytics opencv-python numpy装完后先验证 GPU 是否被 torch 识别再跑一次官方权重推理。权重文件在首次调用时会自动下载到本地缓存目录不需要手动找下载链接。import torch from ultralytics import YOLO print(CUDA available:, torch.cuda.is_available()) print(Device:, torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU) # 加载 YOLOv11 检测权重首次运行会自动下载 model YOLO(yolo11n.pt) # 对单张图推理conf 控制置信度阈值 results model.predict(test.jpg, conf0.4, device0, verboseFalse) for r in results: print(检测框数量:, len(r.boxes)) print(类别:, r.boxes.cls.tolist())逻辑说明YOLO(yolo11n.pt)加载的是 nano 版本适合先跑通链路conf0.4是检测置信度阈值交通场景建议 0.350.5太低会引入大量误检太高会漏掉远处小车。device0指定第一块 GPU没有 GPU 就删掉这个参数走 CPU但实时性会差很多。参数选择上n/s/m/l/x 五个规格里实时测速场景我一般选yolo11s或yolo11mn 太快但小目标召回不够l/x 精度好但单帧耗时上去了追踪和测速环节还要占时间。如果做的是 yolov11 小目标优化可以在推理时把imgsz从默认 640 提到 960 或 1280代价是速度下降需要根据你的帧率预算权衡。2.2 视频流读取与逐帧推理骨架测速必须按帧处理并且要拿到每帧的时间戳。很多人直接用cv2.VideoCapture的帧序号除以 FPS 当时间这在固定帧率视频上勉强能用但监控视频经常有丢帧或变帧率必须用真实时间戳。import cv2 import time from ultralytics import YOLO model YOLO(yolo11s.pt) cap cv2.VideoCapture(traffic.mp4) fps cap.get(cv2.CAP_PROP_FPS) print(视频标称 FPS:, fps) frame_id 0 while True: ret, frame cap.read() if not ret: break t time.time() # 实际处理时间戳用于后续速度计算 results model.track(frame, persistTrue, conf0.4, trackerbytetrack.yaml, verboseFalse) # results[0].boxes.id 是追踪 IDNone 表示该帧没跟上 frame_id 1 cap.release()逻辑说明model.track是 ultralytics 内置的追踪接口persistTrue让追踪器在帧间保持状态trackerbytetrack.yaml指定用 ByteTrack。这一步同时完成检测和追踪输出里boxes.id就是每个目标的追踪 ID。注意time.time()取的是处理时刻如果你要精确测速应该用视频本身的 PTS 时间戳后面标定章节会讲怎么处理。3. 轨迹追踪与 ID 稳定性ByteTrack 够不够用3.1 ByteTrack 与 BoT-SORT 在交通场景的差异ultralytics 内置了 ByteTrack 和 BoT-SORT 两种追踪器配置文件在包目录的cfg/trackers/下。交通场景我实测下来ByteTrack 速度快、对遮挡恢复一般BoT-SORT 带 ReID 特征ID 切换少但每帧多一次特征提取帧率会掉 15%30%。追踪器优点缺点适用场景ByteTrack轻量、速度快遮挡后易换 ID车流稀疏、帧率优先BoT-SORTID 稳定、抗遮挡计算量大车流密集、精度优先选型建议如果你只是做演示或车流不密集ByteTrack 足够如果要统计每辆车的完整轨迹做测速BoT-SORT 更稳。切换只需要改tracker参数results model.track(frame, persistTrue, conf0.4, trackerbotsort.yaml, verboseFalse)3.2 用追踪 ID 维护轨迹字典测速需要每辆车的历史位置序列所以必须自己维护一个track_id - [(timestamp, cx, cy), ...]的字典。这里有个血泪经验追踪 ID 会在目标消失几帧后重新出现时变成新 ID如果不做处理同一辆车会被算成两段轨迹速度直接断掉。from collections import defaultdict, deque # 每辆车保留最近 30 帧的位置deque 自动丢弃旧数据 tracks defaultdict(lambda: deque(maxlen30)) def update_tracks(results, timestamp): boxes results[0].boxes if boxes.id is None: return ids boxes.id.int().cpu().tolist() xyxy boxes.xyxy.cpu().numpy() for tid, box in zip(ids, xyxy): cx (box[0] box[2]) / 2 cy (box[1] box[3]) / 2 tracks[tid].append((timestamp, cx, cy))逻辑说明deque(maxlen30)限制每辆车只保留最近 30 帧防止内存无限增长也保证速度计算只用近期位移。cx, cy取检测框中心点比用框角点稳定因为框的宽高会随视角变化抖动。时间戳用视频 PTS 而不是处理时间后面会讲怎么取。参数上maxlen的选择取决于你的帧率和测速窗口30 帧在 30fps 下是 1 秒足够算瞬时速度如果你要算更平滑的平均速度可以加到 60 或 90。但窗口太长会把加减速过程抹平交通测速一般 0.51.5 秒窗口比较合适。4. 像素到米的标定速度估计的精度命门4.1 逆透视变换做路面标定这是整个项目最容易翻车的地方。YOLOv11 给你的是像素坐标速度要的是米/秒中间必须有一个像素到米的映射。常见做法有两种一是用已知长度的参照物比如车道线标准宽度做比例尺二是用逆透视变换IPM把路面投影成俯视图在俯视图里像素和米是线性关系。我一般用四点标定法在画面里选一个矩形路面的四个角点对应真实世界里的一个矩形区域用cv2.getPerspectiveTransform求变换矩阵。import cv2 import numpy as np # 画面中路面矩形的四个角点像素坐标需按你的视频手动标 src_pts np.float32([[320, 480], [960, 480], [1200, 720], [80, 720]]) # 真实世界对应的矩形单位米假设宽 14 米、长 20 米 dst_pts np.float32([[0, 0], [14, 0], [14, 20], [0, 20]]) M cv2.getPerspectiveTransform(src_pts, dst_pts) def pixel_to_meter(px, py): # 把像素点映射到俯视图的米制坐标 pt np.array([[[px, py]]], dtypenp.float32) mapped cv2.perspectiveTransform(pt, M) return mapped[0][0][0], mapped[0][0][1]逻辑说明src_pts是你在画面上量出来的四个点dst_pts是你假设的真实尺寸。这里的关键是dst_pts的宽高必须和实际路面吻合否则速度会整体偏大或偏小。标定一次可以用很久但相机一动就得重标。参数说明src_pts的顺序必须是左上、右上、右下、左下和dst_pts一一对应顺序错了变换矩阵就废了。真实尺寸的获取方式用车道线标准宽度一般 3.5 米或路面已知标记物反推。如果实在没有参照可以用一辆已知车长的车做标定误差能控制在 5% 以内。4.2 速度计算与平滑有了米制坐标速度就是位移除以时间。但逐帧算速度噪声极大必须做平滑。我一般用最近 N 帧的位移做线性拟合斜率就是速度。import numpy as np def estimate_speed(track, M): if len(track) 5: return None pts [] for ts, cx, cy in track: mx, my pixel_to_meter(cx, cy) pts.append((ts, mx, my)) pts np.array(pts) # 对 x 和 y 分别做一次线性拟合斜率即速度分量 vx np.polyfit(pts[:, 0], pts[:, 1], 1)[0] vy np.polyfit(pts[:, 0], pts[:, 2], 1)[0] speed np.sqrt(vx**2 vy**2) # 米/秒 return speed * 3.6 # 转 km/h逻辑说明np.polyfit对时间-位移做一次拟合斜率就是平均速度比逐帧差分稳定得多。要求至少 5 个点是为了保证拟合有意义。vx和vy是速度在俯视图两个方向的分量合成后乘 3.6 得到 km/h。参数上拟合窗口就是track的长度前面设了 30 帧。如果你的场景车速变化快可以缩短到 15 帧如果噪声大加到 45 帧。注意polyfit对异常点敏感如果追踪框某几帧跳了速度会瞬间飙高所以后面避坑章节会讲怎么做异常值剔除。5. 避坑与排查测速翻车的五个真实原因5.1 速度整体偏大或偏小现象所有车速度都偏高 20% 或偏低。原因标定用的真实尺寸和实际路面不符或者src_pts点选得不准。解决用一辆已知车长的车验证调整dst_pts的宽高比例直到已知车速和估计值吻合。5.2 追踪 ID 频繁跳变导致速度断点现象同一辆车速度曲线出现尖峰或归零。原因遮挡或检测漏帧导致 ByteTrack 分配了新 ID。解决换 BoT-SORT或者在轨迹字典里做 ID 合并——如果新 ID 的起始位置和某个消失 ID 的末尾位置在时空上接近就合并成同一条轨迹。5.3 帧时间戳不准导致速度抖动现象速度值在相邻帧之间大幅波动。原因用处理时间time.time()当帧时间GPU 推理耗时不稳定。解决用cv2.CAP_PROP_POS_MSEC取视频真实时间戳或者对处理时间做滑动平均后再用。5.4 远处车辆速度误差大现象近处车速度准远处车速度离谱。原因透视变换在画面远端像素密度低一个像素对应的实际距离很大检测框几个像素的抖动就被放大成几 km/h。解决对远处目标降低权重或者只对画面中下部区域做测速远端只做追踪不做速度输出。5.5 置信度阈值设太低引入误检现象速度列表里出现不存在的车。原因conf设太低路面反光或阴影被当成车。解决把conf提到 0.45 以上同时加类别过滤只保留 car、bus、truck 这几类。6. 验证与进阶怎么确认你的速度是可信的测速做完怎么知道准不准我一般用两个方法交叉验证。第一个是定速巡航参照找一段已知限速的路段或者用一辆带 GPS 的车跑一遍对比估计值和 GPS 速度误差在 10% 以内算合格。第二个是帧率一致性检查同一辆车在视频不同时间段的速度应该连续如果出现跳变说明追踪或标定有问题。进阶用法上如果你要做多摄像头接力测速核心是统一时间基准和坐标系。每个相机单独标定输出世界坐标下的轨迹再按时间戳融合。这时候 YOLOv11 的推理结果要保存成结构化数据方便后续处理import json def save_frame_result(frame_id, timestamp, tracks, out_file): record {frame: frame_id, ts: timestamp, vehicles: []} for tid, track in tracks.items(): if len(track) 2: continue ts, cx, cy track[-1] record[vehicles].append({ id: tid, cx: cx, cy: cy, speed_kmh: estimate_speed(track, M) }) out_file.write(json.dumps(record) \n)逻辑说明每帧存一条 JSON包含帧号、时间戳和每辆车的 ID、位置、速度。这样后续做轨迹回放、多相机融合、或者离线调参都不用重新跑推理。estimate_speed返回 None 时 JSON 里就是 null下游处理时跳过即可。参数上保存频率建议每帧都存文件会大但信息完整如果只做统计可以每 5 帧存一次。JSON Lines 格式比单个大 JSON 好处理可以流式读取不会一次性吃满内存。最后说个我自己的习惯每次调完标定参数我都会拿同一段视频跑三遍看速度曲线的重合度。如果三遍差异超过 5%说明链路里还有随机因素没控住通常是追踪 ID 不稳定或者时间戳抖动。这个习惯帮我省了很多次返工。希望帮到你。本文还有配套的精品资源点击获取