集中式与去中心化架构对比
协作（多机器人）SLAM 系统之间最根本的区别在于全局地图在何处被构建。
集中式架构
一台单一的服务器（地面站或云端）汇聚来自所有机器人的数据并执行全局优化。每个机器人运行一个轻量级的本地前端（跟踪、关键帧选择），并将关键帧、描述子或子地图流式传输给服务器；服务器执行跨机器人场景识别、地图融合和全局光束法平差，然后将校正后的地图广播回去。示例：C2TAM（基于云的 PTAM）、CCM-SLAM（服务器 + ORB-SLAM 客户端）、maplab 2.0（多会话融合）。
网络上传输的内容：关键帧（关键点+描述子+位姿估计）向上传输；优化后的地图校正向下传输。原始图像保留在机器人本地。
- 优点：最紧密的全局一致性（服务器能看到一切）、简单的客户端、机器人卸下了繁重的计算、拥有唯一的权威地图。
- 缺点：单点故障、需要与服务器保持连接、服务器的带宽和算力必须随团队规模扩展，且作业范围受通信基础设施的限制。
一个设计良好的集中式系统仍然能优雅地降级：CCM-SLAM 客户端通过缓存关键帧并事后同步，在连接中断期间持续跟踪，因此服务器对于共享地图而言至关重要，但对每个机器人自身的安全而言并非必需。
去中心化（点对点）架构
不存在服务器：机器人在通信范围内直接与邻近节点交换信息，每个机器人维护自己对（部分）全局地图的估计。优化是分布式的——每个机器人在自己的轨迹变量上进行迭代，只与邻居交换边界/分隔位姿的估计，反复迭代直到网络收敛到全局最优。示例：DOOR-SLAM、Kimera-Multi、Swarm-SLAM。
网络上传输的内容：相遇时的紧凑场景识别描述子，随后是用于验证候选回环的特征，再之后是小规模的逐次迭代优化消息——从不传输整个地图。
- 优点：无单点故障、可扩展到更大的团队、能在间歇性的自组织链路下工作，且原始数据可以留在每个机器人本地（隐私/带宽方面）。
- 缺点：全局一致性更难保证——分布式优化器收敛更慢，每个机器人可能暂时持有地图的不同版本，并且鲁棒的异常值剔除（例如 PCM、渐进非凸优化）变得至关重要，因为没有中央权威来审核跨机器人回环。
对比
| 集中式 | 去中心化 | |
|---|---|---|
| 全局优化 | 在服务器上，精确求解 | 分布式，迭代求解 |
| 故障容忍度 | 服务器至关重要 | 优雅降级 |
| 通信方式 | 机器人到服务器 | 机器人到机器人（邻居） |
| 异常值审核 | 服务器审核所有回环 | 需要鲁棒后端（PCM、GNC） |
| 地图版本 | 一个权威地图 | 暂时存在分歧的局部视图 |
| 典型团队规模 | 较小（2-4） | 更大规模的集群 |
如何选择
- 基础设施可靠（仓库 WiFi、实验室、云链接）且团队规模较小 → 集中式：通向一个准确共享地图的最简单路径。
- 链路间歇、短距离或受干扰（地下、灾害响应、集群）→ 去中心化：唯一能在网络分裂时仍持续工作的架构。
- 跨多个会话进行长期建图而非实时协作 → 集中式的离线融合（maplab 2.0 风格）通常就足够了，完全绕开了实时带宽问题。
- 在实践中混合方案很常见：机器人在现场以点对点方式运行，一旦恢复连接就将数据转储到中央服务器。
根本性的矛盾在于一致性与通信成本之间的权衡：集中式系统实现了更紧密的全局一致性，但会产生单点故障；去中心化系统更加稳健，但全局优化更难。近期的工作（Kimera-Multi、Swarm-SLAM）趋向于采用带有鲁棒异常值剔除的去中心化架构。
对SLAM的意义
架构选择驱动着协作 SLAM 设计中的一切其他方面——传输什么内容、在哪里验证回环、地图融合如何发生、以及系统如何失效。对于拥有可靠 WiFi 的小型团队，集中式系统是获得准确共享地图的最简单路径；对于集群、地下探索或受干扰的网络，去中心化设计才是唯一能够存活下来的方案。