Persistent content must be periodically re-matched to the environment to stop long-term drift
Aliases: map maintenance · periodic relocalization · anchor re-alignment · drift closure
What it is
A label sits on the vitrine rim on day one and on the door handle three months later — no wall came down, no lamp changed; visual–inertial residuals, dust, and chairs that crept a little stacked night after night. Anchor rematching is taking the live view against the stored map again on a schedule, clearing accumulated drift, rather than treating the first lock as forever.
This is maintenance, not “void after a renovation.” Structural change is an invalidation decision. Rematching is the slow crawl in a room that still looks like itself.
Why it happens
Visual–inertial odometry is usually stable inside a session; sessions join on feature matches. Each join’s residual is not zero: morning-to-afternoon light, glare on the glass, a body walking past will pair descriptors with a “close enough” other set of points. If residuals are stored and never reconciled, the anchor crawls millimetres to centimetres a day in one direction. The eye misses it for days; months later the content has left the edge it was pinned to.
Rematching is an explicit loop closure: update the anchor pose in the map from the current observation, or update the map and back-solve the content. Without that loop, persistence writes the first error plus every later seam to disk. Too rare, and drift is already large enough that matching fails; too often, and each match’s jitter is written into the content — the label shivers on the rim.
Studying it
Long-horizon revisit: control points in the same room, sampled daily, weekly, monthly, no structural change, only natural light and slight furniture motion. Compare never-rematch, rematch-on-cold-start, rematch-on-drift-threshold.
Time factors: days elapsed, lighting-slot difference, mild layout shift or not. Observations: anchor translation against control points, rematch success, visible content jitter, counts of a mismatch jumping the label to the opposite wall.
A thirty-minute lab session cannot see this curve. Cross at least one day–night cycle.
Where it stops holding
A fully static bench that re-origins from the same marker every time gains little from rematching. Feature-starved spaces (corridors, blank walls) will jump under rematch, which is worse than a slow crawl; close the loop on a fixed fiducial instead. Once structure has changed (a partition down, a case replaced), do not rematch the old map — that forces the new room into the old coordinates. With several people present, rematch on the shared frame; otherwise each person’s private “correction” splits one label into several.
Applying it
- Give persistent content a rematch cadence: once on every cold start, and again daily or weekly in a long-running venue. On failure, freeze the content and say “needs realignment.” Do not keep drawing at the old coordinates.
- Damp or threshold a single match’s pose update so the label does not jitter in successful-match noise.
- Put control points (a fixed hook, a landmark) in the venue config as rematch ground truth. Do not let the feature cloud only agree with itself.
- How to check: photograph the same label at a fixed clock time for four weeks and measure offset from the vitrine rim. A monotonic climb past the task’s error budget means rematching is not working; a jump to the other wall means a mismatch was accepted as a correction.
Related
- Same group:N5.09.1 Cloud anchors let different devices at different times see the same content at the same place · N5.09.3 Anchor lifetime needs an explicit policy, not a permanent-environment assumption · N5.09.4 Merging several local frames into a shared frame is the premise of multi-user persistence · N5.09.5 After a structural change to the environment, old anchors should be invalidated, not silently kept
- Nearby:N5.04 Spatial Anchors · N5.05 Shared Space
- Search terms:
anchor rematching·map maintenance·long-term SLAM drift
Cards in the same group
- N5.09.1Cloud anchors let different devices at different times see the same content at the same place
- N5.09.3Anchor lifetime needs an explicit policy, not a permanent-environment assumption
- N5.09.4Merging several local frames into a shared frame is the premise of multi-user persistence
- N5.09.5After a structural change to the environment, old anchors should be invalidated, not silently kept