MASt3R-Fusion
Zhou 2025 · Paper
One-line summary — Tightly fuses the MASt3R feed-forward visual model with IMU and GNSS measurements in a hierarchical factor graph, giving foundation-model dense SLAM metric scale and global geo-referencing.
Problem
Classical visual SLAM “often struggle[s] with low-texture environments, scale ambiguity, and degraded performance under challenging visual conditions”; feed-forward pointmap regression (MASt3R) fixes much of that by recovering high-fidelity geometry directly from images. But these new pipelines discard “the widely validated advantages of probabilistic multi-sensor information fusion”: no metric scale from an IMU, no absolute geo-referencing from GNSS, no principled uncertainty bookkeeping. MASt3R-Fusion asks how to couple a feed-forward visual model tightly with inertial and GNSS sensing rather than post-hoc.
Method & architecture
Two stages: real-time SLAM (sliding-window VIO with a feed-forward frontend) and global optimization (loop closure + GNSS over the full trajectory).
Feed-forward visual measurement. Following MASt3R-SLAM, each image is encoded to tokens , and pairs are decoded jointly into pointmaps and descriptor maps
where are 2D-to-3D pointmaps in the reference frame of . Dense matching is done by ray-proximity optimisation over the pointmaps, then refined with descriptor dot-products and a 4x bilinearly upsampled descriptor map for sub-pixel accuracy; correspondences with large depth residuals are masked out, which also rejects dynamic objects.
Sim(3) pointmap-alignment constraints. Each keyframe carries a pointmap and a camera-to-world similarity (scale , rotation , translation ). For a matched pair, the residual combines reprojection with known depth and a depth term for pure-rotation cases:
with the relative Sim(3) transform. Unlike bundle adjustment, no per-point depths are optimised — the network’s 3D structure is trusted up to scale, so visual constraints become compact pairwise factors. Each dense constraint is compressed on the GPU into Hessian form , — just a block per pair handed to the CPU solver.
Isomorphic group transformation. To fuse with metric-scale sensors, Sim(3) is factored as , and the Lie-algebra perturbations are related linearly by
so Sim(3) visual Hessians attach directly to SE(3) poses plus a per-keyframe scale .
Sliding-window factor graph. The window state is — SE(3) pose, scale, velocity, IMU biases — in float64 (dense GPU work stays local in float32). Standard IMU preintegration factors link consecutive keyframes, and old states are marginalised via Schur complement into a prior . The real-time cost is
Global SLAM. Loop candidates come from feed-forward encoder-token retrieval, filtered by an efficient VIO-uncertainty test (distance uncertainty from along-track/cross-track error propagation) before expensive dense verification. GNSS positions enter as factors tied to keyframes via temporary IMU preintegration nodes to handle time offsets. A two-step global optimisation first uses Cauchy-robustified relative-pose loop constraints, then swaps inlier loops to full Hessian-form visual factors — keeping all V-I information instead of collapsing to a pose graph.
Results
- KITTI-360 (monocular VIO): average relative translation error is 43.0% lower than DM-VIO and 17.7% lower than DBA-Fusion (e.g., highway seq 0003: 0.406% vs 1.146%/1.041%); visual-only MASt3R-SLAM essentially fails at this scale (RTEs of 21–55%).
- KITTI-360 (global SLAM with loop closure): normalised ATE of 0.05% of trajectory length vs 0.63% for ORB-SLAM3 and 2.91% for VGGT-Long — e.g., 2.13 m ATE over the 8.4 km seq 0000 vs 26.03 m (ORB-SLAM3) and 103.64 m (VGGT-Long).
- SubT-MRS (caves, mixed indoor/outdoor): VIO ATE 0.23% of length vs 0.41–1.74% for DBA-Fusion/ORB-SLAM3/DM-VIO; with loop closure 0.13% vs 0.37% (ORB-SLAM3), while visual-only VGGT-Long fails on all three sequences.
- Wuhan urban dataset (V-I-GNSS): with real GNSS RTK, horizontal RMSE 0.21 m / 0.09 m on the two sequences vs 2.54/0.62 m for VINS-Fusion’s loose global fusion; under simulated 100-second GNSS outages it keeps 0.37/0.46 m RMSE.
- Runs in real time on a laptop RTX 4080 Mobile GPU and handles arbitrarily long sequences in 8 GB of GPU memory. Code: GREAT-WHU/MASt3R-Fusion.
Why it matters for SLAM
MASt3R-Fusion demonstrates that 3D foundation-model front-ends are compatible with the classical multi-sensor factor-graph machinery that production systems rely on — you do not have to choose between learned dense geometry and rigorous sensor fusion. The Sim(3)-constraints-into-SE(3)-graph device (via the isomorphism) is the key pattern to remember: it is how scale-ambiguous learned geometry gets grounded by metric sensors. It points at where deployed SLAM is heading: feed-forward models for perception, factor graphs for estimation, absolute sensors for grounding.