Cloud anchors let different devices at different times see the same content at the same place

What it is

A label pinned to a vitrine with a tablet in the morning is still on the vitrine rim when a colleague walks in that afternoon on a different headset. What makes that possible is not a pose stored on the first device. It is cloud anchors: visual features of the place are uploaded, later devices download them and relocalize, and only then does the same content appear at the same physical point.

The same device finding its place on next boot is local relocalization. Cloud anchors are across devices and across time: still here.

Why it happens

A device builds a short local feature map and uploads descriptors plus the anchor pose. A later device matches its live view against that cloud map, recovers its own 6DoF in the map, and puts content back in the same world frame. What was uploaded is a matchable appearance, not a snapshot: change the lighting, the crowd, the hang of the show, and matching fails — the locator returns failure, not a “close enough” point.

The time gap is what separates cloud anchors from same-session alignment. Same-session alignment can use a marker both people see, or a short-range handshake. Hours later, different person, no shared session: the retrievable map is the only join. If the map never covered a viewpoint — a sweep from the door, never around the case — a later device entering from the side will miss, pin content across the hall, or show nothing.

Studying it

Cross-device revisit: device A places at t0; devices B and C hours later, from different doors, try to resolve the same anchor. Record localization success and translation/rotation error against a real fiducial.

Factors: device-model gap, entry viewpoint, elapsed time, whether the cloud map contains that viewpoint. Scores: resolve rate, position error, scan-to-appearance latency, whether failure says “place not found” rather than misplacing.

Retesting on one device within five minutes measures local tracking, not cloud anchors.

Where it stops holding

No network, an isolated intranet, or a deleted cloud map makes cross-device revisit fail outright; a pre-downloaded offline pack or an on-site QR code has to catch it. Highly repetitive corridors and blank gallery walls lack distinctive descriptors; a large cloud still matches unstably. When several stale maps index the same place, a later arrival may resolve yesterday’s layout. Simultaneous multi-user alignment is a different job: those people need their local frames merged into one shared frame, not the same anchor fetched overnight.

Applying it

• Treat “someone else can still see this here tomorrow” as a cloud-anchor workflow: force a multi-view scan at placement, and on resolve failure say “could not localize this place.” Never drop content silently at the default origin.
• Keep one authoritative map per venue so the same gallery is not indexed by several maps that refuse to recognize each other.
• Offline, switch to a printable locator or a preloaded map pack. Do not pretend the cloud will always be there.
• How to check: place with device A, wait two hours, enter with device B through another door. Content should land within centimetres to a decimetre of the original mark. Landing across the room, or vanishing with no failure cue, means the cloud-anchor chain never closed.

Related

• Same group：N5.09.2 Persistent content must be periodically re-matched to the environment to stop long-term drift · 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：cloud anchors · cross-device relocalization · spatial map sharing