简介视觉SLAMVisual SLAM是机器人自主定位与建图的核心技术而ORB-SLAM2作为经典开源方案被广泛用于单目相机运动轨迹恢复。要让它准确运行输入数据的规范性比算法调参更关键——图片序列必须时序连续、时间戳对齐、相机内参精确否则即使能编译通过也会初始化失败或轨迹漂移。本文以工程实践为导向系统性讲解如何将自采图片整理成ORB-SLAM2可直接消费的数据集从目录命名、时间戳生成、棋盘格标定到YAML配置修改、编译运行再到用EVO评估轨迹精度并结合弱纹理、动态物体、高分辨率等真实场景的避坑经验。无论你是想用手机或工业相机自建SLAM数据集还是准备落地视觉定位应用掌握这套数据规范化流程就能让ORB-SLAM2稳定输出可用轨迹。1. 用ORB-SLAM2跑自己的图片序列先搞懂它到底要什么很多第一次接触ORB-SLAM2的开发者手里已经攒了一堆自己拍的图片比如用手机、工业相机或无人机按固定频率拍下来的连续帧然后兴冲冲地打开官方Demo发现跑KITTI、TUM都能出轨迹换成自己的图片序列却直接初始化失败甚至根本读不进去。这个现象太常见了原因不是ORB-SLAM2有多难而是它对自己的输入格式有着非常隐性的要求图片必须按时序连续、时间戳必须对齐、相机内参必须准确甚至图片的命名排序都必须能被它的读取逻辑识别。本文要解决的问题就是把你手里那堆“散装图片”变成一个ORB-SLAM2能直接吃进去、还能跑出可用轨迹的序列数据集并且把每一步的配置、参数和常见坑讲透。适合的人群是已经能编译ORB-SLAM2但换数据就翻车的入门者以及准备自采数据做建图或定位、但还没摸清数据规范的从业者。2. 从零准备自己的图片序列数据集格式、命名与时间戳2.1 图片序列的目录结构与命名规范ORB-SLAM2官方示例中TUM数据集用rgb/目录存放彩色图KITTI用image_0/和image_1/存放灰度图EuRoC用cam0/、cam1/存放灰度图。跑自己的序列时最简单可靠的做法就是照搬TUM的目录结构一个父目录下放一个rgb/文件夹里面是连续命名的图片文件父目录里再放一个rgb.txt时间戳文件。命名规则我强烈建议使用纯数字、固定位数补零比如000001.png、000002.png不要用frame1.jpg、frame2.jpg这种混排因为ORB-SLAM2的读取器按文件名排序如果位数不齐frame10.png会排在frame2.png前面直接打乱时序。如果你的图片是相机采集软件生成的比如img-20250101-153020.png这种带日期时间的名字也能跑但必须先统一重命名。常见做法是用Python脚本按文件修改时间排序后重新编号确保序列顺序和拍摄顺序一致。目录结构最终要长这样my_sequence/ ├── rgb/ │ ├── 000001.png │ ├── 000002.png │ ├── 000003.png │ └── ... └── rgb.txt# 把当前目录下所有jpg按时间排序并重命名为6位数字 ls -1 *.jpg | awk {printf mv %s %06d.jpg\n, $0, NR} | bash这段脚本的核心是ls -1按字典序输出文件名然后awk生成重命名命令最后交给bash执行。注意ls的字典序对10.jpg排在2.jpg后面这个问题无力解决所以你的原始文件名必须是类似IMG_0001.jpg这类能按字典序排序的格式否则先把它们改名为纯数字再跑。参数说明%06d是6位补零如果你有超过10万帧改成%08d。2.2 时间戳文件TUM格式与EuRoC格式怎么选时间戳文件是ORB-SLAM2能否正确计算轨迹的命脉。单目SLAM本身不依赖绝对时间戳但轨迹对齐和速度估计需要相对时间。TUM格式的rgb.txt每行是时间戳 图片路径时间戳单位是秒可以是浮点数比如1698561234.123456 rgb/000001.png。EuRoC格式则是时间戳, 图片名逗号分隔而且图片直接放在cam0下不带路径前缀。跑自己的序列我建议用TUM格式因为mono_tum示例的读取代码最直观而且后面用EVO评估轨迹时需要TUM格式的ground truth或时间戳前缀。获取时间戳的方式取决于你的图像来源。如果是工业相机SDK采集通常时间戳是相机硬件触发的时间如果是手机或普通摄像头用Python的time.time()在读取帧的同时记录即可。关键是时间戳必须单调递增而且相邻时间戳的差值要基本等于你真实采集帧率。比如你用30fps采集那么时间戳间隔应在0.033秒附近波动如果某两帧间隔突然变成0.5秒SLAM的匀速运动假设就会失效。import time import os rgb_dir rgb ts_file rgb.txt with open(ts_file, w) as f: for img_name in sorted(os.listdir(rgb_dir)): # 这里假设每帧采集间隔约0.033秒实际用你相机的时间戳 ts time.time() # 示例用当前时间实际项目从采集端读取 f.write(f{ts:.6f} {rgb_dir}/{img_name}\n) time.sleep(0.001) # 避免同一秒内写入过快仅测试用这段脚本帮你从已有的rgb/目录生成rgb.txt但注意time.time()是脚本运行时刻不是采集时刻。如果你采集时没存时间戳这里就会埋下一个大坑相邻帧时间差是随机的ORB-SLAM2视图几何会算出乱跳的速度轨迹会严重漂移。所以务必在采集端同步记录时间戳或者用视频文件FFmpeg抽帧时保留帧PTS显示时间戳。2.3 相机标定参数内参矩阵、畸变系数与尺度问题ORB-SLAM2的配置文件里需要填写相机内参和畸变系数它不会自动标定。常见的错误是直接拿手机厂商给的等效焦距去填结果跑出来轨迹扭曲。正确做法是先用棋盘格标定推荐用OpenCV的calibrateCamera买一张A4纸大小的棋盘格打印出来从不同角度拍20~30张注意保证棋盘格在画面中占据1/4以上面积且角度覆盖倾斜、左右旋转。标定得到的内参是fx, fy, cx, cy畸变是k1, k2, p1, p2, k3。ORB-SLAM2的配置文件用的是畸变模型Pinhole或KannalaBrandt8普通针孔相机就选Pinhole。还有一个关键点ORB-SLAM2默认设置Camera.horizontal_fov和Camera.vertical_fov只用于可视化不影响算法但如果设置得离谱会导致虚拟相机显示异常建议按真实FOV填。import cv2 import numpy as np # 用OpenCV棋盘格标定这里只给出核心代码 criteria (cv2.TERM_CRITERIA_EPS cv2.TERM_CRITERIA_MAX_ITER, 30, 0.001) objp np.zeros((6*9, 3), np.float32) objp[:, :2] np.mgrid[0:9, 0:6].T.reshape(-1, 2) objpoints [] imgpoints [] for fname in glob.glob(calib/*.jpg): img cv2.imread(fname) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) ret, corners cv2.findChessboardCorners(gray, (9, 6), None) if ret: objpoints.append(objp) corners2 cv2.cornerSubPix(gray, corners, (11, 11), (-1, -1), criteria) imgpoints.append(corners2) ret, mtx, dist, rvecs, tvecs cv2.calibrateCamera(objpoints, imgpoints, gray.shape[::-1], None, None) print(内参矩阵:\n, mtx) print(畸变系数:, dist.ravel())这里的objp是世界坐标系中的角点坐标findChessboardCorners找角点calibrateCamera求解内参。特别提醒标定板的行列数必须与代码中(9,6)一致而且采集图片时务必让棋盘格覆盖图像四角和中心否则畸变参数会非常不准。另外单目SLAM的轨迹尺度是未知的ORB-SLAM2默认输出的轨迹尺度任意它把第一帧的深度归一化到某个随机值。如果后续要建图或测量必须用已知尺寸的物体标定尺度这一步放到后面进阶章讲。3. 修改配置文件并编译运行让ORB-SLAM2吃下你的数据3.1 配置文件yaml的关键字段与参数含义ORB-SLAM2的配置文件是一个YAML文件类似TUM的TUM1.yaml这样的格式。复制一份现有配置文件改参数是最稳妥的不要从零写。你需要改的字段至少有字段含义推荐值Camera.type相机模型PinHole或KannalaBrandt8普通相机填PinHoleCamera.fx, Camera.fy焦距像素标定结果对应值Camera.cx, Camera.cy主点坐标标定结果对应值Camera.k1, k2, p1, p2畸变系数标定结果未标定填0但效果差Camera.fps采集帧率30或你的真实值影响初始化窗口判断Camera.rows, Camera.cols图像分辨率640x480或1920x1080等ORBextractor.nFeatures每帧提取的特征点数默认1000弱纹理场景可提到2000Viewer.Viewer可视化开关设为1服务器无显示器可设为0ThDepth深度阈值单目无效默认35单目下忽略注意Camera.fps只用于ORB-SLAM2内部估计相机运动时的正则化如果填错特征点三角化的深度范围判断会出错。另外还有一个隐藏字段ORBextractor.scaleFactor默认1.2表示图像金字塔每层缩放比例如果你拍的是大视角变化场景需要调小到1.1否则特征点尺度匹配失败。3.2 编译ORB-SLAM2的完整命令与常见依赖问题编译ORB-SLAM2是许多人卡住的第一道坎但其实是标准的CMake流程。依赖项包括Eigen3、OpenCV、Pangolin、DBoW2和g2o等第三方库。在Ubuntu 20.04上OpenCV默认4.2而ORB-SLAM2源码较老会有API不兼容问题最常见的是CV_LOAD_IMAGE_UNCHANGED变成了cv::IMREAD_UNCHANGED。遇到这个报错直接全局搜索替换即可。# 安装基础依赖 sudo apt install build-essential cmake libeigen3-dev libgtk2.0-dev pkg-config sudo apt install libopencv-dev libboost-all-dev libssl-dev # 编译第三方库 cd ORB_SLAM2/Thirdparty/DBoW2 mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j8 cd ../../g2o mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j8 cd ../../Pangolin mkdir build cd build cmake .. make -j8 # 编译主程序 cd ../../.. mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j8参数说明-j8是并行编译核数如果你的机器是4核改成-j4否则内存不够会卡死。CMAKE_BUILD_TYPERelease必须写Debug模式下ORB-SLAM2的特征提取慢好几个数量级。如果编译过程中提示找不到OpenCV检查CMakeLists.txt里的find_package(OpenCV REQUIRED)是否找到了你的OpenCV版本或者手改OpenCV_DIR指向你的安装路径。还有一个容易忽视的点ORB-SLAM2自带的libORB_SLAM2.so会链接OpenCV 3.x如果你系统装的是4.x务必在CMakeLists.txt里把OpenCV那几行的版本兼容注释掉否则运行时会报符号找不到。3.3 用mono_tum和mono_kitti跑通自己的序列ORB-SLAM2官方提供了单目TUM示例这是跑自己序列最直接入口。命令格式是./Examples/Monocular/mono_tum \ Vocabulary/ORBvoc.txt \ Examples/Monocular/TUM1.yaml \ /path/to/my_sequence \ /path/to/output/trajectory.txt四个参数分别是词袋文件、配置文件、数据集目录、轨迹输出文件。运行后终端会打印初始化关键帧数量、局部建图线程状态等。如果正确初始化几秒后会弹出两个窗口一个显示当前帧的特征点和跟踪状态蓝色为跟踪成功红色为丢失另一个显示稀疏点云地图。如果你手中的图片是灰度单目但时间戳是EuRoC格式逗号分隔就用官方mono_euroc示例。它的参数不同第一个参数是Vocabulary/ORBvoc.txt第二个是配置文件第三个是数据集的mav0/cam0目录第四个是时间戳文件data.csv。这个示例要求配置文件里设置Camera.type: PinHole且Camera.fps为20EuRoC默认如果你自己的数据是30fps必须把yaml改掉再跑否则轨迹时间轴错位。# 用mono_euroc跑EuRoC格式数据 ./Examples/Monocular/mono_euroc \ Vocabulary/ORBvoc.txt \ Examples/Monocular/EuRoC.yaml \ /path/to/my_sequence/mav0 \ /path/to/my_sequence/mav0/cam0/data.csv \ /path/to/output/trajectory.txt跑通后第一件事是看终端输出的Saving trajectory to...以及每帧跟踪的耗时tracking time。如果每帧耗时超过30ms说明你的机器实时性不足或分辨率太高建议先降到VGA分辨率和灰度图再跑。4. 跑通之后必做的验证轨迹、地图与数值怎么看4.1 输出的轨迹文件与关键帧文件解读ORB-SLAM2默认会输出三个文件运行时不带后缀的除了指定轨迹还会保存KeyFrameTrajectory.txt和CameraTrajectory.txt具体取决于你eval脚本的参数。其中KeyFrameTrajectory.txt每行是时间戳 tx ty tz qx qy qz qw这个7个数是TUM格式的标准轨迹。ORB-SLAM2单目输出的轨迹尺度是任意的也就是说tx, ty, tz的数值不代表真实的米制坐标。怎么判断轨迹是否可用把它拖进EVO或我下面写的脚本里看形状如果是一个来回运动的轨迹但终点和起点重合度差很多说明跟踪中途丢失或尺度漂移。另一个验证点是关键帧的数量。如果你跑了5000张图关键帧只有50个说明大部分帧被判定为冗余这通常会出现在相机原地旋转或静止的场景。反之如果关键帧数量超过总帧数的三分之一说明图像内容和相机运动变化太剧烈局部地图频繁更新轨迹容易抖动。# 简单读取KeyFrameTrajectory.txt并检查尺度连续性 import numpy as np traj np.loadtxt(KeyFrameTrajectory.txt) ts traj[:, 0] pos traj[:, 1:4] dist np.linalg.norm(np.diff(pos, axis0), axis1) print(连续关键帧间距中位数:, np.median(dist)) print(间距标准差:, np.std(dist))这段脚本看相邻关键帧位移的统计特性。如果中位数接近0且标准差很小说明相机基本没动如果出现几个异常大的间距说明中间可能跳变跟踪丢失后重定位。正常的视觉SLAM轨迹应该是位移平滑且非零的除非你拍的场景是近乎静态的。4.2 用EVO评估轨迹误差的实用命令EVO是评估SLAM轨迹的常用工具支持TUM和EuRoC格式。它能帮你算出ATE绝对轨迹误差和RPE相对位姿误差。跑完ORB-SLAM2之后用EVO和你的真值轨迹做对比但注意单目轨迹尺度任意直接对比意义不大要用--align --correct_scale做Sim(3)对齐。# 安装EVO pip install evo # 评估单目轨迹假设你有一个groundtruth.txt evo_ape tum KeyFrameTrajectory.txt groundtruth.txt --align --correct_scale -a--align是做SE(3)对齐--correct_scale是修正尺度。如果对齐后的ATE RMSE小于0.1米说明轨迹精度很好如果大于0.5米基本是跟踪丢失或相机内参不准。注意EVO要求两个轨迹的时间戳必须对齐它会按时间戳插值。如果你的rgb.txt时间和真值时间戳不是同一时钟需要先手动同步。如果没有真值怎么验证轨迹是否可信一个简单方法是“闭环检测”。在采集数据时让相机绕一圈回到起点附近如果ORB-SLAM2检测到闭环终端会打印Loop detected!且地图窗口里会看到点云被拉回原位置。如果你故意绕圈但没检测到闭环说明你的特征点不足或场景重复度不够这时候轨迹的漂移是没法修正的。4.3 可视化检查点云地图和轨迹截图怎么判断成功打开ORB-SLAM2的可视化窗口除了看当前视图更重要的是看地图窗口中的点云形状。一个可靠的单目地图应该呈现出与真实场景一致的结构走廊是长长的点墙房间是闭合的四面点壁。如果你看到点云呈螺旋状或者堆成一团说明尺度漂移严重通常发生在相机快速旋转或场景缺乏深度的区域。还有一个直观验证让相机对着纹理丰富的墙面做小幅度平移地图点应该随相机运动形成连续不平整的面。如果点云像雪花一样散乱大概率是ORB特征提取器没有正确的特征响应可以检查配置里的ORBextractor.nFeatures是否太低或者图像是否过亮过暗。# 保存轨迹并绘制二维俯视图用Python快速画一下 import matplotlib.pyplot as plt plt.plot(pos[:, 0], pos[:, 2], linewidth1) plt.axis(equal) plt.savefig(traj_topdown.png)画出来的轨迹图应当是平滑曲线没有尖角突刺。如果出现折线甚至交叉乱线找对应时间点附近的图片检查是否有强烈的运动模糊或遮挡。5. 避坑ORB-SLAM2跑自建数据集最常翻车的6个地方5.1 图片时间戳是乱序的轨迹直接起飞现象跑出来的轨迹在起点附近反复跳跃甚至绘制成“8”字形乱飞。原因rgb.txt里的时间戳不是按照拍摄顺序写的比如采集时一次批量转了手机连拍图片时间戳用了文件修改时间但文件系统在拷贝过程中把mtime全改成了当前时间导致所有帧的时间戳几乎相同或顺序错乱。解决采集时就要在拍摄程序里同步记录时间戳如果已经丢了时间戳只能按照文件命名顺序伪造一个递增序列。这种方法能跑通但轨迹的时间信息是假的不能用于和外部传感器做融合。5.2 内参错误导致初始化失败或者尺度异常现象程序一直打印Not enough matches或Cannot initialize mono初始化需要好几秒才能通过甚至永远不过。原因相机内参里fx和fy填反了或者cx, cy用了裁剪前的大分辨率。很多手机相机输出的图像已经经过裁剪和缩放直接拿标定软件输出的原始分辨率填进去画面中心和主点差很多。解决标定之后一定要用undistort验证。标定得到的映射能使棋盘格中的直线变直否则标定图本身有问题。另外ORB-SLAM2的分辨率必须和yaml里的rows/cols一致如果你在采集后缩放过图片fx, fy, cx, cy也要等比缩放。5.3 单目尺度是玄学轨迹看起来对但实际大小全错现象输出轨迹形状正确但画出来发现沿x方向移动了10单位的路径实际测量只有5米。原因单目SLAM本身没有尺度信息ORB-SLAM2初始化的基础矩阵求出来的平移量是归一化的尺度由地图点深度决定。标准输出就是任意尺度不算bug。解决如果你需要真实尺度可以在初始化成功后测量一个已知长度物体的点云距离计算缩放因子。更工程化的做法是用双目或RGB-D相机或者在地面上放一个标定尺让ORB-SLAM2初始化时包含尺子然后从点云中手动测量尺度因子。5.4 特征点在弱纹理场景下集体罢工现象对着白墙或天空拍程序很快报跟踪丢失甚至初始化时找不到特征。原因ORB特征依赖灰度角点白墙没有角点ORBextractor.nFeatures1000基本全废。天空区域过曝也是同样的问题。解决采集数据时尽量让画面中包含边缘和纹理比如室内的桌椅、室外的人行道砖缝。如果必须拍白墙可以提高图像伽马值或用CLAHE直方图均衡化预处理但记住预处理后的图内参不变只是特征提取更有效。5.5 分辨率太高导致实时性崩溃跟踪滞后现象运行时可视化窗口卡顿终端报tracking time: 80ms然后逐渐跟踪丢失重定位循环。原因1920x1080图像原始ORB提取器在普通CPU上每帧需要100ms以上超过30fps的采集节奏处理不过来。解决降低分辨率到640x480或320x240同时把yaml里的Camera.rows/cols改成对应值。另外把ORBextractor.nFeatures降到800也可以提速但如果场景特征多建议保持1000并关闭Viewer来腾出CPU。5.6 把动态物体当静止轨迹被“人”带偏现象在室内走廊拍有人从镜头前走过地图里出现一个密集的人形点团之后轨迹把人形点当成静止特征导致定位突然偏移。原因ORB-SLAM2没有任何动态物体剔除机制属于纯几何SLAM。移动的人、摇晃的树叶都会被当成立体匹配点参与位姿估计。解决采集时避免动态物体或者用语义SLAM后处理。如果实在避不开在后期用RANSAC的鲁棒核或设置ORBextractor.nFeatures较高让静止特征占多数但本质问题是无法根治的。6. 进阶用法从图片序列到实时鲁棒运行的关键调参技巧当你能用自己的序列稳定跑通后下一步是让它在更多场景和边界条件下不崩。这里有三个我常用的进阶技巧。第一个技巧是调整图像金字塔的层数和尺度因子。默认scaleFactor1.2、nLevels8这个设置对慢速运动足够但如果相机在快速平移或转弯特征点尺度变化剧烈建议改成scaleFactor1.1、nLevels10。改法是在yaml里增加ORBextractor.scaleFactor: 1.1 ORBextractor.nLevels: 10更小的尺度因子让相邻金字塔层的图像更接近特征点匹配的尺度范围更连续。但代价是每帧提取特征的时间变长所以如果你的场景是手持慢速拍摄保持默认即可。第二个技巧是启用或调整闭环检测线程的活跃度。ORB-SLAM2默认每帧检测闭环但如果你拍摄的路径是重复性很强的区域如长走廊闭环检测容易误报。可以在配置里调低闭环候选数量或者在运行时观察终端若看到Loop detected!但地图点没有明显校正说明候选匹配错误可回退到上一版本代码去掉闭环仅用局部优化。我自己的习惯是先用默认参数跑通再刻意走一个闭环路径验证地图是否回环如果回环校正后轨迹跳动超过0.2米就检查特征字典是否够丰富必要时重新训练词袋。第三个技巧是给轨迹做后处理用EVO的滤波或平滑。但更实用的做法是在采集时增加一个“慢启动”动作——原地轻微晃动相机3秒让ORB-SLAM2稳定初始化。这个动作看似无关紧要但对单目初始化质量影响巨大。快速晃动会让三角化出深度很差的点导致初始地图尺度错误后续整个轨迹都会漂移。所以我的习惯是录制数据时前5秒保持相机静止然后缓慢平移再开始正常采集。这样初始化矩阵的基线足够且场景有足够视差。最后如果你真的要在实际项目中落地这套流程建议写一个自动化的数据检查脚本在跑ORB-SLAM2之前检查图片数量、时间戳递增性、内参文件是否与分辨率匹配以及关键帧间隔的数值分布。这能省掉大半的“为什么跑飞”的排查时间。我的血泪经验是与其反复调ORB-SLAM2的参数不如先把数据质量搞干净。很多玄学翻车最终查下来都是时间戳或内参的问题而不是SLAM算法本身。希望这篇文章能帮你把手里的图片序列变成一条干净的轨迹。如果你的数据还是跑不出的状态先按第5章的检查清单一项项过多半能在十分钟内找到问题。本文还有配套的精品资源点击获取