集中型 対 分散型

協調型(マルチロボット)SLAMシステムは、グローバルマップがどこで組み立てられるかにおいて最も根本的に異なる。

集中型アーキテクチャ

単一のサーバー(地上基地局またはクラウド)がすべてのロボットからデータを集約し、グローバル最適化を行う。各ロボットは軽量なローカルフロントエンド(トラッキング、キーフレーム選択)を実行し、キーフレーム、記述子、あるいはサブマップをサーバーへストリーミングする。サーバーはロボット間の場所認識、マップ統合、グローバルバンドル調整を行い、補正されたマップをブロードキャストで返す。例: C2TAM(クラウドベースのPTAM)、CCM-SLAM(サーバー + ORB-SLAMクライアント)、maplab 2.0(マルチセッション統合)。

ネットワークを流れるもの: 上りはキーフレーム(キーポイント + 記述子 + 位置推定)、下りは最適化されたマップ補正。生の画像はロボット上に留まる。

うまく設計された集中型システムは、それでも緩やかに劣化する: CCM-SLAMのクライアントは、キーフレームをバッファリングし後から遡って同期させることで、切断中もトラッキングを継続する。つまりサーバーは共有マップにとって重要だが、各ロボットの安全性にとっては重要ではない。

分散型(ピアツーピア)アーキテクチャ

サーバーは存在しない。ロボットは通信範囲内にある近隣ロボットと直接情報を交換し、各ロボットは(部分的な)グローバルマップの自分自身の推定を保持する。最適化は分散される — 各ロボットは自身の軌道変数を反復更新し、境界/セパレータ位置の推定だけを近隣と交換し、ネットワークがグローバル最適解に向かって収束するまでこれを繰り返す。例: DOOR-SLAM、Kimera-Multi、Swarm-SLAM。

ネットワークを流れるもの: 遭遇時のコンパクトな場所認識記述子、続いて候補となるクロージャを検証するための特徴、そして小さな反復ごとの最適化メッセージ — マップ全体を流すことは決してない。

比較

集中型分散型
グローバル最適化サーバー上、厳密分散、反復的
障害耐性サーバーが重要緩やかに劣化
通信ロボット-サーバー間ロボット-ロボット間(近隣)
外れ値の検証サーバーがすべてのクロージャを見る頑健なバックエンド(PCM、GNC)が必要
マップのバージョン管理単一の権威あるマップ一時的に分岐するローカルなビュー
典型的なチーム規模小規模(2-4)より大きな群れ

選び方

根本的な緊張関係は一貫性と通信コストの間にある: 集中型システムはより強いグローバル一貫性を達成するが単一障害点を生み出す。分散型システムはより頑健だがグローバルな最適化が難しい。最近の研究(Kimera-Multi、Swarm-SLAM)は、頑健な外れ値除去を伴う分散型アーキテクチャへと傾いている。

SLAMにおける意義

アーキテクチャの選択は、協調型SLAM設計における他のすべてを左右する — 何が送信されるか、ループクロージングがどこで検証されるか、マップ統合がどのように行われるか、システムがどのように失敗するか。信頼できるWiFiを持つ小規模チームには、集中型システムが正確な共有マップへの最も単純な道筋である。群れ、地下探索、あるいは妨害を受けるネットワークには、分散型設計だけが生き残る。

関連ノート