ORB-SLAM3 包含三个并行运行的核心模块Tracking跟踪、Local Mapping局部建图和Loop Closing回环。以前也有一些针对ORBSLAM的GPU加速工作但基本是针对的ORBSLAM2而且主要是对前端也就是跟踪模块做GPU加速这个我在以前的文章《SLAM前端中的GPU加速——以vins-fusion-gpu和ORB_SLAM2_CUDA为例》里有介绍。ORBSLAM3框架图(截自《视觉惯性SLAM:理论与源码解析》)2025-2026年加拿大西蒙菲莎大学 (SFU) 的Reliable Systems Lab针对 ORB-SLAM3 的这三个模块发布了三个对应的 GPU 加速工作FastTrack对跟踪模块实现GPU加速、TurboMap对局部建图模块实现GPU加速(turbo是加速的意思)、FastLoop对回环模块实现GPU加速这三个工作都是开源的我关注也有一段时间了但是较为可惜的是他们没有集成在一个统一的SLAM上。我今天重新查看他们实验室的github时惊喜地发现他们已经把FastTrack、TurboMap和FastLoop集成为了一个统一的可以对三个模块同时进行GPU加速的ORB‑SLAM3版本Nitro-SLAM并且开源了地址在https://github.com/sfu-rsl/Nitro-SLAM。下面分别对这些工作做些简要介绍如果有时间建议阅读下论文原文会讲述得更为清晰这几项工作的论文及代码地址如下FastTrack 论文https://arxiv.org/abs/2509.10757 代码https://github.com/sfu-rsl/FastTrackTurboMap 论文https://arxiv.org/abs/2511.02036 代码https://github.com/sfu-rsl/TurboMap)FastLoop 论文https://arxiv.org/abs/2603.17201 代码https://github.com/sfu-rsl/FastLoopNitro-SLAM 代码https://github.com/sfu-rsl/Nitro-SLAM一、FastTrack加速前端跟踪1.1 问题分析Tracking 是 SLAM 系统的入口所有传感器数据必须先经过跟踪后才能进入其他模块。若跟踪过慢会导致丢帧、定位漂移甚至跟踪丢失尤其在资源受限的嵌入式设备上更为致命。通过对 ORB-SLAM3 的分析作者发现 Tracking 中最耗时的三个子环节是ORB 特征提取在 EuRoC 数据集占据主要时间立体匹配Stereo Matching包括 pinhole 极线搜索和 fisheye 暴力搜索局部地图跟踪Track Local Map在 TUM-VI 数据集耗时占用尤其大1.2 关键设计具体在论文第IV节FastTrack 设计了多个 CUDA kernel立体匹配 GPU 化针对 pinhole极线约束搜索和 fisheye暴力搜索两种相机模型分别实现 GPU kernel覆盖了 ORB-SLAM3 的完整相机模型支持。Search by Projection 并行化局部地图跟踪包括更新局部地图、搜索局部地图点和位姿优化三个阶段。FastTrack 重点将搜索局部地图点中的投影搜索(Search by Projection)任务offload到 GPU即把局部地图点投影到当前帧并在当前帧特征中寻找对应关系的过程 offload 到 GPU。(更新局部地图选择留在了CPU原因见5位姿优化选择了跳过原因见4)集成已有的 ORB 特征提取 GPU 加速参考 Muzzini 等人的工作。跳过局部地图跟踪(Local Map Tracking)中的位姿优化(Pose Optimization)通过实验分析发现这一步可省略而且不显著影响精度。数据传输优化在选择哪些组件上 GPU 时需要注意避免高昂的 CPU↔GPU 数据搬运。比如FastTrack 将跟踪局部地图中更新局部地图保留在 CPU 上。这是因为尽管此过程包含大型循环但每次迭代的执行成本较低而 GPU offload会导致大量数据传输。1.3 实验结果在 EuRoC 和 TUM-VI 数据集上、台式机与 Jetson Xavier NX 嵌入式平台上、stereo-inertial 模式下整体 Tracking最高 2.8× 加速ATE 精度与原版 ORB-SLAM3 相当与同类工作 Jetson-SLAM 相比FastTrack 在 MH01–MH03 上 FPS 更高且轨迹误差显著更低体现了速度与精度的更佳平衡。二、TurboMap重构局部建图后端2.1 问题分析局部建图模块负责处理关键帧以及地图的构建、维护和优化。它包括地图点创建、地图点融合、局部束调整和冗余关键帧剔除等操作。局部建图必须在严格的延迟约束下运行因为局部建图延迟会降低地图质量并增加跟踪失败的风险。TurboMap 指出局部建图的 GPU 并行化面临两个主要挑战共享状态同步开销Local Mapping 频繁读写共享地图map points / keyframes而其他模块同时也在访问需用锁同步——天然制约并行性。大数据传输开销每次迭代要把大量关键帧与地图点数据传到 GPU可能抵消并行收益。也因此先前工作大多只加速Local Bundle Adjustment (LBA)这一天然数据并行的子任务而其他耗时组件Map Point Creation、Map Point Fusion、Keyframe Culling几乎无人触碰。2.2 关键设计具体在论文第IV节TurboMap 是首个整体性重构 Local Mapping 的工作重构地图点创建地图点创建首先在相邻关键帧之间搜索关键点对应关系然后通过三角化确定三维位置并检查视差、正深度、重投影误差和尺度一致性等几何及光度约束。TurboMap 重构这一流程使关键点对应关系搜索能够在 GPU 上并行执行。并行化地图点融合重新设计融合阶段以避免顺序依赖。CPU 端优化关键帧剔除发现该步骤并行收益有限改为 CPU 端高效实现。集成已有的 GPU LBA solver复用现有的 Bundle Adjustment 加速器。持久化 GPU 关键帧存储 (Persistent GPU-resident KeyFrame Storage)将不变immutable的关键帧数据常驻 GPU使局部建图所需的关键帧数据持续保留在 GPU 内存中从而减少重复的数据传输和同步开销。这一设计后来也被 FastLoop 直接复用。2.3 实验结果EuRoC 数据集 Local Mapping平均加速 1.3×TUM-VI 数据集平均加速 1.6×在台式机与嵌入式平台均保持轨迹精度。特别地为探究系统在快速运动场景下的性能作者设计了一个模拟需要高关键帧插入率以维持跟踪精度的实验评估TurboMap和ORB-SLAM3在高局部建图负载下的表现原版 ORB-SLAM3 在高负载下会跳过 LBA 和 Keyframe Culling 以节省时间导致轨迹误差大幅恶化而 TurboMap 凭借更高的处理能力几乎不需跳过这些阶段精度显著优于原版——如 MH01 序列中 ORB-SLAM3 轨迹明显偏离 ground truthTurboMap 则紧贴真值。三、FastLoop并行化回环校正3.1 问题分析回环模块用于判断当前关键帧是否与地图中此前访问过的位置相似并在检测到已访问区域时校正累积误差。ORB-SLAM3 的回环流程包括回环检测和回环校正。论文指出回环检测本身可以较快完成因此FastLoop主要关注回环校正而不是回环检测。当成功建立当前关键帧与历史关键帧之间的数据关联后回环校正需要更新关键帧连接、利用估计的 Sim3 变换修正位姿、融合重复地图点并在本质图上执行位姿图优化将回环修正传播到地图中的其他关键帧。回环校正涉及全局地图范围内的操作因此在检测到回环时可能成为显著的计算瓶颈。其挑战在于共享数据冲突Loop Closing 会修改关键帧位姿、融合地图点、改变图连接与 Tracking、Local Mapping 高度共享数据重复计算模式特征关联与地图点融合反复执行每次都涉及数据传输与 kernel 启动开销回环 GPU 加速研究极少现有工作大多只优化 BA 或回环检测的神经网络部分而对**回环校正Loop Correction**的核心计算几乎未有系统化 GPU 方案。通过分析作者发现回环校正中最耗时的是Loop Fusion(回环融合)和Graph Optimization(图优化)。3.2 关键设计具体在论文第IV节FastLoop 主要设计包括如下Task-level Parallelism任务并行识别那些后续才需要但当前可提前算的任务重排执行顺序让独立任务并发执行。Data-level Parallelism数据并行数据并行性关注的是用相同计算同时处理多个相互独立的数据元素数据并行化有两个必需的条件1它们将相同操作应用到不同的数据元素上例如单个地图点或关键帧2这些数据元素之间不存在依赖关系。回环闭合中适合数据级并行化的组件有投影搜索和回环融合。Projection Search并行化投影搜索Loop Fusion并行化重复的特征关联与地图点融合GPU 内存与数据传输优化包括复用 TurboMap 引入的 GPU-resident KeyFrame Storage每当局部建图插入新的关键帧时FastLoop 首先将其传输到 GPU 驻留的关键帧存储中以减少后续在 CPU 内存和 GPU 内存之间的重复数据传输。还使用了页锁定内存pinned/page-locked memory来加速主机到设备的数据传输等措施具体详见论文IV.E小节。Pose Graph Optimization基于实验室自研的Graphite一个基于CUDA的GPU加速混合精度非线性最小二乘图优化框架实现采用 Levenberg–Marquardt 与自动微分避免了如 JacobiGPU 那样仍需多次 CPU–GPU 来回的开销。3.3 实验结果在 Loop Closing 模块上EuRoC台式机1.4×Jetson1.3×TUM-VI台式机3.0×Jetson2.4×仅看 Loop Correction 部分TUM-VI 台式机上甚至达到3.1×轨迹精度与原版 ORB-SLAM3 相当。3.4 关于GraphiteFastLoop里使用到了GraphiteGraphite 被应用于 回环中最后的 full-inertial bundle adjustment也就是全局视觉惯性 BA。这个在FastLoop和Graphite的论文里都有明确说FastLoop论文里:F. Graph OptimizationThe next step is an essential (pose) graph optimization to propagate the loop correction to the rest of the map,as shown in Figure 2b. To move this process to the GPU,we rewrite the original pose graph optimization and replace the optimization library, g2o , with a GPU-acceleratedalternative, Graphite.Graphite论文里C. Case Study: Visual-Inertial Bundle AdjustmentWe apply Graphite to full-inertial bundle adjustment in ORBSLAM3, which introduces several additional variables and constraints to visual bundle adjustment(Section II).Graphite 是一个基于 CUDA C 和 Levenberg-Marquardt 的 GPU 加速非线性最小二乘图优化框架。它通过描述符批处理支持相同类型项目的并行处理通过用户自定义数据类型适配复杂优化变量和约束通过解析微分、自动微分和动态 Jacobian 提供不同的开发与内存使用选择并通过混合精度、原地优化、图结构感知的 PCG 以及矩阵无关计算降低运行时间和 GPU 内存占用。Graphite也是Reliable Systems Lab团队更早期工作JacobiGPU(ICRA 2024)的延伸。JacobiGPU的项目地址是https://github.com/sfu-rsl/jacobiGPU四、Nitro-SLAMNitro-SLAM把上面三项工作FastTrack、TurboMap 与 FastLoop给集成到了一起实现了一个可以同时对ORBSLAM3的跟踪模块局部建图模块回环模块进行GPU加速的SLAM。Nitro-SLAM里可以通过位掩码来选择哪些模块进行GPU加速位掩码中每个数字位置都充当一个二进制开关1 表示启用0 表示禁用对应的算法子内核或例程。位掩码具体含义如下FastTrack (5-Digit Configuration)1xxxx : ORB feature extraction acceleration on GPU.x1xxx : Stereo feature matching optimization on GPU.xx1xx : Local map points search acceleration on GPU.xxx1x : Camera pose estimation acceleration on GPU.xxxx1 : Tracking pose optimization on/off toggle.TurboMap (4-Digit Configuration)1xxx : Map-point triangulation search acceleration on GPU.x1xx : Map-point fusion acceleration on GPU.xx1x : Redundant keyframe culling optimization on CPU.xxx1 : Local Bundle Adjustment (LBA) solver execution on GPU.FastLoop (6-Digit Configuration)1xxxxx : Merged Sim3 projection search across covisible keyframes for loop-candidate verification on GPU.x1xxxx : Multi-keyframe (up to 3) common-region consistency check across the candidate’s covisible keyframes on GPU.xx1xxx : Loop fusion window and duplicate map-point merging on GPU.xxx1xx : Low-level Sim3 projection-search kernel acceleration on GPU.xxxx1x : Pose Graph Optimization (PGO) / Essential Graph backend engine on GPU.xxxxx1 : Global Full Inertial Bundle Adjustment (GBA) solver execution on GPU (falls back to a PCG iterative solver instead of the direct cuDSS solver once the map exceeds 200 keyframes).更多具体操作可详见https://github.com/sfu-rsl/Nitro-SLAM/blob/main/README.md五、一点个人总结我个人感受比较深的一点是对于GPU加速我们不能单一只看某个模块的计算给它并行化加速就完事了还需要考虑到 CPU-GPU的 数据传输成本。这也是FastTrack、TurboMap 与 FastLoop 三项工作都很重视的一点。如果每次执行 GPU 计算前后都需要在 CPU 内存和 GPU 内存之间传输大量数据那么数据搬运、内存组织和同步等待可能会抵消 GPU 并行计算带来的收益。我们今后自己去实现一些GPU加速时也可以从Nitro-SLAM(FastTrack、TurboMap 与 FastLoop)中参考学习一些基本原则只将计算量较大且适合并行化的部分放到 GPU尽量减少 CPU-GPU 之间的往返传输对可以复用的数据尽可能保留在 GPU 内存中对必须传输的数据批量传输并且只传输实际需要的字段对传输代价过高而计算收益有限的部分保留在 CPU 上在重新组织计算流程时同时考虑数据依赖、同步和传输开销。参考资料FastTrack 论文arXiv:2509.10757 代码github.com/sfu-rsl/FastTrackTurboMap 论文arXiv:2511.02036 代码github.com/sfu-rsl/TurboMapFastLoop 论文arXiv:2603.17201 代码github.com/sfu-rsl/FastLoopGraphite 论文arXiv:2509.26581 代码github.com/sfu-rsl/graphiteNitro-SLAM 代码github.com/sfu-rsl/Nitro-SLAM加拿大西蒙菲莎大学Reliable Systems Lab实验室github主页github.com/sfu-rsl 对ORBSLAM3的跟踪模块、局部建图模块、回环模块都实现GPU加速的开源工作:Nitro-SLAM
ORB-SLAM3 包含三个并行运行的核心模块Tracking跟踪、Local Mapping局部建图和Loop Closing回环。以前也有一些针对ORBSLAM的GPU加速工作但基本是针对的ORBSLAM2而且主要是对前端也就是跟踪模块做GPU加速这个我在以前的文章《SLAM前端中的GPU加速——以vins-fusion-gpu和ORB_SLAM2_CUDA为例》里有介绍。ORBSLAM3框架图(截自《视觉惯性SLAM:理论与源码解析》)2025-2026年加拿大西蒙菲莎大学 (SFU) 的Reliable Systems Lab针对 ORB-SLAM3 的这三个模块发布了三个对应的 GPU 加速工作FastTrack对跟踪模块实现GPU加速、TurboMap对局部建图模块实现GPU加速(turbo是加速的意思)、FastLoop对回环模块实现GPU加速这三个工作都是开源的我关注也有一段时间了但是较为可惜的是他们没有集成在一个统一的SLAM上。我今天重新查看他们实验室的github时惊喜地发现他们已经把FastTrack、TurboMap和FastLoop集成为了一个统一的可以对三个模块同时进行GPU加速的ORB‑SLAM3版本Nitro-SLAM并且开源了地址在https://github.com/sfu-rsl/Nitro-SLAM。下面分别对这些工作做些简要介绍如果有时间建议阅读下论文原文会讲述得更为清晰这几项工作的论文及代码地址如下FastTrack 论文https://arxiv.org/abs/2509.10757 代码https://github.com/sfu-rsl/FastTrackTurboMap 论文https://arxiv.org/abs/2511.02036 代码https://github.com/sfu-rsl/TurboMap)FastLoop 论文https://arxiv.org/abs/2603.17201 代码https://github.com/sfu-rsl/FastLoopNitro-SLAM 代码https://github.com/sfu-rsl/Nitro-SLAM一、FastTrack加速前端跟踪1.1 问题分析Tracking 是 SLAM 系统的入口所有传感器数据必须先经过跟踪后才能进入其他模块。若跟踪过慢会导致丢帧、定位漂移甚至跟踪丢失尤其在资源受限的嵌入式设备上更为致命。通过对 ORB-SLAM3 的分析作者发现 Tracking 中最耗时的三个子环节是ORB 特征提取在 EuRoC 数据集占据主要时间立体匹配Stereo Matching包括 pinhole 极线搜索和 fisheye 暴力搜索局部地图跟踪Track Local Map在 TUM-VI 数据集耗时占用尤其大1.2 关键设计具体在论文第IV节FastTrack 设计了多个 CUDA kernel立体匹配 GPU 化针对 pinhole极线约束搜索和 fisheye暴力搜索两种相机模型分别实现 GPU kernel覆盖了 ORB-SLAM3 的完整相机模型支持。Search by Projection 并行化局部地图跟踪包括更新局部地图、搜索局部地图点和位姿优化三个阶段。FastTrack 重点将搜索局部地图点中的投影搜索(Search by Projection)任务offload到 GPU即把局部地图点投影到当前帧并在当前帧特征中寻找对应关系的过程 offload 到 GPU。(更新局部地图选择留在了CPU原因见5位姿优化选择了跳过原因见4)集成已有的 ORB 特征提取 GPU 加速参考 Muzzini 等人的工作。跳过局部地图跟踪(Local Map Tracking)中的位姿优化(Pose Optimization)通过实验分析发现这一步可省略而且不显著影响精度。数据传输优化在选择哪些组件上 GPU 时需要注意避免高昂的 CPU↔GPU 数据搬运。比如FastTrack 将跟踪局部地图中更新局部地图保留在 CPU 上。这是因为尽管此过程包含大型循环但每次迭代的执行成本较低而 GPU offload会导致大量数据传输。1.3 实验结果在 EuRoC 和 TUM-VI 数据集上、台式机与 Jetson Xavier NX 嵌入式平台上、stereo-inertial 模式下整体 Tracking最高 2.8× 加速ATE 精度与原版 ORB-SLAM3 相当与同类工作 Jetson-SLAM 相比FastTrack 在 MH01–MH03 上 FPS 更高且轨迹误差显著更低体现了速度与精度的更佳平衡。二、TurboMap重构局部建图后端2.1 问题分析局部建图模块负责处理关键帧以及地图的构建、维护和优化。它包括地图点创建、地图点融合、局部束调整和冗余关键帧剔除等操作。局部建图必须在严格的延迟约束下运行因为局部建图延迟会降低地图质量并增加跟踪失败的风险。TurboMap 指出局部建图的 GPU 并行化面临两个主要挑战共享状态同步开销Local Mapping 频繁读写共享地图map points / keyframes而其他模块同时也在访问需用锁同步——天然制约并行性。大数据传输开销每次迭代要把大量关键帧与地图点数据传到 GPU可能抵消并行收益。也因此先前工作大多只加速Local Bundle Adjustment (LBA)这一天然数据并行的子任务而其他耗时组件Map Point Creation、Map Point Fusion、Keyframe Culling几乎无人触碰。2.2 关键设计具体在论文第IV节TurboMap 是首个整体性重构 Local Mapping 的工作重构地图点创建地图点创建首先在相邻关键帧之间搜索关键点对应关系然后通过三角化确定三维位置并检查视差、正深度、重投影误差和尺度一致性等几何及光度约束。TurboMap 重构这一流程使关键点对应关系搜索能够在 GPU 上并行执行。并行化地图点融合重新设计融合阶段以避免顺序依赖。CPU 端优化关键帧剔除发现该步骤并行收益有限改为 CPU 端高效实现。集成已有的 GPU LBA solver复用现有的 Bundle Adjustment 加速器。持久化 GPU 关键帧存储 (Persistent GPU-resident KeyFrame Storage)将不变immutable的关键帧数据常驻 GPU使局部建图所需的关键帧数据持续保留在 GPU 内存中从而减少重复的数据传输和同步开销。这一设计后来也被 FastLoop 直接复用。2.3 实验结果EuRoC 数据集 Local Mapping平均加速 1.3×TUM-VI 数据集平均加速 1.6×在台式机与嵌入式平台均保持轨迹精度。特别地为探究系统在快速运动场景下的性能作者设计了一个模拟需要高关键帧插入率以维持跟踪精度的实验评估TurboMap和ORB-SLAM3在高局部建图负载下的表现原版 ORB-SLAM3 在高负载下会跳过 LBA 和 Keyframe Culling 以节省时间导致轨迹误差大幅恶化而 TurboMap 凭借更高的处理能力几乎不需跳过这些阶段精度显著优于原版——如 MH01 序列中 ORB-SLAM3 轨迹明显偏离 ground truthTurboMap 则紧贴真值。三、FastLoop并行化回环校正3.1 问题分析回环模块用于判断当前关键帧是否与地图中此前访问过的位置相似并在检测到已访问区域时校正累积误差。ORB-SLAM3 的回环流程包括回环检测和回环校正。论文指出回环检测本身可以较快完成因此FastLoop主要关注回环校正而不是回环检测。当成功建立当前关键帧与历史关键帧之间的数据关联后回环校正需要更新关键帧连接、利用估计的 Sim3 变换修正位姿、融合重复地图点并在本质图上执行位姿图优化将回环修正传播到地图中的其他关键帧。回环校正涉及全局地图范围内的操作因此在检测到回环时可能成为显著的计算瓶颈。其挑战在于共享数据冲突Loop Closing 会修改关键帧位姿、融合地图点、改变图连接与 Tracking、Local Mapping 高度共享数据重复计算模式特征关联与地图点融合反复执行每次都涉及数据传输与 kernel 启动开销回环 GPU 加速研究极少现有工作大多只优化 BA 或回环检测的神经网络部分而对**回环校正Loop Correction**的核心计算几乎未有系统化 GPU 方案。通过分析作者发现回环校正中最耗时的是Loop Fusion(回环融合)和Graph Optimization(图优化)。3.2 关键设计具体在论文第IV节FastLoop 主要设计包括如下Task-level Parallelism任务并行识别那些后续才需要但当前可提前算的任务重排执行顺序让独立任务并发执行。Data-level Parallelism数据并行数据并行性关注的是用相同计算同时处理多个相互独立的数据元素数据并行化有两个必需的条件1它们将相同操作应用到不同的数据元素上例如单个地图点或关键帧2这些数据元素之间不存在依赖关系。回环闭合中适合数据级并行化的组件有投影搜索和回环融合。Projection Search并行化投影搜索Loop Fusion并行化重复的特征关联与地图点融合GPU 内存与数据传输优化包括复用 TurboMap 引入的 GPU-resident KeyFrame Storage每当局部建图插入新的关键帧时FastLoop 首先将其传输到 GPU 驻留的关键帧存储中以减少后续在 CPU 内存和 GPU 内存之间的重复数据传输。还使用了页锁定内存pinned/page-locked memory来加速主机到设备的数据传输等措施具体详见论文IV.E小节。Pose Graph Optimization基于实验室自研的Graphite一个基于CUDA的GPU加速混合精度非线性最小二乘图优化框架实现采用 Levenberg–Marquardt 与自动微分避免了如 JacobiGPU 那样仍需多次 CPU–GPU 来回的开销。3.3 实验结果在 Loop Closing 模块上EuRoC台式机1.4×Jetson1.3×TUM-VI台式机3.0×Jetson2.4×仅看 Loop Correction 部分TUM-VI 台式机上甚至达到3.1×轨迹精度与原版 ORB-SLAM3 相当。3.4 关于GraphiteFastLoop里使用到了GraphiteGraphite 被应用于 回环中最后的 full-inertial bundle adjustment也就是全局视觉惯性 BA。这个在FastLoop和Graphite的论文里都有明确说FastLoop论文里:F. Graph OptimizationThe next step is an essential (pose) graph optimization to propagate the loop correction to the rest of the map,as shown in Figure 2b. To move this process to the GPU,we rewrite the original pose graph optimization and replace the optimization library, g2o , with a GPU-acceleratedalternative, Graphite.Graphite论文里C. Case Study: Visual-Inertial Bundle AdjustmentWe apply Graphite to full-inertial bundle adjustment in ORBSLAM3, which introduces several additional variables and constraints to visual bundle adjustment(Section II).Graphite 是一个基于 CUDA C 和 Levenberg-Marquardt 的 GPU 加速非线性最小二乘图优化框架。它通过描述符批处理支持相同类型项目的并行处理通过用户自定义数据类型适配复杂优化变量和约束通过解析微分、自动微分和动态 Jacobian 提供不同的开发与内存使用选择并通过混合精度、原地优化、图结构感知的 PCG 以及矩阵无关计算降低运行时间和 GPU 内存占用。Graphite也是Reliable Systems Lab团队更早期工作JacobiGPU(ICRA 2024)的延伸。JacobiGPU的项目地址是https://github.com/sfu-rsl/jacobiGPU四、Nitro-SLAMNitro-SLAM把上面三项工作FastTrack、TurboMap 与 FastLoop给集成到了一起实现了一个可以同时对ORBSLAM3的跟踪模块局部建图模块回环模块进行GPU加速的SLAM。Nitro-SLAM里可以通过位掩码来选择哪些模块进行GPU加速位掩码中每个数字位置都充当一个二进制开关1 表示启用0 表示禁用对应的算法子内核或例程。位掩码具体含义如下FastTrack (5-Digit Configuration)1xxxx : ORB feature extraction acceleration on GPU.x1xxx : Stereo feature matching optimization on GPU.xx1xx : Local map points search acceleration on GPU.xxx1x : Camera pose estimation acceleration on GPU.xxxx1 : Tracking pose optimization on/off toggle.TurboMap (4-Digit Configuration)1xxx : Map-point triangulation search acceleration on GPU.x1xx : Map-point fusion acceleration on GPU.xx1x : Redundant keyframe culling optimization on CPU.xxx1 : Local Bundle Adjustment (LBA) solver execution on GPU.FastLoop (6-Digit Configuration)1xxxxx : Merged Sim3 projection search across covisible keyframes for loop-candidate verification on GPU.x1xxxx : Multi-keyframe (up to 3) common-region consistency check across the candidate’s covisible keyframes on GPU.xx1xxx : Loop fusion window and duplicate map-point merging on GPU.xxx1xx : Low-level Sim3 projection-search kernel acceleration on GPU.xxxx1x : Pose Graph Optimization (PGO) / Essential Graph backend engine on GPU.xxxxx1 : Global Full Inertial Bundle Adjustment (GBA) solver execution on GPU (falls back to a PCG iterative solver instead of the direct cuDSS solver once the map exceeds 200 keyframes).更多具体操作可详见https://github.com/sfu-rsl/Nitro-SLAM/blob/main/README.md五、一点个人总结我个人感受比较深的一点是对于GPU加速我们不能单一只看某个模块的计算给它并行化加速就完事了还需要考虑到 CPU-GPU的 数据传输成本。这也是FastTrack、TurboMap 与 FastLoop 三项工作都很重视的一点。如果每次执行 GPU 计算前后都需要在 CPU 内存和 GPU 内存之间传输大量数据那么数据搬运、内存组织和同步等待可能会抵消 GPU 并行计算带来的收益。我们今后自己去实现一些GPU加速时也可以从Nitro-SLAM(FastTrack、TurboMap 与 FastLoop)中参考学习一些基本原则只将计算量较大且适合并行化的部分放到 GPU尽量减少 CPU-GPU 之间的往返传输对可以复用的数据尽可能保留在 GPU 内存中对必须传输的数据批量传输并且只传输实际需要的字段对传输代价过高而计算收益有限的部分保留在 CPU 上在重新组织计算流程时同时考虑数据依赖、同步和传输开销。参考资料FastTrack 论文arXiv:2509.10757 代码github.com/sfu-rsl/FastTrackTurboMap 论文arXiv:2511.02036 代码github.com/sfu-rsl/TurboMapFastLoop 论文arXiv:2603.17201 代码github.com/sfu-rsl/FastLoopGraphite 论文arXiv:2509.26581 代码github.com/sfu-rsl/graphiteNitro-SLAM 代码github.com/sfu-rsl/Nitro-SLAM加拿大西蒙菲莎大学Reliable Systems Lab实验室github主页github.com/sfu-rsl