双目测距这几年在自动驾驶、安防监控和机器人避障里用得越来越多尤其是和YOLOv8这类检测模型结合以后可以直接给检测框绑定距离信息省掉了过去“先检测、再单独测距”的割裂流程。我做的这个模拟项目X就是一套基于YOLOv8的双目测距实现检测模型覆盖包括车辆、行人、交通灯在内的COCO 80类目标距离计算走OpenCV的传统立体视觉路线整条流程从相机标定、立体校正、视差计算到目标级的距离解算全部跑通。这篇文章就按我实际调试的顺序把核心原理、参数选择、代码实现和踩过的坑完整记录下来给有同样需求的人参考。1. 方案选型与整体设计思路拆解先说结论在“给检测目标输出距离”这件事上方案并不是唯一的。我在项目立项时对比过三套路线分别是单目测距、深度相机测距和双目视差测距最后选择双目YOLOv8组合主要是基于以下考虑。1.1 选型对比为什么不是单目或深度相机单目测距很多资料里会说“靠目标大小估算距离”实际工程里就是在假设目标真实尺寸已知的前提下用检测框的高度映射距离。这套做法的问题很明确目标的真实尺寸无法保证行人有高有矮、车辆有轿车有货车一换车型或姿态误差直接失控。而且单目方案没有几何约束本质上是在做“猜测”不具备可推广性。我在别的项目里试过用车辆宽度的先验知识做单目测距10米以内勉强能用20米以上基本没法看所以这个项目从起步就放弃了单目。深度相机比如结构光或ToF方案精度确实好但它有两个硬伤。第一是室外强光环境下红外结构光会受干扰性能衰减非常明显第二是有效量程有限很多消费级深度相机的有效范围也就5米左右对道路场景动辄几十米的测距需求根本不够用。双目视觉虽然受光照影响但不受主动光源限制只要纹理信息够量程靠基线可以设计成本也低所以它是工程落地中最“皮实”的路线。1.2 为什么检测模型选YOLOv8检测这件事上YOLO系列依然是工程落地效率最高的选择。选YOLOv8而不是更早的v5或v7有几个实际原因。首先是部署生态v8官方的ultralytics仓库把训练、验证、导出打包得足够顺滑导出ONNX或TensorRT引擎都有现成脚本。其次是后处理更简单v8的head在推理时直接输出中心点x、中心点y、宽、高、各类别置信度的解耦格式不用像v5那样解析多层输出再做nms代码写起来清爽很多。再就是v8默认支持80类COCO和项目需求里的车辆、行人、交通灯直接吻合不用额外挑数据集。当然COCO 80类里并不是所有类都适合做距离测量后续会讲怎么按业务过滤类别。1.3 整体系统架构与数据流转整个系统的数据流分两条线最终在距离解算模块汇合。第一条线是双目相机左右目各拿一帧图像经过畸变校正和立体校正后把两帧图像变换成“极线对齐”的状态再交给立体匹配算法算稠密视差图。第二条线是只用左相机图像也可以选右目只要标定关系对应好跑YOLOv8检测拿到目标框的像素坐标。最后一步把检测框中心点或框内小区域映射到视差图上提取对应位置的视差值代入三角测距公式算出距离。这个架构的好处是检测和测距解耦两边可以独立优化。比如检测换模型、视差换算法都不会牵一发动全身。代价是需要多维护一套标定参数这个后面细讲。2. 双目视觉核心原理与硬件准备双目测距的数学基础一点都不玄乎就是初中几何里的三角形相似。真正让工程变复杂的是怎么在像素级别精确找到“同一个空间点在左右两幅图里的投影位置”这个对应关系才是视差计算的本质。2.1 视差与三角测距原理先建立一个理想模型两个相机水平放置光轴平行焦距相同成像平面共面。空间中某个点P它在左图像里的像素横坐标是xl在右图像里是xr那么视差定义为d xl - xr根据相似三角形关系深度Z f * B / d其中f是焦距像素单位B是左右相机光心之间的距离基线长度d是视差像素单位。从这里可以直接看出几个关键规律距离和视差成反比也就是说目标越远视差越小距离分辨率越差距离的误差和距离的平方成正比这个后面精度分析再展开。像素单位的焦距可以通过标定得到公式是fx_pixel FX_mm / sensor_width_mm * image_width不过实际工程里不需要自己算OpenCV标定会直接给出fx和fy的像素值。2.2 基线长度的设计与量程规划基线B是整个硬件设计里最需要权衡的参数。视差d的提取精度有限亚像素级一般也就0.1像素左右在相同视差精度下基线越长相同距离处的视差值越大测距精度越高。但基线长了也有代价相机视野重叠区域变小近距离目标的公共视野受限立体匹配的搜索范围变大计算量上升整个设备的体积也变大。我这个项目选择的基线是12cm基于这样的量程规划道路场景主要关注3米到50米范围的车辆和行人。50米处一个行人投影大概还有几个像素此时视差大约在1~3个像素量级已经是亚像素估计的极限了。如果项目更偏近距离室内机器人比如避障距离2米为主我会建议基线缩到6~8cm这样近距离匹配的搜索代价更小。反过来如果要做100米以上的远距离测距12cm基线也不够用需要上到30cm甚至更长的基线。2.3 相机选型与同步要求双目测距对相机有两个硬性要求。第一是畸变不能太大鱼眼镜头这种强畸变的头虽然视场大但标定和校正的难度会上一个台阶普通道路场景建议选常规的6mm或8mm镜头视场角大约50到70度畸变相对好标定。第二是左右目成像参数必须一致包括分辨率、焦距、传感器型号所以买双目模组时尽量选同一批次、同一型号的两个相机。还有一点很容易踩坑就是帧同步。如果两个相机各采各的哪怕帧率都是30fps由于曝光起始时刻不同高速运动的车辆在两幅图里的位置可能差出好几个像素视差就会严重错误。我当时用的方案是支持硬件外触发同步的双目模组把左右目曝光信号用外部电路拉齐。如果手头只有普通USB相机至少要跑一个软件同步逻辑每帧同时读取、校验时间戳差值差值大于一个阈值就直接丢帧宁可降低有效帧率也不要用错位分图像算视差。2.4 环境部署要点实际走线时还有几个细节容易被忽略。两个相机要固定在刚性结构的同一块金属板或碳纤维板上固定好后整个标定和使用期间不能再有丝毫位移毫米级的相对位移都会让标定参数失效。我见过有人用热熔胶粘两个USB摄像头凑合开机半小时后板子发热基线变了后续数据全部作废。如果使用环境温度变化大最好定期重标定温度引起的结构热胀冷缩对双目系统的影响是真实存在的。3. 相机标定与立体校正实操拿到硬件后的第一件事不是跑YOLO而是把相机内参、畸变系数、左右目相对位姿都标定出来。这一步做不好后面整个流程全部白搭。OpenCV的标定流程虽然是一套固定代码但实操细节非常多我列一下我项目里最终定下来的流程和参数。3.1 标定板选择与图像采集标定板我用的是10x7内角点的棋盘格单个方格边长30mm打印后贴在绝对平整的铝板上。这里有个容易犯的错直接用普通打印纸贴墙纸张不平整会导致角点坐标在毫米级别上抖动标定出来的焦距会有千分之几的误差对于50米测距来说足以产生半米的偏差。采集图像时最少要20张以上每张都要保证棋盘格能够完整出现在视野内同时姿态要覆盖各种角度左右倾斜、上下俯仰、远近变化、四个角落都放。容易忽略的是棋盘格旋转角度要足够丰富如果所有图里棋盘格都正对相机内参解算时会出现退化情况重投影误差看着还行实际换场景就露馅。采集时左右目必须同时拍摄同一位姿也就是说棋盘格位置不变两个相机各自拍一张这样后续标定才有对应关系。3.2 单目标定与双目标定参数解析先用cv2.calibrateCamera分别标定左右目拿到各自的相机内参矩阵和畸变系数。内参矩阵是K [fx 0 cx 0 fy cy 0 0 1]畸变系数是5参数组合dist [k1, k2, p1, p2, k3]k1、k2、k3是径向畸变p1、p2是切向畸变。标定完成后必须看重投影误差我给自己定的标准是误差小于0.15像素超过0.2像素就说明标定图像质量不合格需要重拍。单目标定之后是立体标定这一步拿到的是右相机相对左相机的旋转矩阵R和平移向量T。T的模长就是基线长度可以用它验证一下实际测量值是否和机械设计一致我标出来的T模长是119.8mm和设计的120mm很接近这就说明标定基本可信。3.3 立体校正从“不平”到“极线对齐”立体校正的目的是把两个相机的图像通过重投影变换变成理想平行双目模型下的图像也就是左右图的对应点在同一个水平扫描线上。OpenCV里这个过程由stereoRectify和initUndistortRectifyMap完成。stereoRectify的关键参数是alpha它控制校正后图像的裁剪保留程度。alpha取0时校正后的图像只保留有效像素区域输出图像最小但会损失部分边缘alpha取1时保留全部像素边缘会有黑色填充区域但保留的视野最大。我的做法是alpha取0.5到0.6之间兼顾视野和有效匹配区域。如果alpha取0左右图的公共视野反而变小对匹配不利。3.4 校正效果验证方法校正完怎么验证效果两个办法。第一个是画水平线检查在左图取几个特征明显的点记录它们的y坐标然后在右图同名点的y坐标应该和左图完全一致误差不超过1个像素我在实测中普遍能控制在0.5像素以内。第二个更直观把左右校正图转成红青叠加图你会看到同一物体在两张图里完美重叠只有水平方向的偏移这个偏移量就是视差。这个环节还有个实用的自检技巧用标定棋盘格放在场景里检测棋盘格角点后左右对应的角点y坐标差值的均值应该非常小。我把这个差值作为每次开机自检的一个指标超过阈值就提示标定参数可能失效了。4. YOLOv8检测模块的集成与调优检测部分看起来是最“现成”的但真正要把YOLOv8和双目测距流程融合好还是有不少工程细节要处理。4.1 模型选择与导出YOLOv8官方提供五个规模的模型n、s、m、l、x。对于实时双目系统检测不是唯一算力消耗点立体匹配同样吃资源所以我最终选了yolov8s在精度和速度上取平衡。如果是嵌入式平台建议yolov8n配合TensorRT部署如果算力充足且对检测精度要求苛刻可以考虑yolov8l但推理延迟会明显上涨。ultralytics训练完的模型是PyTorch格式做工程部署时我建议导出成ONNXyolo export modelyolov8s.pt formatonnx dynamicFalse imgsz640导出时imgsz要和推理时保持一致我用的是640x640。如果设成dynamic动态尺寸虽然灵活但会拖慢推理速度具体项目中固定尺寸是更好的选择。4.2 类别过滤与置信度阈值COCO 80类里有相当一部分类别在这个场景里用不上比如猫、狗、薯条这些。如果不对类别做过滤检测器会把远距离误检也送到距离解算模块一来浪费算力二来输出一堆没意义的距离信息。我在后处理里维护了一个业务类别白名单车辆类car、truck、bus、motorcycle、bicycle行人相关person交通设施traffic light、stop sign运行时要过滤掉白名单之外的类别。置信度阈值方面我的经验是检测阈值不能设太低0.45左右比较合理。双目测距不是纯检测场景距离解算对目标框的稳定性很敏感一个抖动严重的框会导致框中心点来回跳距离值也会跳得很厉害宁可漏检也不要一堆假框进来扰乱距离输出。4.3 推理引擎选择与延迟控制在用ONNX Runtime做CPU推理时yolov8s单帧640输入大约要35到45毫秒这还没算立体匹配的时间整体延迟是压不住的。我项目里最终换成了TensorRT在GPU上单帧推理降到6到8毫秒余量就非常充裕了。TensorRT的导出流程相对繁琐但YOLOv8有现成的trtexec转换命令关键是固定输入shape和batch size动态shape会平白增加很多引擎构建时间和显存占用。提示如果你也是用OpenCV DNN模块加载ONNX注意OpenCV的DNN后端对YOLOv8的某些算子和新版本支持的差异我建议在固定设备上先跑一遍完整链路验证各算子兼容性再决定是否继续用OpenCV DNN路线。4.4 检测框与视差图的分工协作检测和立体匹配是并行处理的两条线。我的实现里用两个线程分别跑检测和视差计算检测线程输出目标框立体匹配线程输出视差图最后在主线程做距离解算。这里必须做好帧同步目标框来自第N帧左图视差图也必须来自第N帧左右图如果出现半帧错位近处目标可能差出几十厘米的误差。我在代码里给检测结果和视差图都打了帧号标签合并时匹配帧号不匹配就丢帧重来。5. 距离解算与精度优化实战距离解算是整个链条的最后一环也是最考验细节的一环。检测框和视差图都有了怎么把两者精确对起来决定最终输出的距离值稳不稳。5.1 从目标框到视差的提取策略最直觉的做法是取目标框中心点把这个点的坐标映射到视差图上读一个视差值套公式算距离。但这在实际场景里经常翻车检测框的中心点经常落在目标的中空区域、车窗玻璃、背景天空上这些位置的视差值要么无效要么跳变算出来的距离根本不能用。我实测下来比较稳的策略是“中心区域视差统计法”。具体做法是取检测框中心附近、占框面积约15%的矩形区域比如框宽高的40%乘40%在这个区域内收集所有有效视差值剔除异常值后取中值或均值。之所以用统计量而不用单点是因为视差图本身有噪声单像素跳变太厉害而统计量能滤掉大部分噪点。选中心区域而不是整个框是因为目标边缘经常混入背景视差拉低统计精度。5.2 视差有效性判定SGBM算出来的视差图里有invalid值一般是-1或极小值这些在提取时直接过滤掉。但即便不是invalid某些区域的视差值也可能明显错误比如低纹理区域和遮挡边界。我在提取区域视差前加了几道过滤剔除视差为负值或为零的像素剔除视差超过合理量程范围的像素结合基线标定结果反算如果有效像素占比低于区域内总像素数的30%则认为该区域视差不可信距离输出标记为无效这第三点很重要。遇到反光表面、白色卡车车身这类低纹理区域SGBM根本匹配不出有效视差如果硬算一个平均值出来会得到一个完全离谱的中间值。宁可输出无效也不要输出错误距离这是工程里必须守住的底线。5.3 距离换算公式与坐标系说明有效视差拿到后距离换算公式是Z fx * B / d注意这里的fx要用左相机内参标定出来的fx像素值B是立体标定得到的基线长度单位毫米d是有效视差。算出来的Z是目标相对于左相机光心坐标系沿光轴方向的距离。这里我特别说明一下很多教程把公式写成Z f * B / d没有区分fx和fy在理想模型中fx和fy相等但实际标定出来两者可能有几个像素的偏差必须用fx。5.4 精度实测数据分析我做了静态场景的精度测试把目标放在已知距离处对比测量结果得到这样一组数据真实距离(米)视差均值(像素)测量距离(米)绝对误差(米)3132.43.020.02579.25.030.031039.610.150.152019.820.460.463013.231.051.05507.953.203.20可以看到一个清晰的规律距离越远误差增长越快30米之后误差迅速扩大。这个趋势和理论推导完全一致因为Z对d求导后误差正比于Z的平方delta_Z ≈ Z^2 / (f * B) * delta_d以fx700像素、B120mm、视差误差0.5像素来算20米处误差大约0.36米30米处大约0.81米和实测数据基本吻合。这意味着在基线固定为12cm的前提下要提升远距离精度只能靠提高视差精度而视差精度受限于匹配算法和图像分辨率。5.5 影响测距精度的几个硬件因素我在调试中体会到影响精度的几个因素按权重排序是视差精度、基线长度、图像分辨率和标定精度。视差精度是最核心的它取决于图像纹理质量、立体匹配算法参数、以及左右目图像的帧同步质量。基线长度是硬件设计时就必须定的后期改不了。图像分辨率影响的是远距离目标的可视化细节分辨率越高远距离目标占的像素越多视差估计相对越稳。标定精度影响的是系统性的偏差这个误差在近距离会表现为固定偏移远距离则被放大。6. 常见问题排查与精度优化实录最后这部分把我调试期间遇到的高频问题列出来这些问题在教程和文档里基本不会细讲但实际工程项目中几乎一定会遇到。6.1 视差图大面积空洞怎么处理SGBM在低纹理区域、反光区域、遮挡区域会产生大量无效视差。我最开始跑通流程时白色卡车车身的视差图几乎全是洞导致距离输出频繁无效。解决思路是分级处理第一级调整SGBM参数。把blockSize从5调到9、numDisparities从64调到128空洞明显减少。但参数不是越大越好blockSize增大虽然能填充低纹理区域但会抹平细节导致目标边缘的视差精度下降。第二级在提取区域视差时用“扩大候选区域统计校验”的办法如果中心区域有效视差不足就逐步扩大候选区域直到有效像素占比达标。第三级如果时间预算允许可以对无效视差做后处理插值但插值要谨慎靠近遮挡边缘的地方插值出来的值可信度很低。注意优先靠调算法参数和候选区域策略解决插值永远是最后手段。硬件上保证相机曝光充足也能显著提升视差图质量光线暗的时候匹配成功率急剧下降。6.2 检测框抖动导致距离跳动这是视觉测距里最常见的现象。帧率30fps下YOLOv8输出的检测框中心点会有1到3个像素的随机抖动换算到视差上就是几个像素的误差最终表现为距离输出在小数点后也在跳。我的解法是给距离输出加一个时间维度的平滑滤波用滑动窗口均值或一阶低通滤波。滑动窗口我取5帧窗口太小效果不明显太大则会让距离响应变迟钝不适合应对突然出现的障碍物。一阶低通滤波的系数alpha取0.3左右平滑度高但保留一定的动态响应。更进阶的做法是用卡尔曼滤波对目标的3D位置做跟踪效果最好但实现复杂度也高如果项目不需要轨迹跟踪滑动平均完全够用。6.3 帧同步错位问题前面提到过帧同步我在调试中发现即使两个相机都是外部触发模式如果触发信号有微小的抖动加上图像传输耗时不同左右目之间的时间差依然可能累积到1到2个帧周期。这个问题在车辆高速通过时特别明显表现为视差图在车辆边缘出现细长的错误条纹。解决方法是双管齐下。硬件上尽可能缩短两个相机的触发线长度、共用同一个触发信号源。软件上给每帧打上时间戳在立体匹配前检查左右目的时间戳差值超过一个阈值就直接丢帧等待下一组同步帧。不要舍不得丢帧用错位帧算出的距离误差可能达到几十厘米比丢几帧严重得多。6.4 标定参数在长期运行中漂移的问题项目连续运行几天后我注意到近距离测距的固定偏移逐渐变大整体距离偏近了。查下来发现是支架在温度变化下产生了微小的热变形基线长度发生了零点几毫米的偏移。这个问题在户外变化大的场景尤其严重。对策是把标定参数模型升级不只存单一标定结果而是记录设备在不同温度下的标定结果运行时任选匹配温度区间的一组参数。我实测同一台设备在15度和35度下标定的基线相差约0.8mm对10米距离的测距影响大约是0.08米虽然看起来不大但叠加其他误差后会被放大所以需要引起重视。6.5 天气与光照场景的处理建议双目视觉本质上是被动光学方案它的可靠性和光照强相关。我总结了三条应对经验。第一逆光场景下视差图会变差强烈建议开启相机自动曝光并锁定左右目曝光参数一致防止两目进光量不一致导致匹配失败。第二雨天或雾天时图像对比度低立体匹配成功率下降建议在预处理里加对比度增强我用的简单线性拉伸就有效。第三夜间场景是这类被动视觉方案的短板如果项目必须全天时工作要么增加补光灯要么切换其他传感器方案不要指望纯视觉能扛下夜间远距离测距。6.6 参数速查与调参顺序最后给一个我自己调参时遵循的顺序这个顺序能帮你快速定位问题到底出在哪个环节第一优先级确认左右目图像帧同步没有问题第二优先级确认立体校正没有明显垂直偏差画线检查y坐标差值第三优先级用标定板或已知距离目标验证视差图数值是否合理第四优先级单独验证YOLO检测框是否稳定必要时降低置信度阈值或调整输入分辨率第五优先级最后才调距离解算的平滑参数不要一上来就动SGBM参数参数调了半天发现是帧同步的问题那才是真的浪费时间。7. 个人实践心得与后续扩展方向整个项目做下来我最深的一个体会是双目测距的难点从来不在某一个环节而在于把所有环节的误差控制在一个量级上。标定误差、帧同步误差、立体匹配误差、检测框抖动误差任何一个环节放松了最终的距离输出都会变得不可信。我在调试时一度把全部精力放在优化SGBM参数上发现精度提升很有限回头查了帧同步才发现问题的根源在那里——这种排查逻辑比盲目堆参数重要得多。这个方案后续还有几个可以扩展的方向。一是把SGBM换成基于深度学习的立体匹配模型像某些基于Transformer的匹配网络在低纹理区域的鲁棒性会好很多代价是算力需求大适合有GPU加速的环境。二是给检测跟踪模块加多目标追踪这样能稳定输出每个目标的ID和连续距离轨迹离真正的自动驾驶感知链路又近一步。三是做3D检测框的回归现在只输出目标中心的距离如果后续需求是“知道车辆占用的空间位置”需要在YOLO头之后再接一个3D框回归分支但这是另一个复杂度量级的话题了。对一个要落地成产品的方案来说我的建议是先固定硬件平台再逐步调软件参数千万别频繁换相机或换安装位置每一次改动都要重新标定和重新测试这些时间成本在项目里往往比纯算法调优还要高。