拓冰建站拓冰建站
首页 / 资讯中心 / 正文

Windows平台跑通ORB-SLAM3:WSL2环境搭建与实战指南

简介针对ORB-SLAM3在Windows平台难以直接编译运行的问题这份项目实战资源提供了完整的适配与优化方案面向SLAM研究者、机器人开发者以及需要快速搭建Windows端视觉SLAM环境的工程师。资源共2000个文件以840个cpp、699个h源码文件为主辅以348个txt说明文档、23个yaml配置、5个Python脚本和5个Markdown笔记等压缩包整体318.29MB。内容涵盖环境搭建、源代码配置、功能演示与接口调用等关键环节并针对跨平台内存管理、线程同步等兼容性问题给出处理思路还涉及利用多线程与GPU加速进行性能调优。配套的工程文档、代码注释和实践案例便于开发者对照验证掌握单目、双目与深度相机等多传感器配置下的算法要点。已有688人学习适合希望避开底层编译细节、在Windows下快速上手ORB-SLAM3并进行二次开发的人群。 拿到这个项目标题我得先说句实在话SLAM-适配Windows平台的ORB-SLAM3-优质项目实战.zip这种文件十有八九是各路博主打包“二次分发”的产物标题里“适配Windows”这几个字最容易让人误判。真正的问题从来不是“能不能解压”而是“解压之后怎么把ORB-SLAM3跑起来”。ORB-SLAM3本身是Linux生态下的项目Windows上直接编译光是依赖库就能把人劝退。这篇博文我就按自己的实操经验把从环境准备、源码编译、数据集测试到轨迹评估的完整链路拆开讲一遍帮你绕开我踩过的那些坑。整个过程我实测过的路线是WSL2 Ubuntu 20.04 OpenCV 4.2 Eigen 3.3 修改过的ORB-SLAM3源码编译单目和双目示例跑EUROC数据集最后用evo做轨迹评估。这套组合目前是最稳的也最贴近“项目实战”这四个字的真实需求。内容偏工程向适合正在复现ORB-SLAM3、卡在编译或运行环节的读者新手也能照着一步步操作。1. 为什么说“Windows版ORB-SLAM3”是个伪命题1.1 项目标题背后的真实需求看到标题里带“Windows平台”很多人的第一反应是“下载下来双击就能用”。但ORB-SLAM3不是那种开箱即用的软件它是一套C源码需要你自己编译、自己准备数据集、自己调参数。所谓“适配Windows”本质上是作者把原本面向Linux的代码做了一些移植比如处理了时间戳函数、文件系统依赖、部分CMake配置但核心的三方库依赖DBoW2、g2o、Sophus、Pangolin依然保留了Linux的惯性。所以你在Windows上跑ORB-SLAM3真正的需求不是“找到一个Windows版”而是“搭建一套能在Windows环境下运行Linux依赖的工具链”。这个需求有两个解法第一纯原生Windows编译用Visual Studio vcpkg硬啃第二用WSL2Windows Subsystem for Linux 2搭一个轻量Linux环境在Linux环境里编译运行。1.2 两条路线的取舍我两种方案都试过。原生Windows方案你要面对的是Pangolin依赖OpenGL和GLEWDBoW2需要Boostg2o需要一堆线性代数库每一个库都要用vcpkg或手动编译版本稍微不对就链接失败。而且ORB-SLAM3源码里大量使用了usleep、unistd.h这类POSIX接口Windows下要么改代码要么用兼容层。折腾一整天的结果往往是在链接阶段报几百个error。WSL2方案就简单得多。它在Windows里虚拟了一个完整Linux内核对ORB-SLAM3来说这就等于在标准Ubuntu环境里编译所有依赖问题都可以用apt-get解决运行性能损失可以忽略不计。再说直白点你真正需要的是把SLAM算法跑起来看效果不是跟编译器较劲。提示如果你非要在原生Windows上跑建议不要碰vcpkg直接用MSYS2 mingw-w64配合pacman装依赖踩坑率低不少。但后续运行时的OpenCV、Pangolin路径配置依然繁琐新手不建议尝试。2. 环境准备版本选择比安装动作更重要2.1 系统与依赖版本锁定ORB-SLAM3的依赖版本特别敏感我推荐下面这套组合实测下来编译最顺组件推荐版本说明系统Ubuntu 20.04WSL2对应gcc 9CMake 3.16兼容性最好OpenCV4.2.03.4.x也能跑但特征提取速度稍慢Eigen3.3.73.4有兼容性问题不建议追新Pangolinv0.6用于可视化和UI依赖OpenGLDBoW2/g2o/SophusORB-SLAM3自带在Thirdparty目录下单独编译为什么不能全都装最新版因为ORB-SLAM3的代码在2021年后基本停止大改当时适配的库版本就停留在那个阶段。Eigen 3.4改了部分头文件目录结构会直接导致Eigen/Core找不到OpenCV 4.5引入了新的cv::Mat类型检查部分老接口会被标记为deprecated编译能过但运行时会触发断言。所以这里请务必备份旧版本不要手贱升级。2.2 WSL2环境下的关键操作首先确保你的Windows开启了WSL2并安装Ubuntu 20.04# 在Windows PowerShell管理员中执行 wsl --install -d Ubuntu-20.04进入WSL后先换源再装基础工具链sudo apt update sudo apt upgrade -y sudo apt install -y build-essential cmake git pkg-config \ libglew-dev libglfw3-dev libgl1-mesa-dev libglu1-mesa-dev \ libeigen3-dev libboost-all-dev libssl-dev \ libopencv-dev python3-pip这一步把CMake、GCC、OpenCV、Eigen、GLEW、GLFW一次性装齐。需要注意apt默认安装的OpenCV版本在Ubuntu 20.04是4.2正好符合需求不用再自己编译。Eigen默认版本是3.3.7也刚好卡在兼容区间。这就是我强烈推荐20.04的原因——它自带的依赖版本和ORB-SLAM3年代完全吻合。2.3 Pangolin单独编译Pangolin是可视化窗口库编译顺序要在ORB-SLAM3之前完成git clone -b v0.6 https://github.com/stevenlovegrove/Pangolin.git cd Pangolin mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j$(nproc) sudo make install如果编译过程中报OpenGL相关错误检查一下libgl1-mesa-dev和libglew-dev是否装好。WSL2本身支持GUI显示但默认没有X Server你需要额外配置WSLg或者安装VcXsrv。Windows 11的WSLg可以直接显示GUI窗口Windows 10用户建议装VcXsrv然后用export DISPLAY$(grep nameserver /etc/resolv.conf | awk {print $2}):0.0设置显示环境。注意编译Pangolin时-j$(nproc)会把所有CPU核心都拉满WSL2默认分配的内存如果小于8GB建议改成make -j4否则容易OOM导致编译进程被杀。3. 源码编译从报错到跑通的完整记录3.1 源码准备与必要修改解压项目包到WSL里有个细节直接用Windows资源管理器右键解压会导致文件权限错乱部分可执行脚本失去执行权限。建议把zip拷贝到WSL后用命令行解压cd ~ unzip SLAM-适配Windows平台的ORB-SLAM3-优质项目实战.zip -d orbslam3 cd orbslam3 chmod x build.sh源码目录里的build.sh脚本不能直接执行因为原项目为Linux设计会默认使用nproc并编译所有示例。建议先手动编译三个第三方库cd Thirdparty/DBoW2 mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4 cd ../../g2o mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4 cd ../../Sophus mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4如果项目包里的第三方库不完整就用ORB-SLAM3官方GitHub仓库里的对应目录替代。这一步的核心目的是生成各自的.so库文件后续ORB-SLAM3主程序链接时需要。3.2 修改源码中的平台兼容代码即使是“适配Windows”的项目包以下几处代码仍需要手动改否则编译或运行到一半会崩溃第一处src/System.cc里的时间戳获取。原代码用的是std::chrono::system_clock::now().time_since_epoch().count()在不同系统上返回的精度单位不一致建议统一改成// 在System.cc中找到类似代码 auto now std::chrono::duration_caststd::chrono::milliseconds( std::chrono::system_clock::now().time_since_epoch()).count();第二处Examples/Monocular/mono_euroc.cc里的usleep(5000)。直接改成std::this_thread::sleep_for(std::chrono::milliseconds(5))需要在文件头部加#include thread和#include chrono。第三处CMakeLists.txt里的-marchnative编译选项。WSL2的虚拟CPU指令集可能和本机不完全一致-marchnative会导致非法指令错误建议全部替换为-marchx86-64。3.3 编译ORB-SLAM3主程序修改完成后在主目录下执行mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease \ -DCMAKE_PREFIX_PATH/usr/local/lib/cmake/Pangolin make -j4编译时间取决于机器性能一般10到20分钟。如果报找不到PangolinConfig.cmake说明Pangolin安装路径不对用sudo find / -name PangolinConfig.cmake 2/dev/null确认实际路径再通过CMAKE_PREFIX_PATH指定。编译成功后build/Examples/Monocular目录下会生成mono_euroc等可执行文件。到这里ORB-SLAM3的编译阶段就算完成了接下来进入真实数据和调参环节。4. 运行实测用EUROC数据集验证建图效果4.1 数据集准备与格式检查ORB-SLAM3单目测试最常用的是EUROC数据集里面有MH机器大厅和V室外系列。下载MH_01_easy的Machine Hall 01压缩包解压后你会看到mav0/cam0/data和mav0/cam1/data两个目录里面是灰度图还有一个state_groundtruth_estimate0/data.csv这是评估用的真值轨迹。下载完成后把数据集放到~/Datasets/MH01下。注意数据集路径不能有中文WSL默认挂载/mnt/c下的Windows盘直接把数据集放在Windows桌面会导致IO性能下降加载图片速度慢得离谱强烈建议放到Linux文件系统内部。4.2 修改单目配置文件运行前需要检查Examples/Monocular/EuRoC.yaml里的相机参数是否和数据集匹配。EUROC的官方参数如下Camera.fx: 458.654 Camera.fy: 457.296 Camera.cx: 367.215 Camera.cy: 248.375 Camera.k1: -0.28340811 Camera.k2: 0.07395907 Camera.p1: 0.00019359 Camera.p2: 1.76187114e-05这些参数已经被官方写入yaml一般不需要改。但有一个参数很关键ORBextractor.nFeatures默认是2000。如果数据集分辨率是752x4802000个特征点勉强够用如果换成更高分辨率的自制数据集这里至少要调到3000以上否则初始化阶段经常失败。4.3 运行单目示例cd ~/orbslam3/build/Examples/Monocular ./mono_euroc ../../../Vocabulary/ORBvoc.txt \ ../../../Examples/Monocular/EuRoC.yaml \ ~/Datasets/MH01/mav0/cam0/data \ ~/Datasets/MH01/mav0/cam0/timestamp.csv运行后会出现Pangolin窗口显示当前帧的特征点和地图点。如果一切正常几秒钟内就能看到相机位姿轨迹在窗口中慢慢生长。窗口左上角显示当前跟踪状态OK表示正常LOST表示跟踪丢失。MH_01序列光照稳定、纹理丰富基本不会丢。程序结束后终端会打印一段轨迹评估统计包括ATE的RMSE、均值和中位数。RMSE在0.1米以内说明代码运行正确如果超过0.3米大概率是数据集时间戳对齐问题下面会专门说。4.4 用evo工具做轨迹精度评估很多人忽略这一步但SLAM算法复现的评判标准就是轨迹精度量化对比才有说服力。evo是目前最常用的SLAM轨迹评估工具pip install evo --upgrade --no-binary evo运行mono_euroc时加一个参数-t或者直接把真值轨迹和估计轨迹导出到tum格式./mono_euroc ... -t evo_ape tum groundtruth.txt KeyFrameTrajectory.txt -a -p-a表示自动对齐消除坐标系基准差异-p画出误差曲线。evo的输出结果里ATE RMSE是最核心的指标它代表估计轨迹和真实轨迹之间的距离误差单位是米。我实测MH_01单目模式大约在0.06到0.12米之间这个精度对单目视觉SLAM来说已经相当能打。5. 常见问题与排错实战5.1 编译期问题速查报错内容根因解决方法fatal error: Eigen/Core: No such file or directoryEigen版本过高或未安装执行sudo apt install libeigen3-dev确认版本3.3.xcannot find -lPangolinPangolin未安装或路径不对用find / -name libpangolin*查到路径后在CMakeLists里加link_directories链接时报一堆undefined reference to cv::...OpenCV版本混用编译和链接版本不一致统一用apt的OpenCV 4.2pkg-config --modversion opencv4检查internal compiler error内存不足降低make -j并行数或者给WSL2增加内存上限5.2 运行时崩溃和跟踪失败最常见的是程序一跑就段错误Segmentation fault。90%的情况是时间戳文件格式不对EUROC的timestamp.csv文件末尾有Linux换行符\n如果项目包在Windows下被改过换行符为\r\n程序读取时会解析失败导致推入的图像时间戳全部为0进入死循环。解决方法用dos2unix转换时间戳文件sudo apt install dos2unix dos2unix ~/Datasets/MH01/mav0/cam0/timestamp.csv如果单目前几帧就报not enough features说明场景特征太少或者初始帧视野太窄。可以尝试把EuRoC.yaml里的ORBextractor.nFeatures调高或者从数据集的不同时间点开始跑。5.3 关于las数据格式的延伸SLAM建图常见任务里很多人会拿室内或移动扫描的激光数据去和视觉SLAM结果比较这里就绕不开las格式。Las是激光雷达点云的行业标准格式ORB-SLAM3输出的KeyFrameTrajectory.txt是轨迹不是点云如果你用ORB-SLAM3保存的稠密或稀疏地图想转成las一般需要借助PCL库做格式转换。至于“CAD能不能打开las”结论是原生的AutoCAD打不开需要装点云处理插件或者先用CloudCompare、QGIS这类专业工具把las转成CAD支持的格式。Visual SLAM出的点云大多数情况量级在百万级以下CloudCompare足够应付不用上重型软件。5.4 跑通之后的下一步建议能把EUROC的MH01跑通说明整个工具链已经通了。接下来建议你换MH_03试试它的光照变化和运动轨迹更复杂能检验算法在退化场景下的表现。再往下可以接自己的摄像头把mono_euroc换成mono_tum或mono_kitti只需要改相机内参和图像输入部分动作不大但成就感很强。踩过这么多次坑之后我的体会是复现ORB-SLAM3这类经典视觉SLAM项目最难的不是算法本身而是“让代码在新的平台上跑起来”这层工程壁垒。依赖版本锁死、时间戳格式、编译参数这三个细节抓好了项目基本就成功了大半。这个zip包里的内容实际上只是起点把原理吃透、数据集测透、评估做透才算真正把SLAM实战玩明白。本文还有配套的精品资源点击获取
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门