Lost anchors need recoverable relocalization
Aliases: tracking lost · recovering a lost anchor · limited tracking
What it is
Cover the cameras, or walk out and back in, and a menu that was nailed to a wall can vanish whole, or pop up on a different wall. Relocalization is the third path: admit the anchor cannot be found right now, enter a recoverable state, and when features match again put the content back at the original physical place — never substituting a wrong coordinate if it cannot be found.
Loss is a normal path. Recoverable means there is a walk from “cannot find it” back to “still on that wall,” not that loss is a crash or a cue to rearrange.
Why it happens
Once tracking loses its lock on the current map — lens covered, a featureless corridor, a whip-pan — the runtime can only coast or report an invalid pose. If anchored content is still drawn at the last good coordinate, it pins to the wrong place in the room; if it is stripped, people think it was deleted. ARKit marks this stretch relocalizing; OpenXR may keep serving a inferred pose while clearing the tracked flag. Both say: poses are still coming out, confidence is gone.
Recovery depends on seeing the original signature again. People need to be steered toward that patch, not left waiting in place. When recovery fails, the honest fallback is “this anchor is unusable for now; re-pin?” — not leaving the object on an inferred coordinate and pretending it is still true.
Studying it
Run a lose–recover protocol: after placement, manufacture loss by covering the cameras, leaving the room, or entering a weak-texture stretch. Record time to loss, whether relocalization succeeds, pose error against a real landmark after recovery, and whether people read the stretch as “searching” rather than “gone.” ARKit TrackingState and ARCore failure reasons are process tags; the dependent measures remain whether the object returned, and whether people clicked in error.
Independent variables: cause of loss, duration of loss, whether the original surface was in view at re-aim. Dependent variables: relocalization success rate, post-recovery pose error, mis-clicks during the lost stretch.
A brief tracking dropout inside the same volume should not be treated as a loss that needs re-pinning. Split short dropouts from losses that actually need relocalization.
Where it stops holding
Desktop tasks that never leave the tracked volume and always have features rarely walk this branch — a sleeve over the camera still will. 3DoF has no position to lose, so the leaf does not apply. Killing the app and reopening is re-entry, not in-session relocalization; do not merge the two into one prompt. A successful recovery whose pose is already off is drift, not “still not found.” If the original surface has been carried away, relocalization will fail indefinitely; the path then is re-pin, not an infinite spin.
Applying it
- On loss, enter an explicit “looking for this room” state. Hide or freeze the content; do not keep taking input at inferred coordinates.
- Prompt people to look at the featured patch where it was placed (that door, that table). The prompt must be a heading they can take, not “please wait.”
- If the timeout cannot find it, offer “re-pin here” and “don’t show it,” and do not dump the object dead ahead of the current heading as a fake find.
- How to check: after placing, cover the cameras for ten seconds and uncover. The object should reappear in place, or the “searching” state should be up. If it jumps to another wall and is still clickable, loss was treated as a valid pose.