A deliberately small working memory
The DA3-Small front-end has 80 million parameters. It uses an anchor keyframe and the two most recent frames to estimate each new pose. Back-end estimates repeatedly re-anchor it to reset local drift.
How AMB3R-SLAM turns a moving camera’s video into a coherent 3D map—even when the journey stretches for kilometers.
A visual guide to Hengyi Wang & Lourdes Agapito’s paper
University College London · arXiv:2609.19518v1
A small front-end keeps up with new frames. A stronger back-end relates parts of the journey to one another, limiting the drift that accumulates over time.
SLAM means simultaneous localization and mapping: estimating where the camera is while building a map of what it sees. Tiny motion errors add up. This paper’s central contribution is a hierarchy of constraints that brings the journey back into agreement.
A fast front-end follows the incoming video. Each local estimate can be reasonable, yet small errors accumulate along the journey.
Local submaps overlap their next two neighbors (stride Δ = n/3). These span-2 links supply more geometric agreement than a simple chain.
Sparse keyframes across several submaps provide longer-range links, even before a physical revisit. Confidence and co-visibility checks decide which edges enter the graph.
When a previously visited place is recognized, geometrically verified loop edges constrain the graph. Optimization distributes corrections across the journey.
Conceptual animation. Node positions and correction amounts are illustrative; this is not a SLAM implementation.
The DA3-Small front-end has 80 million parameters. It uses an anchor keyframe and the two most recent frames to estimate each new pose. Back-end estimates repeatedly re-anchor it to reset local drift.
The back-end uses a Sim(3) pose graph: it reconciles relative translation, rotation and scale. Translation residuals are normalized by baseline distance, and a Huber loss limits outlier influence. It does not perform traditional pixel-reprojection bundle adjustment.
Here, “front-end” and “back-end” are parts of a SLAM algorithm. They do not mean a web interface and a cloud server: the reported system runs on one GPU.
Original explanatory diagram based on §§3.1–3.2. The arrows describe information dependencies, not a documented message API. Animation timing is illustrative.
The current RGB image enters the tracker. The same video also supplies a sliding window for mapping. The stages work with different amounts of context.
Current frame Iₜ + the video frames available for the mapping window.
Per-frame tracking; mapping windows are constructed every Δ frames.
DA3-Small combines the new frame with an anchor and the two most recent frames. It estimates where the camera moved and resolves local scale using a robust scale solver.
Compact image memory → camera-pose estimates and confidence.
Pose = camera position and orientation; monocular geometry also requires scale alignment.
The back-end groups frames in time and selects the highest-confidence view in each group. Confidence from the front-end helps it spend reconstruction effort on the most reliable views.
Front-end confidence + corresponding RGB views from the mapping window.
Images provide geometry; confidence guides selection. This is an information flow, not a specified network packet.
A larger model reconstructs overlapping submaps. Span-2 edges, sparse long-context constraints and verified loop closures connect them. A Sim(3) pose graph reconciles translation, rotation and scale.
Selected images → geometry, relative transformations, verified graph edges and corrected poses.
Different constraints operate at different spans; a loop edge requires a verified revisit.
Back-end estimates re-anchor the tracker so new poses start from a corrected reference. Corrections also propagate across the trajectory, with weighted pose averaging in overlapping windows.
Corrected pose / alignment / scale → updated tracking anchor and corrected trajectory.
The next frame continues the same cycle. Re-anchoring is not retraining the neural network.
For a new image, it uses a compact memory: an anchor keyframe and the two most recent frames. It estimates camera pose and solves local scale. Its confidence guides the back-end’s choice of which images to reconstruct.
It reconstructs selected views in overlapping windows, aligns submaps, adds longer-range constraints and verifies revisits. Pose-graph optimization adjusts camera relationships; corrections propagate to frames and re-anchor subsequent tracking.
| Direction | What information? | Why it matters |
|---|---|---|
| Camera → both stages | RGB frames: the current image for tracking, and a window of images for mapping. | The back-end needs actual views to reconstruct geometry; a stream of poses alone is not enough. |
| Front-end → back-end | Per-frame confidence, associated with the tracked views. | Within temporal groups, the back-end chooses the highest-confidence frames and interpolates intermediate poses. |
| Back-end → front-end | Back-end pose/alignment estimates, including the relevant scale correction in monocular operation. | Re-anchor tracking in the corrected coordinate frame and reset accumulated local drift. |
| Back-end → map & trajectory | Reconstructed geometry and corrected camera poses across the sequence. | Make local observations agree across overlapping windows and long journeys. |
Source: §3.1 Front-end, §3.2 Hierarchical Backend, and Figure 2. The paper specifies the algorithmic dependencies; exact software payload formats and scheduling are not detailed here.
Absolute trajectory error (ATE) measures the difference between an estimated path and the reference trajectory after alignment. Lower is better.
On the Bonn dynamic dataset, the default system reports 1.3 cm average ATE versus 2.3 cm for WildGS-SLAM (Table 8). It optimizes camera-pose relationships and uses learned geometry priors, without explicit motion segmentation.
The complete monocular system runs at 17.6 FPS on KITTI and 10.2 FPS on VBR on an RTX 4090. Peak GPU memory is 10.3 GB and 14.0 GB, respectively (Table 9). Faster front-end-only numbers are not whole-system throughput.
The ablation study switches off components on VBR. W-AUC evaluates trajectory segments; a higher percentage is better. Select curves to compare.
Hover or focus a point for the exact reported value.
Categorical x-axis: window lengths are not equally spaced distances. “Full” denotes full trajectories. Values from Table 10.
A single camera cannot directly observe absolute metric scale. Extra sensors change how the system constrains geometry.
The foundation model estimates poses and depth from images. Relative scale remains a degree of freedom, so the back-end aligns position, orientation and scale between submaps.
RGB-D depth, or depth from calibrated stereo matching, calibrates each submap with a robust median depth ratio. Relative scale is fixed to 1, leaving rigid pose optimization.
ICP supplies relative poses. For loop closure, the geometric model initializes alignment, followed by ICP refinement. Registration quality controls the weight of each loop edge.
Tables 2, 4 and 6. LiDAR values shown use the paper’s Sim(3)-aligned ATE; KITTI’s SE(3)-aligned value is 1.01 m, versus 0.95 m with Sim(3) alignment.
The authors' own figures show the real system and its qualitative results. They are published under the arXiv distribution licence, so they stay at the source — open them alongside this page.
The authors report that duplicated surfaces and ghosting can remain in ambiguous regions. Accurate tracking does not automatically yield a clean, unified 3D model.
Stereo, depth and LiDAR are integrated at the system level. The geometric foundation models still take RGB images, rather than conditioning natively on every sensor.
The paper evaluates nine datasets on GPU hardware. It does not establish browser or phone performance, universal robustness, or a ready-to-use indoor positioning service.
Based on: “AMB3R-SLAM: Kilometer-scale SLAM with Hierarchical Backend,” Hengyi Wang & Lourdes Agapito, arXiv:2609.19518v1, 17 September 2026. The paper’s own figures are linked, not reproduced. Charts here reproduce selected reported values; animated scenes are explanatory illustrations. Independent visual explainer, not an official project page.