Survey Preprint · under review · 2026

Collaborative SLAM in the Era of 3D Gaussian Splatting

Architectures, methods, and future directions

Phuc Nguyen Xuan^1,†, Thanh Nguyen Canh^2,†, Huu-Hung Nguyen³, Nak Young Chong^2,4, Xiem HoangVan^5,*

¹Institute of System Integration, Le Quy Don Technical University ²Japan Advanced Institute of Science and Technology ³AI and Data Science Research Center, Le Quy Don Technical University ⁴Hanyang University ⁵VNU University of Engineering and Technology ^†Equal contribution ^*Corresponding author

arXiv Paper list Explore the systems

28: methods on the timeline
2: architectures
4: core problems
4: design patterns
7: open questions

01 · Overview

One shared Gaussian world model for a whole robot team

Multi-robot SLAM needs a scene representation that is real-time, high-fidelity and easy to fuse across agents. Sparse feature maps and neural implicit fields each miss one of these. 3D Gaussian Splatting renders explicit Gaussian primitives by differentiable rasterization, so it is both fast and photorealistic, but its dense submaps strain bandwidth and must stay consistent across agents.

This survey reviews Collaborative Gaussian Splatting SLAM (CoGS-SLAM): systems that build a shared Gaussian map across robot teams. It proposes an architecture-based taxonomy, analyses four core problems, identifies cross-cutting design patterns, compares systems on common benchmarks and sets out open questions.

Architecture taxonomy

Centralized designs, which still dominate because of 3DGS compute and sync demands, versus emerging distributed ones.

Problem-oriented analysis

Correspondence, registration, consistency and communication, with the solution strategies used for each.

Benchmarks & directions

Datasets, metrics and results on ReplicaMultiAgent, plus seven open research questions.

02 · Architecture

Centralized or distributed?

Classic collaborative SLAM moved from centralized to distributed designs. Gaussian-splatting SLAM temporarily reverses that trend: most systems keep a server because 3DGS training and map fusion are heavy.

Centralized · most CoGS-SLAM today

Agents track, a server fuses

Agents run tracking, local mapping and feature extraction. The server handles inter-agent loop closure, Gaussian-to-Gaussian registration, global map merging and pose-graph optimization.

e.g. CP-SLAM, MANG-SLAM, GRAND-SLAM, HAMMER, MAGiC-SLAM

High-fidelity reconstruction, robust map integration
Server bottleneck, single point of failure

Distributed · emerging

Peers map and agree

Each agent maps and tracks on its own and shares information peer to peer, reaching agreement through consensus (e.g. ADMM), distillation or distributed pose-graph optimization.

e.g. Di-NeRF, MNE-SLAM, MAC-Ego3D, CoMA-SLAM

No single point of failure, more scalable
Harder convergence, still immature for 3DGS

Core components of CoGS-SLAM. Centralized: each agent does tracking, local mapping, loop closure detection and 3D Gaussian map representation, and streams data to a server that does inter-agent loop closure, semantic extraction, submap merging and pose graph optimization. Distributed: each agent additionally does intra-agent selection and association and inter-agent alignment. — Fig. 4 of the paper: core components of CoGS-SLAM, centralized (top) and distributed (bottom).

03 · Core problems

Four problems every CoGS-SLAM system must solve

From finding overlapping observations to building one consistent, scalable Gaussian map.

Core problem pipeline: multi-agent observations go through local tracking and mapping, then the core collaborative problems (inter-agent correspondence, spatial alignment, consistency maintenance) produce a globally consistent Gaussian map and trajectories, supported by a cross-cutting communication layer. — Fig. 5 of the paper: the core problem pipeline of CoGS-SLAM.

Cross-cutting design patterns

04 · Evolution

From collaborative SLAM to collaborative Gaussian maps

The milestones of Fig. 2 plus the systems compared in Tables 1–2, by year and map representation. Hover or tap a method to see its reference; click it to find it in the explorer.

Timeline of noteworthy collaborative SLAM methods from PTAMM (2008) to CoMA-SLAM and OminiMAG-SLAM (2026), ending with this survey. — Fig. 2 of the paper: timeline of noteworthy collaborative SLAM methods.

05 · Explorer

Explore the systems

Neural and Gaussian collaborative SLAM systems from Tables 1, 2, 4 and 5. Search, filter by representation or architecture, and click a row for the shared payload and reference. Press / to search.

Search systems Sort

System	Year	Representation	Architecture	Consistency	Descriptor	Input	ATE (cm)	PSNR (dB)

06 · Benchmarks

How do current systems compare?

Averages over the four ReplicaMultiAgent sequences (Office-0, Apartment-0, 1, 2), as reported in Tables 4 and 5. Systems without a reported average are left out.

Tracking errorATE RMSE, cm · lower is better

Rendering quality of the merged mapPSNR, dB · higher is better

Datasets used to evaluate CoGS-SLAM (Table 3)

Dataset	Domain	Environment	Input	Originally multi-agent	Used by

ReplicaMultiAgent is the closest thing to a common benchmark; real-world evaluation is still split across datasets, splits and protocols, which makes direct comparison hard.

07 · Applications

Where shared Gaussian maps help

08 · Open questions

What is still unsolved

09 · Cite

Citation

@misc{nguyenxuan2025collaborative,
  title         = {Collaborative SLAM in the Era of 3D Gaussian Splatting: Architectures, Methods, and Future Directions},
  author        = {Nguyen Xuan, Phuc and Nguyen Canh, Thanh and Nguyen, Huu-Hung and Chong, Nak Young and HoangVan, Xiem},
  eprint        = {2510.23988},
  archivePrefix = {arXiv},
  year          = {2025}
}