尧图网站建设 
简介面向 Windows 平台的 ORB-SLAM2 实验构建包适合需要绕开 Linux 编译障碍、专注研究视觉 SLAM 算法的初学者与二次开发者。压缩包内已预编译全部第三方依赖库并附带属性表与配置文件简单配置后即可启动实验代码完成基础封装注释和调用结构清晰便于按需修改与调试。资源压缩包共 898 个文件约 154.62MB以程序头文件、C 源码、导入库与动态库为主同时包含 yaml 参数配置、属性表、工程解决方案及标定图片等覆盖从编译、运行到二次扩展所需的关键文件类型。目前已有 362 人下载学习。除可直接运行的 ORB-SLAM 单目程序外还附带 20 张张氏标定板图片可配合进行相机标定实验ORB 词袋文件、预编译中间文件等均已一并打包能够开箱即用。整体工程结构完整适合在此基础上开展特征点跟踪、位姿估计、闭环检测等经典 SLAM 模块的代码阅读与二次开发。1. Windows下跑通ORBSLAM实验从能编译到能出图之间的真实距离我第一次在Windows下碰ORB-SLAM时想法很简单clone下来cmake跑个数据集完事。结果光是依赖库就断断续续搞了四天。Windows下跑通ORBSLAM实验这件事难点从来不在SLAM算法本身而在它的依赖链——OpenCV、g2o、DBoW2、Pangolin每一套骨子里都是为GCC/Linux写的到了MSVC这边全得重新磨合。这篇文章把我实际验证过的完整路径拆出来依赖怎么锁版本CMakeLists改哪几行数据集怎么下以及那些让新手劝退的运行期崩溃到底怎么排查。适合两类人课程或毕设要拿ORB-SLAM2出结果的学生以及想在Windows上快速验证视觉SLAM效果的机器人工程师。读完你能在本机跑出第一张稀疏点云并且知道出问题时该去查哪儿。2. 移植ORB-SLAM到Windows的底层难点三个线程、四套依赖和一堆POSIX假设ORB-SLAM在Linux上算是一键编译的幸运儿——OpenCV用apt装Pangolin也是apt包Eigen3直接头文件即用。Windows的失守是系统性的C跨平台代码里用得最顺手的POSIX接口全都不见了CMake对MSVC的编译选项适配几乎是空白再加上多线程运行时和动态库加载的规则和Linux完全不同。移植的每一层都有账单要还。这一章先把这些账算清楚因为后面你上手改代码时所有报错本质上都能归到这里。2.1 ORB-SLAM的核心链路Tracking、LocalMapping、LoopClosing三线程怎么协作ORB-SLAM2的解算流程拆开看其实很清爽。前端Tracking线程负责逐帧提取ORB特征和当前局部地图做匹配用EPnP或直接线性变换求出相机位姿再通过局部BABundle Adjustment光束平差精磨。这是SLAM比纯VO视觉里程计强的地方——不是只算相邻帧而是反复优化历史和当前帧的关系。LocalMapping线程把新的关键帧插入地图剔除冗余点生成新的地图点。LoopClosing线程负责检测回环用DBoW2的词袋模型对当前帧和历史关键帧搜索一旦发现闭环就用g2o做全局位姿图优化把累积漂移一把拉回来。这三个线程在Windows下的意义不只是概念——它们是真实存在的std::thread编译时你必须保证链接的C运行时一致。MSVC的/MT和/MD混用、Debug和Release混用都会在第三个线程启动时给你颜色看。更隐蔽的是三个线程共享一批OpenCV Mat和Map数据这些对象的构造和析构会跨越dll边界。如果exe和dll用的运行时不一致对象在dll里new、到exe里delete轻则内存泄漏重则heap corruption表现就是跑几分钟后随机崩溃。这也是后面DLL污染导致的崩溃往往随机发生的原因——不是玄学是线程在访问一块已经被写坏的内存。2.2 Windows上的依赖库选型OpenCV、g2o、DBoW2、Pangolin的版本怎么锁依赖版本不要追新这是我反复吃亏后的第一句忠告。ORB-SLAM2源码仓库里自带Thirdparty/g2o和Thirdparty/DBoW2——这两个子目录本身就是官方锁版本的方式。你在Windows上最省力的做法是直接用源码里的这两个目录通过add_subdirectory编进主工程而不是自己去网上拉一份新版本的g2o。有人从vcpkg装最新g2o再链接函数签名直接对不上报错几百行起步而且g2o的并行优化在MSVC下的表现很不稳定。OpenCV的选型ORB-SLAM2的CMakeLists里find_package(OpenCV)只要求版本大于等于3.x但Windows下建议直接上4.x官方预编译包。4.1.0和4.5.1都是可靠选择注意4.5之后vcpkg会把OpenCV拆成opencv_core450.lib等一堆库而官方预编译包是单独的opencv_world450.lib后者更符合ORB-SLAM2原本的链接写法。尽量不要用3.xORB-SLAM2部分分支用了cv::Mat::forEach等较新的接口3.4能编过但会有兼容告警。Eigen3是纯头文件库CMake里给对include目录就行版本锁3.3.7或3.3.9别上3.4.x——3.4新增的宏定义在MSVC下会产生大量警告压过了真正的错误信息。Pangolin是可视化库也是Windows新手最大的坑。它依赖GLEW和OpenGLLinux下apt两行能装完Windows下要么vcpkg install pangolin要么手动编译。我的选择是vcpkg把triplet固定成x64-windows不要用x64-windows-static——静态链Pangolin时它会把OpenGL、GLEW全静态进来链接期格外长运行期还容易和系统里的opengl32.dll冲突。2.3 代码里藏着多少非Windows假设unistd.h、mbstowcs与-fPIC当你真要把源码过一遍MSVC拦截点至少有四个。第一多处源代码include了unistd.h比如系统文件状态判断那类逻辑Windows没有这个头文件常见做法是把include行直接注释掉因为实际用到的符号很少。第二System.cc里用了mbstowcs这类多字节转宽字符函数Windows下不是不能跑但会依赖locale且产生告警。第三根目录CMakeLists.txt里那几行-O3 -marchnative -fPICMSVC的cl.exe一个都不认识满屏的warning D9002: ignoring unknown option这就是新手编译时最常见的第一道墙。第四部分.cc用了S_ISDIR、stat结构体Windows的VS里stat是_stati64字段名也不同。还有一处隐蔽问题ORB-SLAM2的cmake_modules目录里放的是给Linux写的FindG2O.cmake、FindDBoW2.cmake里面用了pkg-config和Unix路径Windows下find_package基本找不到任何东西。所以主CMakeLists里如果把find_package(G2O)和find_package(DBoW2)当真后面target_link_libraries必然失败。正确做法是放弃find_package直接add_subdirectory。这些差异叠加起来就导致原版源码直接过Windows编译器是极小概率事件。下面的编译部分会把整套构建流程从头铺一遍。3. 用VS2019 CMake编译ORB-SLAM2我从零到出exe的完整命令这一章直接给可抄的作业。我的环境Windows 10 Pro x64Visual Studio 2019 CommunityMSVC v142工具集CMake 3.22OpenCV 4.1.0 x64预编译包Eigen 3.3.7Pangolin走vcpkg安装。这套组合我完整跑通了TUM数据集和摄像头实时模式下面按顺序来。3.1 环境版本表一套验证过不打架的组合组件版本安装方式说明Visual Studio2019 (v142)安装器选使用C的桌面开发不要只装Build Tools后面排错要用IDECMake3.16以上官网zip解压即用命令行模式即可无需装GUI版OpenCV4.1.0或4.5.1官网Windows包解压后把build/x64/vc15/bin加入PATH4.x的lib名是opencv_world410.libEigen3.3.7官网tar.gz解压仅头文件实际只用到Eigen/Core、Dense等Pangolinvcpkg的0.8版vcpkg install pangolin --triplet x64-windows会自动带GLEW依赖ORB-SLAM2原版GitHub仓库git clone别用--depth1容易丢子模块Thirdparty/g2o和DBoW2保留在仓库里版本选型里最容易翻车的是OpenCV用OpenCV 3.x会有一堆函数签名差异用OpenCV 4.10以上又可能在图像解码和Pangolin窗口事件上有冲突。锁4.1.x最省心这也是ORB-SLAM2后期官方CI里Windows构建用过的版本区间。3.2 先编译Thirdparty里的g2o和DBoW2完整命令与参数ORB-SLAM2仓库的Thirdparty目录下有g2o、DBoW2和DLib三个子模块。DLib是词袋训练工具不需要单独编DBoW2会带。我采用的方式是直接保留主CMakeLists里的add_subdirectory语句让主工程一次性把依赖编出来——省事而且保证和主工程使用完全相同的编译选项和C运行时。不过要让这一步在MSVC下顺利得先做两个小手术。打开根目录的CMakeLists.txt# ORBSLAM2/CMakeLists.txtWindows下需要注释掉的三行 # set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Wall -O3 -marchnative ) # set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall -O3 -marchnative) # 上面两行是GCC参数。如果留着cl.exe会把它当成未知选项 # 虽然只是warning D9002但会淹掉真正有用的编译输出。 # 还有这一行Windows下建议注释掉或改写成绝对路径 # set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/lib)注释掉flag之后MSVC的优化靠Release配置默认的/O2对SLAM的运行时性能影响不大。输出目录那行不处理的话dll会全部堆在build/Thirdparty/g2o/Release里后面链接exe时你得手动找一堆路径容易错。然后执行构建# 在ORB-SLAM2根目录下执行 mkdir build cd build cmake .. -G Visual Studio 16 2019 -A x64 -DCMAKE_BUILD_TYPERelease cmake --build . --config Release --parallel 8第一条cmake命令的-G指定生成VS2019工程文件-A x64锁定64位架构。CMAKE_BUILD_TYPERelease写在生成期而不是在VS里切是为了让依赖库从最开始就拿到正确的宏定义。最后一行--parallel 8按你的CPU核数改16线程的机器写8也行主要避免并行编译时内存被挤爆。第一次构建大约15到25分钟取决于机器。构建结束后去build/Thirdparty/g2o/Release和build/Thirdparty/DBoW2/Release确认生成了g2o.lib、DBoW2.lib以及对应的dll。如果哪个lib没生成不要往下走先回查那一步的报错——这是整个流程里最值得花时间的检查点后面所有链接失败都从这里来。3.3 主工程CMakeLists.txt要改的地方从找库到链接目录主CMakeLists在Windows上除了注释flag还要补几处内容否则find_package会找不到依赖# 1. 指定OpenCV路径放在find_package(OpenCV)之前 set(OpenCV_DIR D:/opencv/build) set(CMAKE_PREFIX_PATH D:/opencv/build) # 2. 显式声明Eigen目录 include_directories(D:/thirdparty/eigen-3.3.7) # 3. 如果Pangolin用vcpkg安装把这行加进去 set(CMAKE_TOOLCHAIN_FILE C:/vcpkg/scripts/buildsystems/vcpkg.cmake) # 4. find_package语句保持原样即可 # find_package(OpenCV 4.1 QUIET) # find_package(Eigen3 3.1.0 REQUIRED) # find_package(Pangolin REQUIRED)第1点是关键机器上如果装了多个OpenCV版本必须用OpenCV_DIR写死成你解压的那个路径否则vcpkg或Anaconda里的OpenCV会被优先找到版本不对时编译期不报错运行期必崩。第3点的CMAKE_TOOLCHAIN_FILE是vcpkg向CMake暴露已装包的标准方式加了它find_package(Pangolin)就能正确找到。如果不想用整链toolchain也可以把C:/vcpkg/installed/x64-windows/share/pangolin单独追加进CMAKE_PREFIX_PATH效果一样。3.4 命令行编译还是CMake-GUI我推荐的方式这里有个分歧很多人喜欢用CMake-GUI点Configure可视化勾选。我的建议是命令行为主、GUI为辅。原因是ORB-SLAM2这个工程的CMakeLists写得不规范GUI里cache条目很琐碎路径输错一个就要全量重配命令行则可以把路径写死错误一目了然。GUI也可以用来排错——当构建报找不到Pangolin时打开GUI看Pangolin_DIR和PANGO_INCLUDE_DIR两个cache变量分别指向哪这是最快的诊断方式。另外强调一点不要用CLion或Qt Creator自带的CMake来生成这个老工程它们会在Generator上做手脚导致exe运行时依赖一堆说不清的dll。4. 跑通第一个数据集实验TUM freiburg1_desk从下载到建图编译产物出来后离第一张点云只差数据。很多新手在这一步翻车不是命令错了而是数据集选错。下面先说清楚下哪个、怎么下。4.1 数据集下载与解压为什么我推荐TUM的freiburg1序列TUM RGB-D数据集是ORB-SLAM2作者原版readme里用过的基准。freiburg1_desk这个序列包含一个桌面场景相机的运动有平移、旋转和回环非常适合验证三线程完整工作链。下载可以用脚本或浏览器# 从TUM官网下载约2GB的tgz压缩包 # https://cvg.cit.tum.de/rgbd/dataset/freiburg1/rgbd_dataset_freiburg1_desk.tgz tar -xvzf rgbd_dataset_freiburg1_desk.tgz # 解压后检查目录结构 ls rgbd_dataset_freiburg1_desk # depth/ rgb/ groundtruth.txt rgb.txttar命令在Windows 10自带的WSL和Git Bash里都能用如果直接在资源管理器里右键解压务必确认解压后得到一个单层目录而不是嵌套多层。解压后打开rgb.txt确认是时间戳 路径两列格式ORB-SLAM2的读取器靠这个文件驱动帧率这个文件有问题后面全是空图。为什么不推荐EuRoC数据集EuRoC是MAV无人机数据集单目序列有cam0、cam1目录时间戳在state_groundtruth.csv里文件结构和TUM完全不同。mono_tum这个example根本不认它你连main函数都进不了在LoadImages读文件列表阶段就会返回-1。注意数据集和工程路径都不要放在中文目录、不要放在桌面的网盘同步目录ORB-SLAM2的文件读取对非ASCII路径支持极差后面第五章会具体说明。4.2 改mono_tum.cpp里的三个路径参数ORB-SLAM2自带的mono_tum例子main函数开头用argc判断参数数量小于4就打印用法退出。它需要的三个参数是词典文件、相机标定yaml、数据集序列路径。我建议直接在源码里写死避免每次敲错反斜杠// Examples/Monocular/mono_tum.cpp int main(int argc, char **argv) { // 这三个路径改成你自己的绝对路径统一用正斜杠 string vocabFile D:/ORB_SLAM2/Vocabulary/ORBvoc.txt; string settingsFile D:/ORB_SLAM2/Examples/Monocular/TUM1.yaml; string sequencePath D:/datasets/rgbd_dataset_freiburg1_desk; // 原代码的argc逻辑保留做兜底命令行参数优先 if (argc 1) vocabFile argv[1]; if (argc 2) settingsFile argv[2]; if (argc 3) sequencePath argv[3]; // 后面的LoadImages(...)不用改 }这段代码的逻辑说明用if (argc 1)做覆盖既保留命令行自由度又能在IDE里直接F5跑。路径统一用正斜杠的原因是C字符串里反斜杠是转义符写F:\dataset\rgb实际得到的是F:、换行、dataset、回车、rgb的混合串文件系统根本找不到这个路径。相机标定文件TUM1.yaml里面写的是fx、fy、cx、cy和畸变系数对应freiburg1相机的内参。如果你换用freiburg2序列这里要换成TUM2.yaml否则建出来的图是弯的回环检测很难触发。运行前确认yaml里的Camera.fps是30和数据集采集帧率一致不一致时Tracking线程会丢失跟踪。4.3 运行与预期输出从加载词典到弹出Pangolin窗口编译并运行# 在ORB_SLAM2/build目录下进入对应配置的输出目录 cd build/Examples/Monocular/Release ./mono_tum.exe D:/ORB_SLAM2/Vocabulary/ORBvoc.txt D:/ORB_SLAM2/Examples/Monocular/TUM1.yaml D:/datasets/rgbd_dataset_freiburg1_desk运行后正常日志分三个阶段。第一阶段毫秒内打印Loading ORB Vocabulary...几秒钟加载完毕说明DBoW2词袋库正常。第二阶段控制台每处理一帧打印当前关键帧序号和地图点数量同时弹出一个Pangolin窗口里面是相机轨迹和稀疏点云。第三阶段跑完所有图像后ORB-SLAM2自动把轨迹写到KeyFrameTrajectory.txt最后一行显示总处理帧数。注意如果运行到二三十帧时窗口黑屏或卡住先别急着杀进程——它可能只是短暂丢失跟踪。观察日志里有没有Tracking lost字样有的话检查标定yaml的fx、fy值以及运行前是否把OpenCV的release版dll放进了PATH。4.4 怎么看建图结果点云、轨迹和漂移的判别当窗口出现第一块稀疏点云时不要只看有没有图要看三个指标。第一点云是否在桌面边缘形成连续平面如果点像碎渣一样飞散在相机正前方多半是标定焦距错了第二轨迹线在相机回到原点时有没有闭合闭合代表回环检测成功这是LoopClosing线程在起作用第三右侧的关键帧列表是否匀速增长如果每帧都新建关键帧说明ORB特征质量差或帧间运动太快调大yaml里ORBextractor.nFeatures参数默认2000可以提到3000。跑完发现KeyFrameTrajectory.txt的帧数比数据集总帧数少很多是正常的——SLAM只保存关键帧。想量化验证精度用TUM官网的评价工具python evaluate_ate.py groundtruth.txt KeyFrameTrajectory.txt --plot ate.pngATE中位数小于5cm这个ORB-SLAM实验就算真正成立如果大于20cm先排查标定和帧率而不是怀疑算法本身。5. 避坑实录五个让新手劝退的Windows编译运行问题这一章我把实际踩过和帮别人排查过的五条最具代表性的问题写出来按现象→原因→解决的顺序你在Windows上撞到的报错基本逃不出这五个圈子。5.1 Debug/Release错配第11帧必崩的玄学现象项目用VS打开后没切配置默认Debug编译能过运行到大约第11帧或LocalMapping Thread启动时报错信息是Unhandled exception at 0x... Microsoft C exception: cv::Exception甚至直接访问冲突。原因ORB-SLAM2的依赖库全用Release构建而主工程用Debug运行时STL容器和OpenCV Mat内部的内存布局会因_DEBUG宏产生变化。更致命的是DBoW2里的vector和unordered_map在Debug下迭代器尺寸不同Tracking线程往局部地图里插入点时踩坏邻接内存。这不是你代码的问题是MSVC下Debug和Release的ABI不兼容。解决整个依赖链统一用Release。VS顶部配置管理器切成Release确认OpenCV链接的是opencv_world410.lib而不是opencv_world410d.libPangolin的vcpkg包也要确认不是x64-windows-debug。如果项目里有人改过/Fd、/Z7这类调试信息参数也可能在Release下触发类似问题保持默认即可。5.2 DLL加载乱序找不到或无法定位程序输入点现象exe能启动几毫秒后弹窗找不到opencv_world410.dll或者系统里明明有OpenCV却提示无法定位程序输入点xxx于动态链接库opencv_world410.dll。原因Windows加载dll的顺序是exe目录→系统目录→PATH而不是你最近装的OpenCV优先。机器上如果装过Anaconda、ROS2、或任何自带OpenCV的软件它们的dll很可能先被加载版本和ORB-SLAM2编译期用的接口对不上就会报输入点找不到。解决把你自己那份OpenCV的build/x64/vc15/bin放到PATH最前面并确认在VS里调试时用的环境变量是PATHD:\opencv\build\x64\vc15\bin;%PATH%。最彻底的做法是运行时把opencv_world410.dll、Pangolin的dll直接复制到exe同目录这样机器上其他软件带的OpenCV就再也干扰不到你。5.3 反斜杠路径和中文目录读数据集时静默丢帧现象数据集放在类似F:\数据集\桌面的路径下编译和运行都正常控制台日志也在推进但Pangolin窗口里只有零散几个点云像被抽了帧或者卡在Find the any hit in the region不动。原因ORB-SLAM2里的cv::glob和文件流对非ASCII路径支持极差中文目录在高版本OpenCV下可能匹配出乱码文件名imread返回空MatSLAM把空帧当成正常帧跳过。反斜杠路径则是C转义把路径截断。解决数据集和工程一律放纯英文路径比如D:\ORB_SLAM2、D:\datasets代码里的路径统一用正斜杠——Windows的文件API和OpenCV都接受正斜杠唯独字符串转义不接受。排查这类问题最快的办法是在System.cc的LoadImageSequence里打印拼接后的完整路径看实际去读的是哪个文件。5.4 imread进灰度断言崩溃通道类型没有钉死现象运行到某帧控制台弹断言失败assertion failed (src.channels() 1 || src.channels() 3 || src.channels() 4) in cv::cvtColor或直接崩在OpenCV的mat.inl.cpp。原因ORB-SLAM2的Tracking接口要求输入灰度图CV_8UC1有人把RGB图直接喂进TrackMonocular或者数据集的png本身是三通道但bgr顺序和预期不一致。真正的原因是读取后的Mat没有统一转成灰阶就往下走。解决喂给TrackMonocular之前加一行转换加判空cv::Mat gray; cv::cvtColor(colorFrame, gray, cv::COLOR_BGR2GRAY); if (gray.empty()) continue;不要用image.channels()1就跳过转换的旁路老老实实每帧都转。TUM数据集的png本来就是灰度图不会触发但换成自己录的视频或摄像头流100%会崩。这段对你接实时视频流时特别有用。5.5 数据集选错拿EuRoC当TUM跑的结果现象用mono_tum去跑EuRoC数据集控制台输出Failed to open file ...cam0...然后直接退出或者跑了FLIR相机序列点云严重倾斜。原因ORB-SLAM2每个example写死了读取格式。mono_tum读TUM的rgb.txt加深度目录结构mono_euroc读EuRoC的cam0/data目录和data.csv时间戳两者的文件列表解析完全不同。把EuRoC塞给mono_tumLoadImages函数第一次fopen就返回false。解决先明确数据集属于哪个基准。TUM就用mono_tumEuRoC就用mono_euroc它的main函数需要额外传标定文件和传感时间戳文件做对齐。如果只是验证Windows编译是否成功最快的办法是下一个小序列几百MB十分钟跑完别一上来下EuRoC整包十几个GB。这个坑特别隐蔽因为它不报错只是行为异常。6. 进阶把摄像头接进去跑实时SLAM验证你的Windows链路数据集跑通只是能复现要让这个实验对你有实际价值下一步是把视频流换成你自己的摄像头。ORB-SLAM2的Examples/Monocular下有mono_webcam.cc逻辑比mono_tum更简单用cv::VideoCapture打开摄像头逐帧取图转灰度后直接送TrackMonocular。// Examples/Monocular/mono_webcam.cc 里的核心循环词典和标定加载和tum一致 cv::VideoCapture cap(0); // 0表示默认摄像头笔记本内置也是0 if (!cap.isOpened()) { std::cerr Camera open failed std::endl; return -1; } cap.set(cv::CAP_PROP_FRAME_WIDTH, 640); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 480); double timestamp 0.0; cv::Mat frame; while (cv::waitKey(1) ! q) { cap frame; if (frame.empty()) continue; cv::Mat gray; cv::cvtColor(frame, gray, cv::COLOR_BGR2GRAY); Sophus::SE3f Tcw sl.TrackMonocular(gray, timestamp); timestamp 1.0 / 30.0; // 按30fps模拟时间戳 // Tcw是当前帧相机位姿可以打印矩阵或叠加到画面 }参数说明分辨率设640x480是有意的ORB特征提取数量在更高分辨率下会翻倍低配机器容易在Tracking线程堆积帧导致SLAM跑不过实际帧率。时间戳用1/30递增是模拟真实时间有更高精度要求时用cv::getTickCount换算否则里程计累积误差会被当成真实时间差参与优化。把相机拿在手里做平移、旋转和回环动作窗口内点云应当稳定增长回环那一刻轨迹会发生一次明显跳变校正——这个现象是这个实验对你链路完整性的终极验证。我在这块吃过一个教训笔记本UVC摄像头在微信会议用完后cap.isOpened()返回true但cap frame一直给空图原因是摄像头被另一个进程独占。当时我在设备管理器里看见该设备已被占用才反应过来是软件抢了摄像头。从此我养成跑实时SLAM前先用系统相机应用确认能出画面的习惯。Windows下的ORB-SLAM实验编译只是第一关真正让人崩溃的都是这些操作系统底层的脾气——但只要你愿意一步步日志排查这条路一定能走通。希望帮到你。本文还有配套的精品资源点击获取 Windows下跑通ORB-SLAM2：从编译到建图的完整避坑指南
简介面向 Windows 平台的 ORB-SLAM2 实验构建包适合需要绕开 Linux 编译障碍、专注研究视觉 SLAM 算法的初学者与二次开发者。压缩包内已预编译全部第三方依赖库并附带属性表与配置文件简单配置后即可启动实验代码完成基础封装注释和调用结构清晰便于按需修改与调试。资源压缩包共 898 个文件约 154.62MB以程序头文件、C 源码、导入库与动态库为主同时包含 yaml 参数配置、属性表、工程解决方案及标定图片等覆盖从编译、运行到二次扩展所需的关键文件类型。目前已有 362 人下载学习。除可直接运行的 ORB-SLAM 单目程序外还附带 20 张张氏标定板图片可配合进行相机标定实验ORB 词袋文件、预编译中间文件等均已一并打包能够开箱即用。整体工程结构完整适合在此基础上开展特征点跟踪、位姿估计、闭环检测等经典 SLAM 模块的代码阅读与二次开发。1. Windows下跑通ORBSLAM实验从能编译到能出图之间的真实距离我第一次在Windows下碰ORB-SLAM时想法很简单clone下来cmake跑个数据集完事。结果光是依赖库就断断续续搞了四天。Windows下跑通ORBSLAM实验这件事难点从来不在SLAM算法本身而在它的依赖链——OpenCV、g2o、DBoW2、Pangolin每一套骨子里都是为GCC/Linux写的到了MSVC这边全得重新磨合。这篇文章把我实际验证过的完整路径拆出来依赖怎么锁版本CMakeLists改哪几行数据集怎么下以及那些让新手劝退的运行期崩溃到底怎么排查。适合两类人课程或毕设要拿ORB-SLAM2出结果的学生以及想在Windows上快速验证视觉SLAM效果的机器人工程师。读完你能在本机跑出第一张稀疏点云并且知道出问题时该去查哪儿。2. 移植ORB-SLAM到Windows的底层难点三个线程、四套依赖和一堆POSIX假设ORB-SLAM在Linux上算是一键编译的幸运儿——OpenCV用apt装Pangolin也是apt包Eigen3直接头文件即用。Windows的失守是系统性的C跨平台代码里用得最顺手的POSIX接口全都不见了CMake对MSVC的编译选项适配几乎是空白再加上多线程运行时和动态库加载的规则和Linux完全不同。移植的每一层都有账单要还。这一章先把这些账算清楚因为后面你上手改代码时所有报错本质上都能归到这里。2.1 ORB-SLAM的核心链路Tracking、LocalMapping、LoopClosing三线程怎么协作ORB-SLAM2的解算流程拆开看其实很清爽。前端Tracking线程负责逐帧提取ORB特征和当前局部地图做匹配用EPnP或直接线性变换求出相机位姿再通过局部BABundle Adjustment光束平差精磨。这是SLAM比纯VO视觉里程计强的地方——不是只算相邻帧而是反复优化历史和当前帧的关系。LocalMapping线程把新的关键帧插入地图剔除冗余点生成新的地图点。LoopClosing线程负责检测回环用DBoW2的词袋模型对当前帧和历史关键帧搜索一旦发现闭环就用g2o做全局位姿图优化把累积漂移一把拉回来。这三个线程在Windows下的意义不只是概念——它们是真实存在的std::thread编译时你必须保证链接的C运行时一致。MSVC的/MT和/MD混用、Debug和Release混用都会在第三个线程启动时给你颜色看。更隐蔽的是三个线程共享一批OpenCV Mat和Map数据这些对象的构造和析构会跨越dll边界。如果exe和dll用的运行时不一致对象在dll里new、到exe里delete轻则内存泄漏重则heap corruption表现就是跑几分钟后随机崩溃。这也是后面DLL污染导致的崩溃往往随机发生的原因——不是玄学是线程在访问一块已经被写坏的内存。2.2 Windows上的依赖库选型OpenCV、g2o、DBoW2、Pangolin的版本怎么锁依赖版本不要追新这是我反复吃亏后的第一句忠告。ORB-SLAM2源码仓库里自带Thirdparty/g2o和Thirdparty/DBoW2——这两个子目录本身就是官方锁版本的方式。你在Windows上最省力的做法是直接用源码里的这两个目录通过add_subdirectory编进主工程而不是自己去网上拉一份新版本的g2o。有人从vcpkg装最新g2o再链接函数签名直接对不上报错几百行起步而且g2o的并行优化在MSVC下的表现很不稳定。OpenCV的选型ORB-SLAM2的CMakeLists里find_package(OpenCV)只要求版本大于等于3.x但Windows下建议直接上4.x官方预编译包。4.1.0和4.5.1都是可靠选择注意4.5之后vcpkg会把OpenCV拆成opencv_core450.lib等一堆库而官方预编译包是单独的opencv_world450.lib后者更符合ORB-SLAM2原本的链接写法。尽量不要用3.xORB-SLAM2部分分支用了cv::Mat::forEach等较新的接口3.4能编过但会有兼容告警。Eigen3是纯头文件库CMake里给对include目录就行版本锁3.3.7或3.3.9别上3.4.x——3.4新增的宏定义在MSVC下会产生大量警告压过了真正的错误信息。Pangolin是可视化库也是Windows新手最大的坑。它依赖GLEW和OpenGLLinux下apt两行能装完Windows下要么vcpkg install pangolin要么手动编译。我的选择是vcpkg把triplet固定成x64-windows不要用x64-windows-static——静态链Pangolin时它会把OpenGL、GLEW全静态进来链接期格外长运行期还容易和系统里的opengl32.dll冲突。2.3 代码里藏着多少非Windows假设unistd.h、mbstowcs与-fPIC当你真要把源码过一遍MSVC拦截点至少有四个。第一多处源代码include了unistd.h比如系统文件状态判断那类逻辑Windows没有这个头文件常见做法是把include行直接注释掉因为实际用到的符号很少。第二System.cc里用了mbstowcs这类多字节转宽字符函数Windows下不是不能跑但会依赖locale且产生告警。第三根目录CMakeLists.txt里那几行-O3 -marchnative -fPICMSVC的cl.exe一个都不认识满屏的warning D9002: ignoring unknown option这就是新手编译时最常见的第一道墙。第四部分.cc用了S_ISDIR、stat结构体Windows的VS里stat是_stati64字段名也不同。还有一处隐蔽问题ORB-SLAM2的cmake_modules目录里放的是给Linux写的FindG2O.cmake、FindDBoW2.cmake里面用了pkg-config和Unix路径Windows下find_package基本找不到任何东西。所以主CMakeLists里如果把find_package(G2O)和find_package(DBoW2)当真后面target_link_libraries必然失败。正确做法是放弃find_package直接add_subdirectory。这些差异叠加起来就导致原版源码直接过Windows编译器是极小概率事件。下面的编译部分会把整套构建流程从头铺一遍。3. 用VS2019 CMake编译ORB-SLAM2我从零到出exe的完整命令这一章直接给可抄的作业。我的环境Windows 10 Pro x64Visual Studio 2019 CommunityMSVC v142工具集CMake 3.22OpenCV 4.1.0 x64预编译包Eigen 3.3.7Pangolin走vcpkg安装。这套组合我完整跑通了TUM数据集和摄像头实时模式下面按顺序来。3.1 环境版本表一套验证过不打架的组合组件版本安装方式说明Visual Studio2019 (v142)安装器选使用C的桌面开发不要只装Build Tools后面排错要用IDECMake3.16以上官网zip解压即用命令行模式即可无需装GUI版OpenCV4.1.0或4.5.1官网Windows包解压后把build/x64/vc15/bin加入PATH4.x的lib名是opencv_world410.libEigen3.3.7官网tar.gz解压仅头文件实际只用到Eigen/Core、Dense等Pangolinvcpkg的0.8版vcpkg install pangolin --triplet x64-windows会自动带GLEW依赖ORB-SLAM2原版GitHub仓库git clone别用--depth1容易丢子模块Thirdparty/g2o和DBoW2保留在仓库里版本选型里最容易翻车的是OpenCV用OpenCV 3.x会有一堆函数签名差异用OpenCV 4.10以上又可能在图像解码和Pangolin窗口事件上有冲突。锁4.1.x最省心这也是ORB-SLAM2后期官方CI里Windows构建用过的版本区间。3.2 先编译Thirdparty里的g2o和DBoW2完整命令与参数ORB-SLAM2仓库的Thirdparty目录下有g2o、DBoW2和DLib三个子模块。DLib是词袋训练工具不需要单独编DBoW2会带。我采用的方式是直接保留主CMakeLists里的add_subdirectory语句让主工程一次性把依赖编出来——省事而且保证和主工程使用完全相同的编译选项和C运行时。不过要让这一步在MSVC下顺利得先做两个小手术。打开根目录的CMakeLists.txt# ORBSLAM2/CMakeLists.txtWindows下需要注释掉的三行 # set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Wall -O3 -marchnative ) # set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall -O3 -marchnative) # 上面两行是GCC参数。如果留着cl.exe会把它当成未知选项 # 虽然只是warning D9002但会淹掉真正有用的编译输出。 # 还有这一行Windows下建议注释掉或改写成绝对路径 # set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/lib)注释掉flag之后MSVC的优化靠Release配置默认的/O2对SLAM的运行时性能影响不大。输出目录那行不处理的话dll会全部堆在build/Thirdparty/g2o/Release里后面链接exe时你得手动找一堆路径容易错。然后执行构建# 在ORB-SLAM2根目录下执行 mkdir build cd build cmake .. -G Visual Studio 16 2019 -A x64 -DCMAKE_BUILD_TYPERelease cmake --build . --config Release --parallel 8第一条cmake命令的-G指定生成VS2019工程文件-A x64锁定64位架构。CMAKE_BUILD_TYPERelease写在生成期而不是在VS里切是为了让依赖库从最开始就拿到正确的宏定义。最后一行--parallel 8按你的CPU核数改16线程的机器写8也行主要避免并行编译时内存被挤爆。第一次构建大约15到25分钟取决于机器。构建结束后去build/Thirdparty/g2o/Release和build/Thirdparty/DBoW2/Release确认生成了g2o.lib、DBoW2.lib以及对应的dll。如果哪个lib没生成不要往下走先回查那一步的报错——这是整个流程里最值得花时间的检查点后面所有链接失败都从这里来。3.3 主工程CMakeLists.txt要改的地方从找库到链接目录主CMakeLists在Windows上除了注释flag还要补几处内容否则find_package会找不到依赖# 1. 指定OpenCV路径放在find_package(OpenCV)之前 set(OpenCV_DIR D:/opencv/build) set(CMAKE_PREFIX_PATH D:/opencv/build) # 2. 显式声明Eigen目录 include_directories(D:/thirdparty/eigen-3.3.7) # 3. 如果Pangolin用vcpkg安装把这行加进去 set(CMAKE_TOOLCHAIN_FILE C:/vcpkg/scripts/buildsystems/vcpkg.cmake) # 4. find_package语句保持原样即可 # find_package(OpenCV 4.1 QUIET) # find_package(Eigen3 3.1.0 REQUIRED) # find_package(Pangolin REQUIRED)第1点是关键机器上如果装了多个OpenCV版本必须用OpenCV_DIR写死成你解压的那个路径否则vcpkg或Anaconda里的OpenCV会被优先找到版本不对时编译期不报错运行期必崩。第3点的CMAKE_TOOLCHAIN_FILE是vcpkg向CMake暴露已装包的标准方式加了它find_package(Pangolin)就能正确找到。如果不想用整链toolchain也可以把C:/vcpkg/installed/x64-windows/share/pangolin单独追加进CMAKE_PREFIX_PATH效果一样。3.4 命令行编译还是CMake-GUI我推荐的方式这里有个分歧很多人喜欢用CMake-GUI点Configure可视化勾选。我的建议是命令行为主、GUI为辅。原因是ORB-SLAM2这个工程的CMakeLists写得不规范GUI里cache条目很琐碎路径输错一个就要全量重配命令行则可以把路径写死错误一目了然。GUI也可以用来排错——当构建报找不到Pangolin时打开GUI看Pangolin_DIR和PANGO_INCLUDE_DIR两个cache变量分别指向哪这是最快的诊断方式。另外强调一点不要用CLion或Qt Creator自带的CMake来生成这个老工程它们会在Generator上做手脚导致exe运行时依赖一堆说不清的dll。4. 跑通第一个数据集实验TUM freiburg1_desk从下载到建图编译产物出来后离第一张点云只差数据。很多新手在这一步翻车不是命令错了而是数据集选错。下面先说清楚下哪个、怎么下。4.1 数据集下载与解压为什么我推荐TUM的freiburg1序列TUM RGB-D数据集是ORB-SLAM2作者原版readme里用过的基准。freiburg1_desk这个序列包含一个桌面场景相机的运动有平移、旋转和回环非常适合验证三线程完整工作链。下载可以用脚本或浏览器# 从TUM官网下载约2GB的tgz压缩包 # https://cvg.cit.tum.de/rgbd/dataset/freiburg1/rgbd_dataset_freiburg1_desk.tgz tar -xvzf rgbd_dataset_freiburg1_desk.tgz # 解压后检查目录结构 ls rgbd_dataset_freiburg1_desk # depth/ rgb/ groundtruth.txt rgb.txttar命令在Windows 10自带的WSL和Git Bash里都能用如果直接在资源管理器里右键解压务必确认解压后得到一个单层目录而不是嵌套多层。解压后打开rgb.txt确认是时间戳 路径两列格式ORB-SLAM2的读取器靠这个文件驱动帧率这个文件有问题后面全是空图。为什么不推荐EuRoC数据集EuRoC是MAV无人机数据集单目序列有cam0、cam1目录时间戳在state_groundtruth.csv里文件结构和TUM完全不同。mono_tum这个example根本不认它你连main函数都进不了在LoadImages读文件列表阶段就会返回-1。注意数据集和工程路径都不要放在中文目录、不要放在桌面的网盘同步目录ORB-SLAM2的文件读取对非ASCII路径支持极差后面第五章会具体说明。4.2 改mono_tum.cpp里的三个路径参数ORB-SLAM2自带的mono_tum例子main函数开头用argc判断参数数量小于4就打印用法退出。它需要的三个参数是词典文件、相机标定yaml、数据集序列路径。我建议直接在源码里写死避免每次敲错反斜杠// Examples/Monocular/mono_tum.cpp int main(int argc, char **argv) { // 这三个路径改成你自己的绝对路径统一用正斜杠 string vocabFile D:/ORB_SLAM2/Vocabulary/ORBvoc.txt; string settingsFile D:/ORB_SLAM2/Examples/Monocular/TUM1.yaml; string sequencePath D:/datasets/rgbd_dataset_freiburg1_desk; // 原代码的argc逻辑保留做兜底命令行参数优先 if (argc 1) vocabFile argv[1]; if (argc 2) settingsFile argv[2]; if (argc 3) sequencePath argv[3]; // 后面的LoadImages(...)不用改 }这段代码的逻辑说明用if (argc 1)做覆盖既保留命令行自由度又能在IDE里直接F5跑。路径统一用正斜杠的原因是C字符串里反斜杠是转义符写F:\dataset\rgb实际得到的是F:、换行、dataset、回车、rgb的混合串文件系统根本找不到这个路径。相机标定文件TUM1.yaml里面写的是fx、fy、cx、cy和畸变系数对应freiburg1相机的内参。如果你换用freiburg2序列这里要换成TUM2.yaml否则建出来的图是弯的回环检测很难触发。运行前确认yaml里的Camera.fps是30和数据集采集帧率一致不一致时Tracking线程会丢失跟踪。4.3 运行与预期输出从加载词典到弹出Pangolin窗口编译并运行# 在ORB_SLAM2/build目录下进入对应配置的输出目录 cd build/Examples/Monocular/Release ./mono_tum.exe D:/ORB_SLAM2/Vocabulary/ORBvoc.txt D:/ORB_SLAM2/Examples/Monocular/TUM1.yaml D:/datasets/rgbd_dataset_freiburg1_desk运行后正常日志分三个阶段。第一阶段毫秒内打印Loading ORB Vocabulary...几秒钟加载完毕说明DBoW2词袋库正常。第二阶段控制台每处理一帧打印当前关键帧序号和地图点数量同时弹出一个Pangolin窗口里面是相机轨迹和稀疏点云。第三阶段跑完所有图像后ORB-SLAM2自动把轨迹写到KeyFrameTrajectory.txt最后一行显示总处理帧数。注意如果运行到二三十帧时窗口黑屏或卡住先别急着杀进程——它可能只是短暂丢失跟踪。观察日志里有没有Tracking lost字样有的话检查标定yaml的fx、fy值以及运行前是否把OpenCV的release版dll放进了PATH。4.4 怎么看建图结果点云、轨迹和漂移的判别当窗口出现第一块稀疏点云时不要只看有没有图要看三个指标。第一点云是否在桌面边缘形成连续平面如果点像碎渣一样飞散在相机正前方多半是标定焦距错了第二轨迹线在相机回到原点时有没有闭合闭合代表回环检测成功这是LoopClosing线程在起作用第三右侧的关键帧列表是否匀速增长如果每帧都新建关键帧说明ORB特征质量差或帧间运动太快调大yaml里ORBextractor.nFeatures参数默认2000可以提到3000。跑完发现KeyFrameTrajectory.txt的帧数比数据集总帧数少很多是正常的——SLAM只保存关键帧。想量化验证精度用TUM官网的评价工具python evaluate_ate.py groundtruth.txt KeyFrameTrajectory.txt --plot ate.pngATE中位数小于5cm这个ORB-SLAM实验就算真正成立如果大于20cm先排查标定和帧率而不是怀疑算法本身。5. 避坑实录五个让新手劝退的Windows编译运行问题这一章我把实际踩过和帮别人排查过的五条最具代表性的问题写出来按现象→原因→解决的顺序你在Windows上撞到的报错基本逃不出这五个圈子。5.1 Debug/Release错配第11帧必崩的玄学现象项目用VS打开后没切配置默认Debug编译能过运行到大约第11帧或LocalMapping Thread启动时报错信息是Unhandled exception at 0x... Microsoft C exception: cv::Exception甚至直接访问冲突。原因ORB-SLAM2的依赖库全用Release构建而主工程用Debug运行时STL容器和OpenCV Mat内部的内存布局会因_DEBUG宏产生变化。更致命的是DBoW2里的vector和unordered_map在Debug下迭代器尺寸不同Tracking线程往局部地图里插入点时踩坏邻接内存。这不是你代码的问题是MSVC下Debug和Release的ABI不兼容。解决整个依赖链统一用Release。VS顶部配置管理器切成Release确认OpenCV链接的是opencv_world410.lib而不是opencv_world410d.libPangolin的vcpkg包也要确认不是x64-windows-debug。如果项目里有人改过/Fd、/Z7这类调试信息参数也可能在Release下触发类似问题保持默认即可。5.2 DLL加载乱序找不到或无法定位程序输入点现象exe能启动几毫秒后弹窗找不到opencv_world410.dll或者系统里明明有OpenCV却提示无法定位程序输入点xxx于动态链接库opencv_world410.dll。原因Windows加载dll的顺序是exe目录→系统目录→PATH而不是你最近装的OpenCV优先。机器上如果装过Anaconda、ROS2、或任何自带OpenCV的软件它们的dll很可能先被加载版本和ORB-SLAM2编译期用的接口对不上就会报输入点找不到。解决把你自己那份OpenCV的build/x64/vc15/bin放到PATH最前面并确认在VS里调试时用的环境变量是PATHD:\opencv\build\x64\vc15\bin;%PATH%。最彻底的做法是运行时把opencv_world410.dll、Pangolin的dll直接复制到exe同目录这样机器上其他软件带的OpenCV就再也干扰不到你。5.3 反斜杠路径和中文目录读数据集时静默丢帧现象数据集放在类似F:\数据集\桌面的路径下编译和运行都正常控制台日志也在推进但Pangolin窗口里只有零散几个点云像被抽了帧或者卡在Find the any hit in the region不动。原因ORB-SLAM2里的cv::glob和文件流对非ASCII路径支持极差中文目录在高版本OpenCV下可能匹配出乱码文件名imread返回空MatSLAM把空帧当成正常帧跳过。反斜杠路径则是C转义把路径截断。解决数据集和工程一律放纯英文路径比如D:\ORB_SLAM2、D:\datasets代码里的路径统一用正斜杠——Windows的文件API和OpenCV都接受正斜杠唯独字符串转义不接受。排查这类问题最快的办法是在System.cc的LoadImageSequence里打印拼接后的完整路径看实际去读的是哪个文件。5.4 imread进灰度断言崩溃通道类型没有钉死现象运行到某帧控制台弹断言失败assertion failed (src.channels() 1 || src.channels() 3 || src.channels() 4) in cv::cvtColor或直接崩在OpenCV的mat.inl.cpp。原因ORB-SLAM2的Tracking接口要求输入灰度图CV_8UC1有人把RGB图直接喂进TrackMonocular或者数据集的png本身是三通道但bgr顺序和预期不一致。真正的原因是读取后的Mat没有统一转成灰阶就往下走。解决喂给TrackMonocular之前加一行转换加判空cv::Mat gray; cv::cvtColor(colorFrame, gray, cv::COLOR_BGR2GRAY); if (gray.empty()) continue;不要用image.channels()1就跳过转换的旁路老老实实每帧都转。TUM数据集的png本来就是灰度图不会触发但换成自己录的视频或摄像头流100%会崩。这段对你接实时视频流时特别有用。5.5 数据集选错拿EuRoC当TUM跑的结果现象用mono_tum去跑EuRoC数据集控制台输出Failed to open file ...cam0...然后直接退出或者跑了FLIR相机序列点云严重倾斜。原因ORB-SLAM2每个example写死了读取格式。mono_tum读TUM的rgb.txt加深度目录结构mono_euroc读EuRoC的cam0/data目录和data.csv时间戳两者的文件列表解析完全不同。把EuRoC塞给mono_tumLoadImages函数第一次fopen就返回false。解决先明确数据集属于哪个基准。TUM就用mono_tumEuRoC就用mono_euroc它的main函数需要额外传标定文件和传感时间戳文件做对齐。如果只是验证Windows编译是否成功最快的办法是下一个小序列几百MB十分钟跑完别一上来下EuRoC整包十几个GB。这个坑特别隐蔽因为它不报错只是行为异常。6. 进阶把摄像头接进去跑实时SLAM验证你的Windows链路数据集跑通只是能复现要让这个实验对你有实际价值下一步是把视频流换成你自己的摄像头。ORB-SLAM2的Examples/Monocular下有mono_webcam.cc逻辑比mono_tum更简单用cv::VideoCapture打开摄像头逐帧取图转灰度后直接送TrackMonocular。// Examples/Monocular/mono_webcam.cc 里的核心循环词典和标定加载和tum一致 cv::VideoCapture cap(0); // 0表示默认摄像头笔记本内置也是0 if (!cap.isOpened()) { std::cerr Camera open failed std::endl; return -1; } cap.set(cv::CAP_PROP_FRAME_WIDTH, 640); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 480); double timestamp 0.0; cv::Mat frame; while (cv::waitKey(1) ! q) { cap frame; if (frame.empty()) continue; cv::Mat gray; cv::cvtColor(frame, gray, cv::COLOR_BGR2GRAY); Sophus::SE3f Tcw sl.TrackMonocular(gray, timestamp); timestamp 1.0 / 30.0; // 按30fps模拟时间戳 // Tcw是当前帧相机位姿可以打印矩阵或叠加到画面 }参数说明分辨率设640x480是有意的ORB特征提取数量在更高分辨率下会翻倍低配机器容易在Tracking线程堆积帧导致SLAM跑不过实际帧率。时间戳用1/30递增是模拟真实时间有更高精度要求时用cv::getTickCount换算否则里程计累积误差会被当成真实时间差参与优化。把相机拿在手里做平移、旋转和回环动作窗口内点云应当稳定增长回环那一刻轨迹会发生一次明显跳变校正——这个现象是这个实验对你链路完整性的终极验证。我在这块吃过一个教训笔记本UVC摄像头在微信会议用完后cap.isOpened()返回true但cap frame一直给空图原因是摄像头被另一个进程独占。当时我在设备管理器里看见该设备已被占用才反应过来是软件抢了摄像头。从此我养成跑实时SLAM前先用系统相机应用确认能出画面的习惯。Windows下的ORB-SLAM实验编译只是第一关真正让人崩溃的都是这些操作系统底层的脾气——但只要你愿意一步步日志排查这条路一定能走通。希望帮到你。本文还有配套的精品资源点击获取