YOLO26单目测距测速开源Demo：检测跟踪到距离估算完整管线-平芜编程栈

最近这类项目热度很高：把“目标检测”和“单目测距/测速”放在一起做。这次我们看的这款开源 Demo，就是围绕 YOLO26 搭好的一条完整感知管线：检测 → 多目标跟踪 → 单目深度测距 → 速度估算。它不是让你从零拼四个模块，而是把整条链路先跑通，再逐段优化。

简单说，这个项目解决的是“视频里有车有人，我除了要知道它们是什么，还想在二维画面里估算它在真实世界里离我多远、移动多快”。单目摄像头只有一个普通 RGB 视频流，没有雷达、没有深度相机，这类需求在智能交通、园区安防、辅助驾驶验证中很常见。项目最值得关注的几个点：第一，基于 YOLO26 做检测，识别能力跟得上新模型；第二，加入了跟踪器，能稳定地给同一个目标分配 ID；第三，用单目几何约束估算距离，再通过跨帧位移计算速度；第四，管线本身是打通封闭的，输出可以是可视化视频，也可以是结构化轨迹数据。

硬件门槛没有想象中那么高，但如果要跑得比较顺，推荐准备 N VIDIA GPU，显存 8GB 起步会比较从容。需要提前说明的是：网络上的“YOLO26 版本”有时对应不同结构和权重文件，所以实际显存占用、启动脚本、配置文件命名，都要以你拉到的这份开源仓库源码为准，最好先看 README，再跑脚本。

这篇文章会带你拆开这条“检测→跟踪→测距→测速”管线，讲清楚每个模块为什么存在、单目测距的几种常见做法、环境要装哪些东西、Demo 怎么启动、功能怎么验证、精度怎么测，也会把批量处理、HTTP 接口、显存和 CPU 占用、常见坑都过一遍。适合这几类读者：正在做大作业或毕业设计、想快速验证 YOLO26 + 单目测距链路的同学；做园区 / 封闭道路视频结构化项目的工程师；以及想理解“单目测速误差从哪里来”的算法爱好者。

1. 核心能力速览

能力项	说明
项目类型	YOLO26 目标检测 + 多目标跟踪 + 单目测距 + 速度估算的贯通式开源 Demo
主要功能	对单目摄像头画面中的车辆 / 行人等目标进行实时检测、ID 跟踪、距离估算和速度估算
技术管线	Detection（检测）→ Tracking（跟踪）→ Distance（单目测距）→ Speed（速度估算）
检测模型	YOLO26，具体结构、权重文件、模型尺寸以发布仓库为准
跟踪方式	常见会使用 ByteTrack / BOT-SORT 等跟踪器，也可能自定义轻量跟踪模块，需查看源码
测距方式	基于相机标定 + 目标底部位置 / 已知物理尺寸的几何法，或接 YOLO26 depth 分支 / 深度先验模型
测速方式	目标跨帧时间戳与位移换算，叠加滤波平滑或参考线法
推荐硬件	NVIDIA GPU 优先，显存建议 8GB 起步；低分辨率 + 小模型可尝试 CPU
支持平台	Windows / Linux 均可，需安装对应 CUDA / PyTorch
启动方式	命令行 + 配置文件，或仓库自带一键脚本
是否支持 API	通常可扩展 HTTP 接口，需要按源码暴露接口封装
是否支持批量任务	图片 / 视频目录批量处理可以做，但测速必须保留同一目标的跨帧记录
适合场景	园区感知实验、封闭道路或停车场结构化分析、科研验证、教学 Demo

表格中凡是涉及“具体值”的信息，比如显存占用、权重尺寸、支持哪些摄像头型号、自带模型只有 COCO 预训练还是有汽车测距微调版本，请直接去看你 clone 到的项目 README。这类开源 Demo 大概率会提供一份可以跑通的配置，但不同提交版本的差异会很大。

2. 适用场景与使用边界

先说适合用在哪儿。

园区、封闭厂区、停车场出入口的车辆与行人相对距离展示。
单目相机固定视角下的交通参与者轨迹结构化，比如输出“从哪条车道过来、在画面里停留多久、平均速度多少”。
作为高校毕设、课程设计的完整 Demo，能体现“检测→跟踪→测距→测速”系统性思路。
帮助理解单目测距的精度边界：它不会是最终测量工具，但对原型验证来说非常合适。

不适合什么场景，也要说清楚。单目测距天然存在尺度不确定性。同一辆车在一帧里看起来小，到底是因为实际远，还是因为摄像头焦距不同，或者目标本身尺寸小，单帧画面无法严格区分。所以它不适合用于要求厘米级绝对位置、依赖单帧做紧急制动的自动驾驶主感知系统，也不适合作为开放道路的执法级测速设备。你可以把结果当作“辅助参考距离”和“趋势估计”，不能直接替代毫米波雷达或激光雷达。

合规和边界也要提一级。Demo 处理的是视频中的车辆和行人，如果你的输入来自城市道路、公共监控，要先确认是否具备拍摄、处理、使用这些视频的授权。涉及人脸、车牌、行人隐私时，尽量做脱敏处理。不要用该项目对路上的车辆进行测速取证，更不能输出针对特定驾驶员的判断结论。凡是涉及行人位置、速度的场景，发布或商用前一定要做人工复核。项目如果要用摄像头实时画面，测试环境建议放在自己有权部署的园区、停车场或实验室，避免合规风险。

3. 技术原理：检测到测速这条管线怎么串起来

只看项目名会觉得“检测、跟踪、测距、测速”是四个并列模块，但真正落地时它们有严格依赖关系：没有检测就没有目标框，没有目标框就没法跟踪，单帧检测框又不足以保证速度稳定，因此必须靠跟踪器做跨帧关联，最后再结合相机参数计算真实位移。

3.1 数据流设计

一帧图像进入管线后的典型数据流如下：

YOLO26 输出目标检测框、类别和置信度。
跟踪器根据检测框与之前帧的目标进行匹配，给每个目标分配唯一 ID。
对每个跟踪目标，取检测框底部中心点，结合相机标定参数，映射到地面坐标并估算其距摄像头的水平距离。
保存该目标最近若干帧的距离、时间戳、画面坐标，计算位移变化。
在输出画面上绘制检测框、ID、距离和速度。

这里最容易被忽略的是：YOLO26 只负责“这一帧哪里有什么”，它不负责“上一帧的这辆车是不是这一辆”。如果不做跟踪，测速就会变成“拿这帧 0 号车的框架，去跟上一帧 0 号车比较”，一旦目标交叉、换道、遮挡，距离和速度全部乱掉。所以跟踪模块是测速准确性的底座。

3.2 单目测距常用方法

根据 YOLO26 单目测距类项目的常见实现，有三种做法很典型。

第一种：基于已知物理尺寸的相似三角形法。

如果知道目标真实物理尺寸，比如普通轿车宽度约为 1.8 米，摄像头焦距为 f（像素单位），目标检测框宽度为 w（像素单位），那么深度可以近似为：

Z ≈ (f * W) / w

其中 W 为目标真实宽度，Z 为到摄像头的深度距离。这个公式简单直观，适合车辆这种尺寸相对稳定的刚性目标。但对行人效果较差，因为行人宽度不稳定，检测框会把两臂、随身物品都算进去。而且只要目标类别混了，比如把一辆三轮货车识别成小客车，测距结果就会偏。

第二种：检测框底部中心点投到地面。

对于车辆、行人，真正有用的是它们“踩在地面上的点”。一般取检测框底边中心像素坐标，再通过针孔相机模型把它投影到地平面。这种做法对相机外参更敏感，要求相机安装高度、俯仰角正确。如果相机倾斜角度标错，几十米外的距离误差会迅速放大。

第三种：直接让模型输出深度或距离。

对应到 YOLO26 生态里，就是给 YOLO26 加一个 depth 或 distance 回归头，或者在检测外部再接一个单目深度估计模型，例如 Depth Anything、MiDaS 等，把深度值作为先验。这种方案能缓解“没有几何标定”的问题，但绝对尺度仍然需要修正，否则拿到的只是相对深度，不是米制距离。

实际项目中三种方法可以混合使用：车辆用类别先验宽度、行人用底部地面投影、深度模型作为远距离修正。具体代码里用哪一种，以仓库 README 和源码为准。重要的是，无论哪种几何方案，都需要知道相机的内参或者安装高度；完全不标定就声称“单目测距米数准确”，这从原理上就站不住脚。

3.3 跟踪模块为什么不能省

跟踪模块的作用主要有三点：

给不同目标分配稳定 ID，让后续测速有“轨迹”可言。
对短暂漏检进行插值，减少检测丢失导致的速度跳变。
过滤置信度低的孤立检测框，避免把闪烁框当成真实目标。

实际 YOLO26 项目里常配 ByteTrack、BOT-SORT 这类跟踪器。ByteTrack 的优势是简单，用检测框的 IoU + 卡尔曼预测做关联，适合大多数车辆行人场景；BOT-SORT 还引入 ReID 特征，遮挡后重识别更稳，但计算量更大。如果仓库里没有集成跟踪器，你也可以自己接一个 ByteTrack 的轮子，把 YOLO26 输出的检测框给它即可。

3.4 速度估算原理

速度估算的核心只有三个量：目标在两帧之间的实际位移、两帧之间的时间间隔、目标在画面内是否保持完整可见。

假设目标在 T1 时刻距离摄像头为 D1，在 T2 时刻距离为 D2，时间间隔为 Δt，它的纵向速度约等于：

V ≈ (D1 - D2) / Δt

正负号可以定义目标在靠近还是远离。横向速度则可以通过像素横向位移联合深度换算得到。更工程化的做法是设置参考线：在路面上选择两处已知间距的地面点，当目标跨越这两个位置时记录时间戳，用“距离差 / 时间差”得到速度。这种参考线法不依赖目标属于哪种类别，也不怕检测框宽度抖动，更适合固定监控视角的园区或车道。

但要注意，纯单目测速的最大误差来源不是数学公式，而是距离估计的抖动。YOLO26 的检测框在连续帧里会上下左右轻微抖动，框宽变化 2 个像素，几十米外车辆的测距结果就可能波动 5%～10%。因此工程上通常会用卡尔曼滤波、滑窗平均或中值滤波平滑距离序列，然后再算速度。观察速度时建议看“连续 10 帧的速度均值”，不要盯某一帧的瞬时速度。

4. 环境准备与硬件要求

4.1 硬件与系统

先给出一个稳妥的起点：NVIDIA GPU，显存 8GB 及以上。这个要求能满足 YOLO26s/m 在 640～1280 分辨率下的推理和跟踪。如果只能用 CPU，不建议跑实时视频，处理一段离线视频验证流程可以，但 FPS 会很低。显存不足时优先换 YOLO26n 或降低推理分辨率。

操作系统方面，Windows、Linux 都可以。Linux 下用 Docker 或者 conda 都方便；Windows 下注意两点：一是 conda 里安装 PyTorch 时选择正确的 CUDA 版本，二是源码里如果有 C++ 扩展编译，需要提前装好 Visual Studio Build Tools。

4.2 Python 环境与依赖

创建独立 Python 环境，避免和已有项目打架。这里给的是通用模板，Python 版本和依赖名请按照仓库 requirements.txt 调整。

conda create -n yolo26 python=3.10 -y conda activate yolo26 # 安装 PyTorch，具体 CUDA 版本去 PyTorch 官网选择 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # 安装 YOLO 依赖，如果是 ultralytics 风格可直接装 pip install ultralytics # 安装项目依赖 cd yolo26-monocular-demo pip install -r requirements.txt

安装完成后验证 GPU 是否可用：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

输出True并显示显卡名称就能进入下一步。如果这里返回False，大概率是 PyTorch 的 CUDA 版本和显卡驱动不匹配，先检查驱动支持的最高 CUDA 版本，再重装对应的 PyTorch。

4.3 摄像机和标定参数准备

单目测距的精度一大半由标定决定。常见的标定参数包括：

相机内参：焦距 fx、fy，主点 cx、cy，以及畸变系数。
相机安装高度：相机光心到地面的垂直距离，单位米。
俯仰角：相机光轴与水平面的夹角。

如果没有标定板，也可以用“现场测量 + 推凑”的方式先跑通流程：拿到相机焦距的像素单位，可以用已知宽度目标在不同距离拍摄，反推 f。但最终要获得可靠距离，还是建议用棋盘格做一次内参标定，再用一个已知高度的米尺标出地面消失线，估算俯仰角。项目配置里通常会留出这些字段，请打开配置文件确认需要哪些。

5. 模型获取与 Demo 启动

5.1 获取 YOLO26 权重

YOLO26 权重文件从官方仓库或项目作者提供的下载链接获取。如果你下载的是 ultralytics 生态导出的.pt文件，一般可以通过YOLO("yolo26s.pt")方式加载。但如果 YOLO26 是基于自定义代码训练的结构，那么权重后缀可能是.pth并带有配套的 yaml 模型定义文件。

首次拉仓库后建议先看模型目录里有几个文件：

weights/ ├── yolo26n.pt ├── yolo26s.pt └── README.md

根据任务需求选择：需要更高精度选 m 或 l，需要更快速度选 n 或 s。测距和测速任务本身并不需要最高精度，反而更看重检测框稳定性。一般来说，在 640 分辨率下用 s 型号把管线跑通，比上来就堆 xl 要省心得多。

5.2 项目配置与启动

Demo 类项目通常会提供一份 YAML 或 JSON 配置文件，内容大概长这样。以下字段为示范，请按仓库实际字段重命名：

model: weights: weights/yolo26s.pt conf_thres: 0.35 iou_thres: 0.5 img_size: 1280 camera: focal_length_px: 1200 mounted_height_m: 1.5 pitch_deg: 0.0 principal_x: 640 principal_y: 360 input: source: inputs/sample.mp4 video_loop: false tracker: method: bytetrack track_buffer: 30 match_thresh: 0.8 output: save_video: true save_csv: true video_path: outputs/result_video.mp4 csv_path: outputs/tracks.csv

启动命令通常是：

python main.py --config configs/demo.yaml

如果项目是模块化脚本，也可能分成detect_track.py、estimate_distance.py等，不要一次性背全套，以 README 给出的入口为准。第一次启动建议先用短视频或单张图片做输入，确保流程完整再上摄像头 RTSP 流。

5.3 首次运行验证

Demo 启动成功后，你至少应该看到三样东西：

画面中每个目标有检测框和类别标签。
每个目标有持续稳定的 ID 数字，不会在下一帧随机变化。
输出区域显示距离或速度，例如car 2 | dist: 24.3 m | speed: 36.5 km/h。

同时终端或输出目录中会生成日志、视频或 CSV。打开 CSV，能看到每个目标的帧号、ID、像素坐标、距离、速度。如果只看到检测框但没有距离和速度，优先检查相机标定参数是否写入，以及代码路径是否真的把测距模块接到了跟踪结果上。这种“检测能跑、测距不输出”的问题，通常不是因为模型坏了，而是配置里缺少焦距、高度这类参数。

6. 功能测试与精度验证

跑通 Demo 只说明链路完整，精度到底行不行，需要设计一套能复现的测试流程。

6.1 测距精度测试

测试目的：确认 YOLO26 输出的距离值与真实距离的误差范围。

测试方法：

在场地内固定一个已知尺寸的目标，最好是一辆真实车辆，或用接近车辆尺寸的刚性物体。
分别把目标放在距离摄像头 5 米、10 米、20 米、30 米的位置，用激光测距仪或卷尺记录真实距离。
对每个位置跑一段视频，记录输出的稳定距离。
计算每个点的平均绝对误差和相对误差。

判断标准：5 米内误差小于 0.5 米、10 米处误差小于 1 米、20 米处误差小于 3 米属于比较理想的结果；如果误差远大于此，先检查标定参数是否准确，再看检测框是否把背景也算进目标宽度。注意，不要在普通城市道路做这类测试，除非你拥有该路段的使用权，并且没有把参与者隐私数据外传。

6.2 多目标跟踪 ID 稳定性测试

测速准确的前提是 ID 稳定，所以单独测跟踪也很有必要。

构造三种场景：

两个目标相向而行，在画面中交叉。
目标被电线杆、树木短暂遮挡。
目标在远处来回走动或徘徊。

分别观察视频输出中的 ID 是否发生跳变。如果两个目标本来一个 ID 是 1、一个是 2，交叉后 1 和 2 互换了，说明跟踪模块在 IoU 关联上出现错误。短时间遮挡后 ID 重新编号是正常现象，但频繁出现就不适合拿来做测速。可以尝试调整track_buffer和match_thresh，或者换 BOT-SORT 这类带重识别特征的跟踪器。

6.3 速度估算测试

测试速度时不要直接用车辆仪表盘作为标准，因为仪表盘本身有偏差。更好的标准是：

让遥控小车以固定 PWM 速度直线行驶，再用两个已知间距的标记点计算平均速度作为参考。
骑自行车通过一段已知长度路段，用秒表计算平均速度，与输出速度做对比。
在封闭园区里驾车，用支持 GPS 测速的手机 App 记录参考速度。

测试时重点记录目标从进入画面到离开画面的速度曲线。理想情况下，速度曲线应当比较平滑，不会出现 5 km/h 到 40 km/h 的跳变。出现大幅跳变的常见原因有：跟踪 ID 丢帧导致位移计算错位、距离估计算法在多帧之间抖动太大、目标处于斜向运动方向。

6.4 输出数据确认

最终输出的 CSV 应该包含类似字段：

frame_id, track_id, class_name, bbox_left, bbox_top, bbox_width, bbox_height, distance_m, velocity_kmh, timestamp_ms

用字段可以完成哪些下游任务？统计某个 ID 的平均速度、画轨迹、判断目标是否进入某个深度范围，这些都可以在 Excel 或 Pandas 里做。验证输出数据时，随机挑 200 帧和原始视频逐帧对比，确认框和 ID 与画面内容一致。批量处理完的视频不要直接信结果，抽查是必要的。

7. 批量任务与 API 接口思路

很多实际需求不是跑一条视频，而是对一个文件夹里的上百段视频或图片做离线处理，或者要把这条感知管线封装成本地服务。这两个需求可以这样扩展。

7.1 批量目录处理

如果项目入口本身是文件输入，循环调用即可。给一个通用批处理思路：

# 将 input_videos 目录下的所有 mp4 批量处理 python batch_process.py \ --input_dir ./input_videos \ --output_dir ./output_videos \ --config configs/batch.yaml

批量处理建议遵循几条原则：

输出目录按输入视频名隔离，每个视频生成一个子目录。
CSV 文件名加上视频名前缀，避免覆盖。
处理前先扫描输入目录，记录文件数量、分辨率和时长。
处理失败时单独记录失败日志，不要中断整个队列。
如果任务量大，先跑 1～2 个视频验证输出，再全量提交。

7.2 基于 FastAPI 的 HTTP 接口封装

项目如果没提供 HTTP API，可以自己封装一层。下面只是一个通用模板，实际路由、请求字段、返回字段必须对照项目源码调整，不要直接复制跑生产环境。

# api_app.py（示例） from fastapi import FastAPI, File, UploadFile import cv2 import numpy as np from pipeline import YOLO26Pipeline app = FastAPI() pipe = YOLO26Pipeline() @app.post("/api/detect") async def detect(image: UploadFile = File(...)): data = await image.read() img = cv2.imdecode(np.frombuffer(data, np.uint8), cv2.IMREAD_COLOR) # 假设 pipe.process_frame 返回检测、跟踪、距离、速度等字段 result = pipe.process_frame(img) return {"success": True, "objects": result} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="127.0.0.1", port=8000)

启动：

uvicorn api_app:app --host 127.0.0.1 --port 8000

7.3 调用与返回示例

调用接口可以用 curl：

curl -X POST http://127.0.0.1:8000/api/detect \ -F "image=@test.jpg"

Python 请求示例：

import requests url = "http://127.0.0.1:8000/api/detect" files = {"image": open("test.jpg", "rb")} response = requests.post(url, files=files, timeout=10) print(response.json())

接口封装后，可以接到自己的 Web 工具、消息队列或自动化脚本里。需要注意的是如果要跑实时视频流，不应逐帧 POST 图片到 HTTP 接口，而是在服务端内部直接解码 RTSP 流并处理，这样能省掉大量图片编解码开销。

8. 资源占用、性能观察与问题排查

8.1 显存占用和 FPS 怎么观察

运行 Demo 时，另开一个终端持续观察显存：

nvidia-smi -l 2

或使用更细粒度的监控：

watch -n 1 nvidia-smi

同时看终端日志里的单帧处理时间。对于视频输入，如果单帧推理时间约 20ms 到 40ms，加上跟踪和后处理之后整体还能保持 15 FPS 以上，体验就会相对流畅。如果是 CPU 推理，单帧时间可能飙到几百毫秒，只适合离线验证。

影响性能的主要因素有这几个：

检测分辨率：640 vs 1280，计算量差距不是 2 倍而是 4 倍。
是否开启半精度：fp16 能明显降低显存和提升推理速度。
跟踪器的复杂度：ByteTrack 开销小，BOT-SORT 带 ReID 开销更大。
输入视频帧率：30 FPS 视频如果机器只能跑 15 FPS，结果是处理速度跟不上播放速度，输出的时间戳依然来自原视频，不会被拉长。但你要理解这是“非实时离线处理”。
是否所有目标都做测距：如果对检测到的行人也要测距，底部地面点法比宽高相似三角形法更容易受到检测框抖动影响。

显存不足时按顺序尝试：打开半精度、把检测分辨率降到 640、换最小的 n 型号、关闭视频画质增强选项、限制同时跟踪的目标数量。

8.2 常见问题排查

问题现象	可能原因	排查方式	解决方案
依赖安装失败	Python 版本不匹配或 CUDA 源不可用	查看 pip 报错日志	换 conda 环境或切换 PyTorch 源
权重加载失败	权重文件路径写错或模型结构不匹配	检查 weights 目录和代码里的模型名	确认权重与 YOLO26 版本一一对应
检测框完全没有	置信度阈值过高、图片为空、模型初始化失败	降低 conf 到 0.1 测试单张图片	逐步调阈值并确认模型输出
图像中有人但测距不出数字	摄像机焦距、高度、俯仰角未配置	打印中间变量，查看测距模块输入	在配置中补齐标定参数
距离值大幅偏大或偏小	目标类别先验尺寸错误、参数单位错误	用已知距离对照测试	校正类别宽高先验和单位
速度忽快忽慢	检测框抖动、跟踪 ID 丢失、没有滤波	查看距离序列和 ID 切换日志	加卡尔曼平滑、提高跟踪缓冲帧数
RTSP 视频拉流失败	网络不通、地址格式错误、解码库缺依赖	用 VLC 先验证 RTSP 地址	检查网络并安装 ffmpeg
CPU 推理速度太慢	未启用 GPU 或模型过大	nvidia-smi 确认 GPU 状态	安装 GPU 版 PyTorch 并切换模型到 s/n
夜间 / 低光环境检测漏检严重	输入图像过暗，YOLO26 训练数据以白天为主	统计夜间帧亮度	使用低光增强预处理或重训低光数据集
批量处理中途崩溃	某段视频损坏、显存波动	记录失败文件名	单文件重试 + 降低批次大小

针对 YOLO26 低光环境检测，补充一点：如果项目要处理隧道、夜间园区这类场景，建议对输入视频先做自适应直方图均衡或低光增强，再用检测器。更长期的手段是拿低光数据微调模型。不要指望同一个白天模型在所有光照条件下都能稳定输出；单目测距测速在夜间更容易出现距离抖动，因为检测框边界不稳定，几何法输入误差会跟着放大。

9. 落地建议与后续改进方向

9.1 工程化建议

把 Demo 往真正能用的方向推进，需要注意这些工程细节。

第一，先把最小可运行配置固化下来。跑通过一套“YOLO26s + 640 分辨率 + ByteTrack”的配置后，把权重、配置文件、测试视频保存到一个固定目录，后续修改参数时可以从这套基线回退。

第二，目录划分清楚。输入视频、输出视频、轨迹 CSV、日志分开存放，批量任务处理结果不要和源代码混在一起。

第三，批量任务一定是先小规模验证，再全量执行。先跑一段 30 秒的测试视频，确认输出文件能打开、CSV 字段正常，再提交 100 段视频。全量跑之前用脚本统计所有文件的时长、编码格式，提前排除损坏文件。

第四，接口服务要做好访问限制。如果起了 HTTP 服务，默认绑定 127.0.0.1，不要直接暴露到公网。如果需要局域网访问，最好放在受控内网并加认证。摄像头视频流里往往含有人员、车辆信息，这类数据一旦被外部非法访问，会带来隐私安全问题。

第五，涉及单目测速结果的展示要谨慎。UI 或者演示视频里可以标注“实验 Demo，非计量设备”，避免给甲方或观众造成“这就是执法级测速”的误解。

第六，设置完善的日志。每一帧的目标 ID、距离、速度、时间戳都记下来，运行出错时能定位到是哪一帧、哪个 ID 出现问题。上线前把录制的轨迹抽取成热力图或散点图，人工抽查正确率。

9.2 后续改进方向

开源 Demo 跑通后，按下面这些方向往下走，工程价值会明显提升。

多目标跟踪换成带 ReID 的方案。遮挡频繁的场景下，BOT-SORT 或 DeepSORT 的效果通常优于纯 IoU 匹配，代价是计算量增加。
引入深度先验网络。YOLO26 检测之外，再接 Depth Anything 或 MiDaS，用深度图约束距离估计，远距离和斜向运动目标的误差会小一些。
时间维度融合。把连续帧的检测结果做成小段轨迹，用滑窗回归距离变化曲线，速度会比逐帧差分更平滑。
加入目标分类和路况上下文。比如只对车道上同向行驶的车辆做速度统计，排除错位目标和静止物体。
低光优化。如果目标是 24 小时工作，建议设计低光数据采集流程，并对检测器做针对性微调；简单应用可以在输入侧串一个增强模块。
轻量化部署。把 YOLO26 导出为 TensorRT / ONNX，在嵌入式设备或边缘盒子跑，很多园区边缘感知设备实际上就是这么落地的。
与业务系统联动。距离低于某个阈值时触发报警，速度超过阈值时记录事件，这些逻辑可以全部建立在 CSV 轨迹数据之上。

要继续深挖技术细节，可以先拿 YOLO26 模型结构图和 depth 分支做对照，再看跟踪器源码，最后补相机标定。三个环节里，标定最容易让人头疼但作用也最大，如果你觉得测距结果不够准，不要先怀疑模型，先检查相机内外参数。

写在最后

这个 Demo 最值得动手尝试的点，不是某一个算法有多惊艳，而是它把“检测→跟踪→测距→测速”这四个环节完整跑通，让新手能在一套代码里看到感知系统的全局链路。建议你下载源码后先做三件事：跑通默认配置、用单张图片验证检测、用短视频验证 ID 稳定性。最该避开或提前准备的坑，是相机标定参数缺失和跟踪 ID 跳变，它们对你最终结果的影响，往往比 YOLO26 模型自身精度的影响还大。

YOLO26单目测距测速开源Demo：检测跟踪到距离估算完整管线