CCM-SLAM

Schmuck & Chli 2019 · 论文

一句话总结 — CCM-SLAM 是一个集中式协作单目 SLAM 系统,其中基于 ORB-SLAM 的代理各自维护固定大小的局部地图,并将关键帧流式传输给一台服务器,由服务器执行场景识别、Sim(3) 地图融合、冗余剔除和全局优化——其设计目标是让每个机器人在通信故障期间也能持续飞行。

问题

单机器人单目 SLAM 的覆盖范围有限,且容易受到漂移的影响;一个机器人团队可以更快地建图,并互相纠正漂移——但前提是必须同时解决三个问题:(1) 在带宽受限的无线链路上高效共享地图数据,(2) 将不同机器人(初始配置未知)构建的地图合并为一个一致的估计,(3) 在没有消息丢失和延迟威胁到任何代理的情况下保持稳健。使这个问题变得棘手的额外约束是:小型无人机的机载计算机无法承载不断增长的全局地图,因此架构本身必须限制客户端的资源使用,同时将所有导航关键任务保留在机载端。

方法与架构

代理端。 每个机器人运行 ORB-SLAM 的基于关键帧的视觉里程计前端,其局部地图 LL 被裁剪为 NN 个关键帧(外加最多 B=NB=N 个尚未确认的缓冲关键帧)——关键帧和地图点通过共视图连接(若共享地图点数 ≥15 则存在一条边,权重为共享观测数)。裁剪时会保留参考关键帧 KFrefKF_{ref} 和最近的关键帧;由其他代理创建的关键帧会最先被移除,因为服务器必定持有它们。如果服务器链接中断,代理只需退化为带受限地图窗口的 VO——自主权永不外包。

服务器端。 服务器地图堆栈为每个代理保存一个(无限制大小)地图;每个代理的处理程序运行通信、地图管理和场景识别线程。每个处理程序保存一个从代理局部坐标系到其服务器地图的 Sim(3)\mathrm{Sim}(3) 变换 LiSiMj={R,t,s}{}^{L_i}S_i^{M_j}=\{R,t,s\}(初始为单位变换——从不假定存在全局参考坐标系)。一个 DBoW2 关键帧数据库支持两种查询类型:地图内场景识别(回环检测→全局光束法平差)和跨代理的地图匹配。匹配成功时,地图融合会计算 MmSMq{}^{M_m}S^{M_q},将匹配的地图点对合并为新的跨代理约束,运行全局 BA(g2o Levenberg-Marquardt,之前先在强边上进行本质图位姿图优化,w100w\geq100),并将每个受影响处理程序的变换更新为 LiSiMf=LiSiMq(MmSMq)1{}^{L_i}S_i^{M_f} = {}^{L_i}S_i^{M_q}\cdot\left({}^{M_m}S^{M_q}\right)^{-1}。一种概率性关键帧剔除方案负责去除冗余:如果一个关键帧 θ%\theta\% 的地图点被至少 3 个其他关键帧观测到,该关键帧就会被剔除——这对于大规模任务而言至关重要。

通信协议(工程核心所在)。 所有位姿都以相对坐标交换——每个关键帧对其前驱及其共视父节点编码相对位姿——因此在服务器地图被锁定进行优化期间到达的数据,会隐式地被优化结果所修正(绝对坐标在回环检测后会出现错位)。消息区分新数据(包含 2D 关键点和 36 字节 ORB 描述子的完整关键帧,1000 个特征时约 55 kB;新地图点约 200 B)和更新(每个关键帧 148 B,每个地图点 52 B)——前者只发送一次,后者反复发送;这将平均流量从约 10 MB/s 降低到 0.37 MB/s。丢失处理采取乐观策略:服务器确认已处理的关键帧 ID,出现空缺则触发重传。服务器会回复与 KFrefKF_{ref} 共视程度最高的 kk 个关键帧,以(可能来自其他代理的)经验来扩充该代理的局部地图。

实验结果

硬件:三架无人机(两架搭载 Intel NUC i7 的 AscTec Neo,一架搭载 Atomboard、载重 200 克的 AscTec Hummingbird)和一台笔记本电脑服务器,通过标准 WiFi 通信;在 EuRoC 机械大厅(machine-hall)序列以及作者的室外 Irchel 数据集(Leica 全站仪真值)上进行了评估,通常取 5 次运行的平均值。

对SLAM的意义

CCM-SLAM 将 C2TAM 的云 SLAM 概念转变为一个建立在现代 ORB-SLAM 骨架之上的成熟开源系统,并成为后续协作系统事实上的比较基线。它的核心经验——通过架构限制代理的资源、交换相对(而非绝对)位姿、将一次性数据与更新分开、以及设计使本地自主能够在网络中断后依然存活——渗透进了几乎所有后续的多机器人 SLAM 工作:在集中式一侧,其直接后代是 COVINS 和 maplab 2.0;在去中心化一侧,其继任者 DOOR-SLAM 和 Kimera-Multi 完全移除了服务器。

相关条目