1. 项目缘起与整体思路拆解1.1 为什么要在 RTX2060 上折腾 DS-SLAMDS-SLAM 这个项目做视觉 SLAM 方向的人应该都不陌生。它是在 ORB-SLAM2 基础上加入语义分割线程的一个动态场景 SLAM 方案核心思路是用语义信息剔除动态特征点让位姿估计在有人走动、有物体移动的环境里也能稳住。我第一次接触它是在一个室内机器人项目里当时用纯几何的 ORB-SLAM2 跑只要画面里有人走过轨迹就会明显跳变回环也容易失败。DS-SLAM 的语义线程正好能解决这个痛点。但问题在于这个项目对环境的依赖相当“挑食”。它需要 Caffe 做语义分割推理需要 CUDA 和 CUDNN 做 GPU 加速还需要一堆 OpenCV、Eigen、Pangolin、DBoW2、g2o 的依赖。官方 README 写得比较简略很多坑只有真正编译过才知道。我手上这台机器是 RTX2060 显卡CUDA 10.0 加 CUDNN 7这个组合在当年算是比较主流的配置但放到现在来看已经偏老很多新版本的库会直接不兼容。所以这篇记录的核心目的很明确把 DS-SLAM 从零到跑通的完整过程拆开把每一步为什么这么做、参数怎么选、报错怎么排查都讲清楚。适合谁看一是刚入门 SLAM 想跑通一个完整语义 SLAM 系统的同学二是手里有类似老显卡老 CUDA 环境、被各种依赖折磨过的开发者。我不会只贴命令而是把背后的逻辑讲透这样你换一台机器也能自己推导。1.2 整体方案选型与依赖关系梳理DS-SLAM 的架构可以理解成三条线程并行跟踪线程、局部建图线程、回环检测线程再加上一个独立的语义分割线程。语义线程用的是 SegNet 网络跑在 Caffe 框架上输出像素级的语义标签然后把“人”这类潜在动态物体的特征点标记出来跟踪线程再决定要不要用这些点。这就决定了它的依赖链条最底层是 GPU 驱动和 CUDA/CUDNN往上是 Caffe带 Python 接口再往上是 OpenCV需要 contrib 模块、Eigen3、Pangolin、DBoW2、g2o最上层才是 DS-SLAM 本体。任何一层版本对不上编译就会卡住。我选择 CUDA 10.0 CUDNN 7 而不是更新的版本原因很实际Caffe 这个框架已经很久没维护了它对 CUDA 11 以上的支持很差很多编译错误在 CUDA 10 上不会出现。RTX2060 是图灵架构算力 7.5CUDA 10.0 是支持这个算力的所以这个组合是能跑通的。如果你用的是 30 系或 40 系显卡那 CUDA 10 可能识别不了就得另想办法这个后面会提。提示不要盲目追求最新版本的 CUDA 和 CUDNN。SLAM 这类项目里Caffe 的兼容性往往比 GPU 性能更重要选一个被验证过的版本组合能省掉大量排查时间。2. 环境准备与核心依赖安装细节2.1 系统基础环境与显卡驱动确认我用的系统是 Ubuntu 18.04这个版本和 CUDA 10.0 的兼容性最好。如果你用 20.04gcc 版本默认是 9而 CUDA 10.0 只支持到 gcc 7需要手动降级比较麻烦。所以系统版本这一步就值得先想清楚。装完系统后第一件事是确认显卡驱动。执行nvidia-smi如果能看到 RTX2060 和对应的驱动版本说明驱动没问题。这里有个细节驱动版本要满足 CUDA 10.0 的最低要求一般 410 以上就行。如果没装驱动用系统自带的“附加驱动”工具装一个推荐版本即可不建议手动编译驱动容易和内核版本打架。确认完驱动接着装 CUDA 10.0。官方 runfile 方式比较可控我选的是cuda_10.0.130_410.48_linux.run。安装时有个关键选择当它问是否安装驱动时选 no因为驱动已经装好了重复装容易冲突。其他组件默认即可。装完 CUDA 后配置环境变量在~/.bashrc里加上export PATH/usr/local/cuda-10.0/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-10.0/lib64:$LD_LIBRARY_PATH然后source ~/.bashrc用nvcc -V验证能看到 10.0 版本就对了。CUDNN 7 的安装相对简单下载对应 CUDA 10.0 的版本解压后把头文件和库文件复制到 CUDA 目录sudo cp cuda/include/cudnn.h /usr/local/cuda-10.0/include/ sudo cp cuda/lib64/libcudnn* /usr/local/cuda-10.0/lib64/ sudo chmod ar /usr/local/cuda-10.0/include/cudnn.h sudo chmod ar /usr/local/cuda-10.0/lib64/libcudnn*验证 CUDNN 是否装好可以编译一个简单的测试程序或者直接看cat /usr/local/cuda-10.0/include/cudnn.h | grep CUDNN_MAJOR输出 7 就说明版本正确。2.2 OpenCV 与 Pangolin 的编译要点OpenCV 我选的是 3.4.x 版本因为 DS-SLAM 的代码里用了一些 3.x 的 API用 4.x 会有接口不兼容的问题。编译 OpenCV 时一定要带上 contrib 模块因为后面 Caffe 编译需要用到。cmake 配置里加上-DOPENCV_EXTRA_MODULES_PATH指向 contrib 的 modules 目录。编译 OpenCV 有个坑如果之前系统里装过 OpenCV可能会出现版本冲突。我的做法是先sudo apt-get remove掉系统自带的然后自己编译安装到/usr/local。编译时开-j并行能快不少但内存小于 8G 的机器建议-j2不然容易 OOM。Pangolin 是 ORB-SLAM2 系列用来做可视化的库DS-SLAM 也沿用了。它依赖 GLEW、GLUT、Boost 这些。安装依赖sudo apt-get install libglew-dev libboost-dev libboost-thread-dev libboost-filesystem-dev然后从源码编译 Pangolincmake 加-DBUILD_EXAMPLESON可以顺便编译示例验证是否装好。Pangolin 的版本也有讲究太新的版本和 ORB-SLAM2 的接口对不上我用的 v0.5 比较稳。2.3 Caffe 编译整个流程里最容易翻车的一环Caffe 是 DS-SLAM 语义线程的核心也是最难搞的部分。我编译的是带 Python 接口的版本因为语义分割的模型加载脚本是 Python 写的。编译前先装依赖sudo apt-get install libprotobuf-dev libleveldb-dev libsnappy-dev libopencv-dev libhdf5-serial-dev protobuf-compiler sudo apt-get install --no-install-recommends libboost-all-dev sudo apt-get install libgflags-dev libgoogle-glog-dev liblmdb-dev然后修改Makefile.config几个关键点USE_CUDNN : 1启用 CUDNN 加速OPENCV_VERSION : 3指定 OpenCV 版本CUDA_DIR : /usr/local/cuda-10.0PYTHON_INCLUDE和PYTHON_LIB指向你的 Python 路径我用的是 Python 2.7因为 Caffe 对 Python 3 的支持在当年还不完善INCLUDE_DIRS和LIBRARY_DIRS里要加上 hdf5 的路径Ubuntu 18.04 的 hdf5 路径和旧版不一样不加会报找不到 hdf5.h改完配置执行make all -j4然后make pycaffe。这一步报错概率很高常见的是 protobuf 版本冲突、hdf5 路径不对、boost 找不到。我的经验是报错信息里如果出现undefined reference多半是链接库路径问题如果出现fatal error: xxx.h: No such file就是 include 路径没配对。编译通过后把python目录加到PYTHONPATHexport PYTHONPATH/path/to/caffe/python:$PYTHONPATH然后python -c import caffe验证不报错就说明 Caffe 装好了。注意Caffe 编译时如果开了USE_CUDNN : 1但 CUDNN 版本和 CUDA 不匹配会在链接阶段报一堆cudnn相关的未定义符号。这时候先确认 CUDNN 版本再检查Makefile.config里的路径。3. DS-SLAM 本体编译与运行实操3.1 源码获取与依赖库编译顺序DS-SLAM 的源码里包含了 Thirdparty 目录里面有 DBoW2、g2o 这些。编译顺序很重要不能乱来。我的做法是先编译 Thirdparty 里的库再编译主工程。进入Thirdparty/DBoW2执行cmake .然后make生成libDBoW2.so。接着进Thirdparty/g2o同样cmake .和make。这两个库编译一般比较顺利如果报 Eigen 相关的错检查 Eigen3 是否装好版本建议 3.3 以上。然后回到主目录修改CMakeLists.txt。这里有几个必须改的地方把 Caffe 的路径指向你编译好的 Caffe 目录把 OpenCV 的路径指向你编译的 OpenCV 3.4确认CMAKE_CXX_FLAGS里有-stdc11因为代码里用了 C11 特性改完执行mkdir build cd build cmake .. make -j4编译过程中如果报undefined reference to caffe::Net说明 Caffe 库没链接上检查CMakeLists.txt里的link_directories和target_link_libraries。如果报 Pangolin 相关的错检查 Pangolin 的版本和头文件路径。3.2 语义分割模型的准备与路径配置DS-SLAM 的语义线程需要一个预训练的 SegNet 模型通常是.caffemodel和.prototxt两个文件。这些文件在官方仓库里可能没有直接提供需要自己找或者用作者提供的下载链接。我当时的做法是从项目 issue 里找到的模型文件放到SemanticSegmentation目录下。然后要修改语义分割的配置文件指定模型路径、输入图像尺寸、类别数等参数。这里有个细节SegNet 的输入尺寸要和跟踪线程的图像尺寸匹配不然会出现坐标对不上的问题。我一般把输入 resize 到 640x480和 ORB-SLAM2 的默认分辨率一致。还有一个容易忽略的点Caffe 的 Python 接口在加载模型时会占用 GPU 显存如果显存不够会报out of memory。RTX2060 有 6G 显存跑 SegNet 加 ORB-SLAM2 是够的但如果同时开其他 GPU 程序就可能不够。我的做法是跑之前先nvidia-smi看一下显存占用确保有 2G 以上空闲。3.3 数据集运行与参数调整DS-SLAM 官方推荐用 TUM 数据集的动态序列比如freiburg3_walking_xyz。运行命令大概是./Examples/RGB-D/rgbd_tum Vocabulary/ORBvoc.txt Examples/RGB-D/TUM3.yaml /path/to/dataset /path/to/associations.txt第一次跑的时候我发现轨迹漂移很严重后来发现是语义线程的阈值设得太宽松很多动态点没被剔除。调整SemanticSegmentation里的置信度阈值从默认的 0.5 提到 0.7效果明显改善。但这个阈值也不能太高太高会把静态点也误删导致特征点不足。还有一个参数是语义线程的更新频率。默认是每帧都跑语义分割但这样 GPU 占用很高帧率上不去。我改成每 3 帧跑一次语义中间帧复用上一次的语义结果帧率从 15 提升到 25 左右轨迹精度没有明显下降。运行过程中可以用 Pangolin 的可视化窗口观察特征点动态点被剔除后剩下的点基本都集中在静态结构上轨迹也平滑很多。4. 常见问题排查与避坑经验实录4.1 编译阶段典型报错与解决思路编译 DS-SLAM 时我遇到过几类典型报错整理成表格方便对照报错信息可能原因解决方法fatal error: caffe/caffe.hpp: No such fileCaffe 头文件路径没配在 CMakeLists 里加include_directories(${CAFFE_INCLUDE_DIRS})undefined reference to cudnnCreateCUDNN 库没链接确认Makefile.config里USE_CUDNN : 1并检查 CUDNN 路径error: ‘usleep’ was not declared缺少 unistd.h在对应源文件里加#include unistd.hImportError: No module named caffePYTHONPATH 没设把 Caffe 的 python 目录加到 PYTHONPATHSegmentation fault运行时报模型路径不对或显存不足检查模型文件是否存在nvidia-smi看显存这些报错里最耗时间的是 CUDNN 链接问题。我一开始以为是 CUDNN 没装好重装了好几遍后来发现是Makefile.config里 CUDNN 的路径写错了。所以遇到链接错误先检查路径再怀疑版本。4.2 运行阶段性能与精度问题调优运行阶段最常见的问题是帧率低和轨迹漂移。帧率低的原因通常是语义线程太慢解决办法有两个一是降低语义分割的输入分辨率比如从 640x480 降到 320x240速度能快一倍多二是减少语义线程的调用频率前面提到的每 3 帧跑一次就是有效的。轨迹漂移的原因比较复杂可能是语义阈值不合适也可能是特征点提取参数需要调。我的经验是先用默认参数跑一遍看轨迹和真值的对比如果漂移集中在有人出现的时段那就是语义剔除没做好调阈值如果全程都漂那可能是相机标定参数不对检查 YAML 文件里的内参。还有一个隐藏问题是时间戳同步。TUM 数据集的 RGB 和 Depth 图像时间戳如果对不齐跟踪会直接丢失。associations.txt 文件要确保时间戳差值在合理范围内一般小于 0.02 秒。提示调参时不要一次改多个参数每次只改一个记录结果这样才能知道哪个参数真正起作用。我见过有人一次改五六个参数最后跑通了也不知道是哪个起了作用。4.3 显卡与 CUDA 版本不匹配的应对方案如果你的显卡是 30 系或 40 系CUDA 10.0 可能识别不了因为新架构的算力不在 CUDA 10 的支持列表里。这种情况下有几个选择一是升级 CUDA 到 11.x但 Caffe 对 CUDA 11 的支持很差需要打补丁二是用 CPU 模式跑语义分割速度会慢很多但至少能跑通三是换用其他语义分割框架比如用 PyTorch 重写语义线程但这需要改代码。我个人的建议是如果只是学习 DS-SLAM 的思路用 CPU 模式跑通流程就够了不必纠结 GPU 加速。如果要做实际项目那可能要考虑更现代的 SLAM 方案比如 ORB-SLAM3 加语义分割的变体那些对新技术栈的支持更好。最后分享一个小技巧编译 Caffe 时如果反复失败可以试试用 Docker 镜像。有人做好了带 Caffe 和 CUDA 的镜像直接拉下来用能省掉大量编译时间。但 Docker 里的 GPU 透传需要配置 nvidia-docker这个也有点折腾看个人取舍。我在实际跑通 DS-SLAM 之后最大的体会是这类老项目的价值不在于它本身有多先进而在于它把语义 SLAM 的完整流程展示出来了。你把它的每个模块拆开看语义分割怎么和跟踪线程交互、动态点怎么剔除、位姿怎么优化这些思路放到今天依然有用。至于环境配置的坑踩过一次之后再遇到类似的项目就能举一反三了。
