CCM-SLAM

Schmuck & Chli 2019 · 論文

一行要約 — CCM-SLAMは、固定サイズのローカルマップを持つORB-SLAMベースのエージェントがキーフレームをサーバーへストリーミングし、サーバーが場所認識、Sim(3)マップ融合、冗長性除去、グローバル最適化を行う、集中型の協調単眼SLAMシステムであり、通信障害を通じてすべてのロボットが飛行を継続できるように設計されている。

問題

単一ロボットの単眼SLAMはカバレッジが限られ、ドリフトに対して脆弱である。ロボットチームであればより速くマッピングし、互いのドリフトを補正できるが、それには3つの問題を同時に解決する必要がある: (1)帯域幅の制約された無線リンク上でマップデータを効率的に共有すること、(2)未知の初期配置を持つ異なるロボットが構築したマップを1つの一貫した推定へ統合すること、(3)いずれのエージェントも危険に陥らせずにメッセージの損失や遅延を乗り越えること。これを難しくする追加の制約: 小型UAVの搭載計算機は成長し続けるグローバルマップをホストできないため、アーキテクチャ自体がクライアント側のリソースを制限しつつ、すべてのナビゲーションに不可欠なタスクを搭載機上に保持しなければならない。

手法とアーキテクチャ

エージェント側。 各ロボットは、 $N$ 個のキーフレームに切り詰められたローカルマップ $L$ (加えて最大 $B=N$ 個の未確認キーフレームのバッファ)を持つORB-SLAMのキーフレームベースの視覚オドメトリフロントエンドを実行する — キーフレームとマップ点は共視性グラフで接続される(15点以上を共有していればエッジ、重みは共有観測数)。切り詰めは参照キーフレーム $KF_{ref}$ と最新のキーフレームを保持する。他のエージェントが生成したキーフレームは、サーバーが保持していることが保証されているため最初に除去される。サーバーとのリンクが切れた場合、エージェントは限られたマップウィンドウでのVOに単純に劣化する — 自律性は決して委譲されない。

サーバー側。 サーバーのマップスタックはエージェントごとに1つの(無制限の)マップを保持する。エージェントごとのハンドラが通信、マップ管理、場所認識スレッドを実行する。各ハンドラは、エージェントのローカルフレームからサーバーマップへの $\mathrm{Sim}(3)$ 変換 ${}^{L_i}S_i^{M_j}=\{R,t,s\}$ を保持する(初期値は恒等変換 — グローバルな参照フレームは決して仮定されない)。DBoW2キーフレームデータベースは2種類の問い合わせをサポートする: マップ内場所認識(ループクロージング → グローバルバンドル調整)と、エージェント間のマップマッチングである。マッチが見つかると、マップ融合は ${}^{M_m}S^{M_q}$ を計算し、マッチしたマップ点のペアを新しいエージェント間制約として統合し、グローバルBA(g2o Levenberg-Marquardt、その前に強いエッジ $w\geq100$ に対するessential-graphポーズグラフ最適化)を実行し、影響を受けるすべてのハンドラの変換を ${}^{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特徴で約55kB。新しいマップ点は約200B)と更新(キーフレームあたり148B、マップ点あたり52B)を区別する — 一度だけ送るか、繰り返し送るかの違いである。これにより平均トラフィックは約10MB/sから0.37MB/sに削減された。損失処理は楽観的である: サーバーは処理済みキーフレームIDを確認応答し、欠落があれば再送をトリガーする。サーバーは、エージェントのローカルマップを(他のエージェントの経験も含めて)補強するために、 $KF_{ref}$ と最も共視性の高い $k$ 個のキーフレームを返信する。

実験結果

ハードウェア: 3台のUAV(Intel NUC i7搭載のAscTec Neo 2台、200gペイロードのAtomboard搭載AscTec Hummingbird 1台)とラップトップサーバーが標準WiFiで通信する。評価はEuRoC machine-hallシーケンスと著者らの屋外Irchelデータセット(Leicaトータルステーションによる真値)で行われ、通常5回の実行にわたって平均化される。

帯域幅/頑健性: 定常時のエージェントあたりのトラフィックは、エージェント→サーバー方向で約0.37MB/s、サーバー→エージェント方向で約0.5-0.75MB/s。0.5秒の遅延は何も変えない。20%のメッセージ損失はやや高いトラフィックで吸収される。50%の損失はトラフィックをおよそ2倍にし、ローカルマップが小さい場合は永続的なデータ損失を引き起こす可能性がある。トラフィックはエージェント数に対して線形にスケールする。
精度(軌道RMSE、協調 = すべてのエージェントの結合軌道): EuRoC MH1-3で3エージェント: 0.077m(軌道長の0.03%)対、単一エージェントの0.048-0.081m(0.04-0.116%); 単眼慣性のVINS-Monoマルチセッション: 0.074m(0.03%)。Irchel: 0.21m(0.06%)対VINS-Monoの0.36m(0.11%) — 協調によって相対誤差が改善する。
搭載トラッキングは共有から利益を得る: データ交換を有効にすると、2エージェントの累積トラッキングRMSEが0.296から0.265m(MH01+MH02)、0.327から0.272m(MH02+MH03)に低下する。
実飛行: 3台のUAVが30×7mの都市シーンを飛行中にオンラインでマッピングし、飛行中に2回のマップ融合と2回のループクロージングが発生した。2台のUAVによる約200×100mの訓練村での捜索救助デモでは、標準的なWiFiルーター上で単一の1336キーフレーム、46413点のサーバーマップが生成され、各エージェント上でリアルタイム動作が終始維持された。

SLAMにおける意義

CCM-SLAMは、C2TAMのクラウドSLAMという概念を、現代的なORB-SLAMバックボーン上の成熟したオープンソースシステムへと発展させ、その後の協調型システムが比較対象とするデファクトのベースラインとなった。その中心的な教訓 — アーキテクチャによってエージェントのリソースを制限すること、相対(絶対でない)位置を交換すること、一度きりのデータと更新を分離すること、ネットワーク損失を通じてローカルな自律性が生き残るよう設計すること — は、その後のほぼすべてのマルチロボットSLAM研究に受け継がれた。集中型側の直接の後継であるCOVINSとmaplab 2.0、そしてサーバーを完全に排除した分散型の後継であるDOOR-SLAMとKimera-Multiである。

CCM-SLAM

問題

手法とアーキテクチャ

実験結果

SLAMにおける意義

関連ノート