去年系统梳理视觉SLAM算法的时候我把DSODirect Sparse Odometry直接法稀疏里程计列入了必跑清单。在特征点法几乎占据教程半壁江山的背景下DSO是少数能让你直观理解“直接法”内部机制的完整开源实现。这篇笔记是系列第八篇主题很聚焦DSO的编译运行。文章会从环境准备开始把依赖库、数据集格式、编译命令、启动参数逐个过一遍最后附上我实际操作中踩过的问题和排查方法。适合正在入门视觉SLAM、已经跑过特征点法、想换个思路看直接法VO的读者哪怕你只用过现成工具照着本文也能把DSO完整跑起来顺便把直接法的运行逻辑也摸个大概。1. 先把DSO的定位搞清楚直接法VO与主流SLAM的差异1.1 直接法到底“直接”在什么地方常见的特征点法SLAM比如ORB-SLAM那一套核心流程是提取角点或关键点、计算描述子、匹配特征、求解位姿、做光束法平差。说白了就是先在地图上找到一堆“地标”然后通过地标的几何关系反推相机运动。DSO完全不同。它不做特征提取不做描述子匹配甚至连“特征”这个概念都淡化到最低限度。它比较的是像素本身的灰度值把一个三维点投影到当前帧和参考帧上假设这两个投影位置对应的是同一个物理点那么它们的亮度应该一致——不一致的部分就是“光度误差”。DSO把所有关键帧之间共享点的光度误差放在一个滑动窗口里做联合优化同时更新相机位姿、点深度和一些光度参数。所以“直接”这个词指的是直接利用图像灰度作为观测值而不用经过特征提取和匹配这道中间工序。这种做法的好处是能利用图像中所有有梯度的信息比如边缘、角点、弱纹理区域特征点法里的“墙角”“桌角”才能用而DSO在纹理不那么丰富但梯度变化明显的场景里往往更稳。代价是它对灰度一致性极其敏感光照变化、曝光突变、镜头暗角、自动白平衡这些都会直接污染误差函数。这也是为什么DSO需要光度标定后面会详细说。1.2 为什么现在还要花时间编译一个“老”项目DSO是2016年前后提出的方法放到现在看代码确实有点“年迈”。直接法的后续主流研究已经转向了与惯性导航融合、与深度学习结合这些方向DSO本身也基本处于维护停滞状态。那为什么还要折腾它第一它是直接法这个分支里最干净的参考实现。相比某些动辄几十万行的大型系统DSO核心代码量级相对可控C11写得很紧凑认真读下来能建立对“滑动窗口优化”“边缘化”“逆深度参数化”这些概念的直观感受。第二项目里的线程模型、内存管理、SSE指令优化都值得看。它不是玩具代码而是一个能在单CPU上实时跑的完整系统。能把这种级别的工程吃透再去看现代VO系统会轻松很多。第三编译本身就是一个很好的“依赖管理实战课”。DSO的依赖里有几个非常挑剔的组件尤其是Sophus的版本坑几乎每个人都踩过。把这些坑填一遍你对整个构建体系的理解会比看十篇教程都深。1.3 编译运行前必须建立的知识框架在动手跑之前我建议你先在脑子里挂几个关键词后面看日志和点云时才不会懵位姿表达DSO内部用李代数Sophus的SE3表达相机位姿区分世界系到相机系、相机系到世界系这两个方向。轨迹输出时通常给的是相机到世界的变换。逆深度三维点不存绝对坐标而是存“在某个关键帧射线方向上的逆深度”。这个参数化方式在优化里很常见初始化为远处点时数值天然接近零数值稳定性好。光度模型帧间的亮度传递不是简单相等而是用指数和仿射参数补偿曝光时间和亮度增益。gamma响应函数和暗角图就是这个模型的一部分。滑动窗口与边缘化DSO只保留最近一批关键帧参与联合优化老帧通过边缘化Schur补把信息“折叠”进先验里而不是直接丢弃。这是它在计算量上能保持恒定的关键。这几个点不需要在运行前完全弄懂但看到日志里的“marginalize”“active keyframes”这些词时至少知道它在干什么。2. 环境准备依赖库与数据集一个都不能少2.1 四件套依赖Eigen、Sophus、OpenCV、PangolinDSO的依赖不算多主要就四个Eigen、Sophus、OpenCV、Pangolin。但每个都有各自的脾气。Eigen3是最省心的纯头文件线性代数库装好开发包就行版本不太挑。Sophus是最大的坑DSO当年写的时候用的是老版非模板Sophus也就是直接定义Sophus::SE3、Sophus::SO3这种类里面还分float和double两套类型。可现在能下载到的Sophus大多是模板化重写后的新版本类名变成了Sophus::SE3d、Sophus::SE3f。DSO源码里写的是老接口拿新版Sophus去编译报错会非常难看。解决办法要么找一个与DSO同时期的老版本Sophus要么直接用社区维护的DSO分支——不少分支已经把对应版本的Sophus塞进了thirdparty目录省掉大半麻烦。我强烈建议走这条路别跟老Sophus死磕。OpenCV也一样。DSO的代码是用OpenCV 2.x/3.x时代的API写的到了OpenCV 4.x一些常量名和头文件被清理掉了典型的就是CV_LOAD_IMAGE_GRAYSCALE直接报未声明。如果你机器上已经装了较新的OpenCV要么换成3.x系列要么给DSO打小补丁把老常量替换成新API。补丁本身不难但要改的位置不止一处。Pangolin负责三维可视化就是那个能看到相机轨迹和稀疏点云的黑窗口。它本身依赖OpenGL、GLEW、X11这些底层库编译Pangolin前先把系统依赖装全否则会在一堆链接错误里浪费很久。Pangolin版本不用太新能编译过就行。提示依赖版本的组合比单个库的版本更重要。我的经验是Eigen用系统包Sophus用一个与DSO同年代的非模板版OpenCV用3.x分支Pangolin用常规版本这套组合在多个Linux发行版上都能顺利通过。如果你想用较新的发行版优先找社区维护的DSO分支人家已经把OpenCV 4和现代编译器的坑填好了。2.2 公开数据集怎么选、目录怎么摆DSO的运行输入是一个数据文件夹一般结构是这样的/path/to/dataset/ ├── images/ │ ├── 00000.png │ ├── 00001.png │ ├── ... └── settings.txt 可选images目录里放的是按序号连续命名的灰度PNG图原版默认按5位补零读取也就是00000.png这种格式。如果你手上的数据集命名是别的样子比如从1开始或者带着前缀后面运行时会直接读不到图这一点要先确认好。数据集怎么选理想情况是找已经被前人整理成DSO标准格式的公开序列这类数据通常自带标定文件。选择标准有三条一是图像尺寸在640×480量级即可太大跑得慢太小测试不出效果二是场景纹理要够室内桌椅、室外的路面和建筑都行纯白墙会难为直接法三是必须有配套的相机内参最好还有真值轨迹否则没法评估精度。如果你只有原始图像序列没有标定文件也不是不能跑但要把相机内参想办法标出来再以calib参数的形式喂给DSO。只用示例参数凑合是跑不出好效果的。2.3 几何标定与光度标定参数的含义DSO需要的标定分两层。第一层是几何标定也就是常规的相机内参焦距fx fy、主点cx cy加上畸变系数。这些参数通过calib字符串传给程序内部决定怎么把三维点投影到像素坐标。第二层是光度标定这是直接法特有的需求。特征点法比较的是描述子向量对亮度变化不敏感所以很多SLAM系统压根不需要光度标定。DSO直接比较像素灰度如果镜头有暗角图像边缘就会比中心暗如果相机的响应函数不是线性的亮度数值就失真如果每帧曝光时间不同整体灰度还会缩放。这些都会让“同一物理点灰度相同”的假设不成立。光度标定包含两个文件一个是gamma响应曲线通常是一个256行的文本记录每个输入灰度对应的真实亮度另一个是vignette暗角图通常是一张单通道PNG每个像素位置存一个补偿系数。运行DSO时把这两个文件路径传进去程序会在光度模型里做校正。实操心得很多公开数据集的创建者已经帮你把gamma和vignette文件准备好了直接用即可。如果自采数据又没做光度标定可以临时用mode1关闭光度模块先跑通流程但这时候的精度和鲁棒性都会打折扣别把这种结果当成DSO的真实水平。3. 完整编译流程从clone到make的每一步3.1 源码获取与分支选择的经验从开源仓库把DSO源码拉下来之后别急着编译先花十分钟把README和CMakeLists.txt扫一遍。README里一般会写明依赖版本和最简单的编译命令CMakeLists里能看到它到底想找哪些库、版本要求是什么。源码分支的选择是决定成败的一步。原版主分支的技术债比较重在较新的编译器和OpenCV 4环境下直接编译大概率会撞上一连串小错误。社区里不少维护分支已经针对现代环境做了适配。我个人的建议很直接别用原版主分支硬刚优先选择别人验证过的维护版省下的时间够你多跑两组实验。拿到源码后先看它的README有没有提到额外的thirdparty目录——如果有说明依赖基本捆好了后面会顺利很多。3.2 CMake配置与编译指令假设依赖都已经装好编译本身其实很常规cd dso mkdir build cd build cmake .. make -j4make -j4里的4可以根据CPU核数调整机器性能好就-j8差一点就-j2避免编译时内存爆掉。cmake ..这一步如果找不到Sophus通常会报Could NOT find Sophus之类的错误。此时需要手动指定Sophus的安装路径常见做法是在cmake命令里加CMAKE_PREFIX_PATH指向Sophus的安装前缀cmake .. -DCMAKE_PREFIX_PATH/path/to/sophus/prefix如果你的Sophus是纯头文件安装方式可能需要把include路径直接传给DSO的构建。不同分支提供的变量名不完全一样以该分支的README为准。编译过程如果有警告多数可以忽略一旦出现error就进入下一节的排查环节。编译成功后可执行文件会生成在bin/dso_dataset。看到这个文件出现说明编译关算是过了。3.3 编译期高频报错与对症处理我把编译期常见的报错整理成一张速查表都是实际踩过的坑按图索骥能省很多时间。典型报错根本原因对症处理fatal error: sophus/se3.hpp: No such file or directorySophus没找到或者装的是新版模板Sophus换成与DSO同年代的老版非模板Sophus或用带thirdparty的分支error: CV_LOAD_IMAGE_GRAYSCALE was not declaredOpenCV 4.x删除了老常量全局替换为cv::IMREAD_GRAYSCALE顺带检查其他被删除的API一堆undefined reference to Sophus::...Sophus版本不匹配接口符号对不上统一老版Sophus清理后重编Pangolin相关链接错误Pangolin缺少X11、GLEW、OpenGL等依赖安装系统开发包后重新编译PangolinEigen报模板实例化错误Eigen与老Sophus的兼容问题锁定Eigen版本或改用社区维护分支编译时提示不支持的SSE指令老CPU缺指令集换支持SSE3/SSE4的机器一般现代x86都满足实操心得编译DSO时我的顺序是先装Eigen和OpenCV把Sophus和Pangolin放最后。因为Sophus和Pangolin出问题的概率最高越晚编译前面的环境越稳定排查范围越小。另外改完依赖后一定要把build目录删掉重新cmake增量编译有时会把旧路径缓存住导致改了等于没改。4. 跑通第一段轨迹命令参数与结果解读4.1 命令行参数逐个拆解编译产物dso_dataset是个命令行程序启动参数很多但常用的就几个。一个典型的启动命令长这样./bin/dso_dataset \ filesize0 \ calibPinhole fx fy cx cy k1 k2 r1 r2 \ gamma/path/to/gamma.txt \ vignette/path/to/vignette.png \ gt/path/to/gt.txt \ mode0 \ preset0 \ quiet1 \ nogui0 \ nolog0 \ start0 \ length1000 \ /path/to/dataset逐个说下filesize图像文件大小限制0表示不限制一般保持0。calib相机内参和畸变系数。部分分支支持在字符串前指定相机模型名比如Pinhole是针孔模型还有RadTan、FOV、Equidistant等具体看分支README。如果你用的是标准针孔径向畸变镜头Pinhole fx fy cx cy k1 k2 r1 r2基本够用。gamma和vignette光度标定文件路径能填就填。没有这两个文件时用mode1临时绕过。mode光度模式。0是完整光度模型1是不用光度标定文件直接基于原始灰度跑。验证流程可以用1做精度实验用0。preset速度与精度取舍的预设档位取值0到3。0最保守、精度最好也最慢3最快但更容易退化。新手先用0。quiet1减少控制台刷屏0输出更多调试信息。第一次运行建议用0方便观察状态。nogui1关闭可视化窗口适合纯服务器环境。看效果时设0。nolog1不写日志文件0写出result.txt等结果。评估精度时需要日志设0。start和length跳过前N帧以及最多处理多少帧。数据集开头往往有相机静止的废帧start100这类设置很实用。最后一个路径参数是数据文件夹。注意命令行参数是“键值”的写法中间不留空格长命令换行用反斜杠。我第一次运行时手滑在等号两边加了空格程序直接把参数当成了无效项还以为是代码问题。4.2 实跑记录启动、GUI与日志输出用上面的命令启动后程序会先加载标定文件然后开始逐帧读取图像。如果nogui0会弹出一个Pangolin窗口能看到相机位姿和一个稀疏点云在空间里扩展。初始化阶段是最容易出状况的地方。DSO需要相机有足够的平移和视差才能确定点的深度所以开始时要缓慢地平移加旋转别静止不动也别猛甩。如果初始化一直不成功Pangolin窗口里的点云基本不增长控制台也没有进入正常跟踪的迹象这时候就停下来检查运动方式。正常跟踪后控制台会持续输出每帧的处理信息包括处理耗时、关键帧数量、活动点数量等。这些数字跳动是正常的重点观察是否每隔一段时间产生新的关键帧——如果几百帧都没建关键帧说明系统认为当前帧没有足够的新信息或者跟踪已经退化。日志方面当前工作目录下会出现result.txt里面的每一行是一条轨迹位姿时间戳、位置三轴、四元数四轴。这个文件就是后续评估精度的原始材料。4.3 输出轨迹文件与精度评估拿到result.txt之后怎么判断DSO跑得好不好首先用可视化工具把轨迹画出来和数据集提供的真值轨迹叠在一起看粗看方向一致、形状吻合基本就是成功了。接着做定量评估。定量评估的标准做法是把估计轨迹和真值轨迹做一次Sim(3)对齐——单目SLAM存在尺度不确定性不做尺度对齐就比位置是没有意义的。对齐之后计算两个指标ATE绝对轨迹误差衡量整体漂移RPE相对位姿误差衡量局部精度。这些指标用社区常见的轨迹评测工具就能算输入只是两个轨迹文件。我在几个公开序列上的经验是preset0下DSO的精度相当能打在纹理合适的室内场景里跑出的ATE通常能和特征点法打得有来有回。但一旦换成preset3速度上去了稍难一点的序列就会出现明显漂移。所以参数预设的选择本质上是在速度和精度之间做取舍没有绝对的好坏看你的实际用途。5. 运行期常见问题与调参速查表5.1 启动即崩的典型原因DSO启动阶段直接崩溃十有八九是输入问题而不是算法问题。我遇到过的典型情况有这几类第一路径错。标定文件、数据集目录写成了相对路径程序的工作目录一换就找不到文件直接报错退出。解决方法是所有路径都用绝对路径省心。第二图像命名对不上。images目录里如果缺了某个序号或者命名不是5位补零DSO读取时会出现读不到图的表现。可以先自己写个脚本检查一下图片序号是否连续。第三光度标定文件格式不对。gamma文件内容不是256个数或者vignette图不是单通道运行时就会读取失败。尤其是vignette我从网上下载过被二次压缩成三通道的版本一加载就挂。第四GUI环境的锅。在远程服务器或者容器里跑没有显示环境Pangolin初始化直接段错误。这种情况老老实实加nogui1。5.2 跟踪中断与退化的处理运行中途跟踪丢失是DSO这类直接法最让人头疼的问题。DSO假设相邻帧之间的运动可以用常量速度模型预测初始位姿然后在灰度误差上做非线性优化。如果相机剧烈旋转预测的初始位姿跟真实位姿差太远光度误差函数又高度非凸优化就会掉进局部极小甚至发散。处理办法分两种。数据层面的办法是控制运动节奏平移为主、旋转为辅避免快速甩头。算法层面的办法是调preset和关键帧相关参数降低对每帧精度的苛刻要求。不过任何调参都不能完全救回极端的运动退化保持运动平稳是直接法用户的必修课。另外要特别注意DSO没有回环检测长时间运行的位置误差会持续累积。它不是“越跑越准”的系统而是“越跑越漂”的系统。如果你需要回环修正要考虑叠加其他模块或用支持回环的后续方案。5.3 实用调参建议与场景选择参数调节是个经验活我给出几条经过实测的基准建议室内手持序列preset0mode0如果初始化困难就把start适当调大跳过前几十帧的晃动期。室外驾驶序列相机运动相对平滑可以用preset1或2换取更高速度精度损失在弱纹理路面场景可接受。没有光度标定mode1先跑通但同时把preset调到0让优化器有更多余量消化光度误差。只要能跑但精度不满意优先检查calib字符串里的内参是否准确内参错一个像素直接法都会明显感知到这是它比特征点法更“挑剔”的地方。跑自己的相机建议固定曝光、关闭自动白平衡把图像缩放到合理尺寸再喂给DSO。自采数据想要好结果光度标定这关躲不掉。6. 编译运行之后它还留下什么值得挖6.1 从“能跑”到“能看懂”代码阅读顺序建议跑通只是第一步DSO真正值钱的部分在代码里。以我读过的经验建议按照“主干-模块-细节”的顺序。先读主程序入口搞清楚数据从哪进来、结果从哪出去然后读核心的跟踪与优化模块看一帧图像从进来到更新位姿的完整链路最后再读光度残差和逆深度相关代码搞明白误差是怎么算、怎么累加的。具体到文件建议优先翻这几个管理整个系统状态和关键帧生命周期的核心类、负责帧间粗跟踪的模块、描述一个三维点观测残差的模块、管理候选成熟点的模块。这几个文件串起来就是DSO的主干。读的时候对照论文里的公式你会发现代码里几乎每个变量都能在论文里找到对应物。这个过程比跑通十组实验都长见识。6.2 这套流程还能向哪继续扩展跑通DSO之后常见的扩展方向有几个一是把数据集换成自己的相机拍摄补全标定与数据制作流程二是对比DSO与特征点法在同一序列上的精度和鲁棒性差异形成自己的工程判断三是研究滑动窗口优化的实现细节把边缘化逻辑彻底吃透。我个人实际操作中的体会是DSO编译运行这件事最有价值的产出不是几条轨迹而是建立了一套“直接法调试直觉”。你会开始习惯性地关注图像的梯度分布、曝光一致性、运动速度对跟踪的影响。这些直觉换到任何基于光度误差的算法上都适用。最后分享一个小技巧多保存几组不同preset、不同mode下跑出来的result.txt统一用轨迹评测工具做对比把数值差异记录下来——这套数据以后写方案对比、做技术汇报时都能直接用。