I’m using AddComponent<ARAnchor>() to add an anchor to an object used as root for others in my scene. After adding the component, the anchor seems fine, with its trackingState = Tracking. However, when I cover my camera until the tracking is lost and then uncover it, the ARAnchor state stays forever Limited, never going back to Tracking. When this happens, my anchor doesn’t move back to its original position as it should.
Sometimes (not always), right after reinstalling the app, the anchor works as expected - the state returns to Tracking after uncovering the camera, and it moves back to the right position. But this only happens in the first session after reinstalling, from the second on, the bug returns. I don’t have anything persistent between my AR sessions.
What could possibly make the anchor be forever stuck in the Limited state? The room I’m testing in is well lit and has lots of details.
No, I use a single scene. The AR starts disabled until the user presses a button, and I start it by enabling the ARSession game object arSession.gameObject.SetActive(true);. I only add the ARAnchor once the session is enabled.
I can’t provide full classes, but I don’t do much besides enabling the AR session and keeping track of ARSession.stateChanged to show relevant instruction UI based on the state.
yep, I don’t add it right away. I’ve also tried starting with the AR session enabled and only adding the anchor once the user clicks the button, but the result was the same.
I’m using AR Foundation 5.1.5, I’d need to upgrade to Unity 6000 to use AR Foundation 6
Curiously, I have a build from 3 months ago where the anchor works flawlessly. I tried downgrading my project to the same version as that build, but when I create new builds from it, the bug still occurs
I had a go at reproducing this, but interestingly, the ARAnchor is stuck on TrackingState.Tracking for me. This is on iOS running ARFoundation 5.1.5.
I get the ARAnchor’s added event => TrackingState.Tracking
Cover the lens until ARSession.state == ARSessionState.SessionInitializing (e.g. camera not tracking)
ARAnchor is still in TrackingState.Tracking.
Violent motion, lens covering, facing away from the anchor, leaving the app and returning…same thing.
The ARAnchor is successfully updating though, as scene understanding improves. Although rarely, and I think ARKit’s relocalization is infamously unreliable.
Polling the ARAnchor’s TrackingState in the Update loop, and anchorsChanged events for this.
That’s interesting, in my case I’m using Android, so I guess this state behaves differently for each platform. So far, I couldn’t reproduce this problem in other projects. When I build the sample Anchors scene that Unity provides, it works fine.
I’ve also used the Update and anchorsChanged event
The script ARPlaceAnchor.cs from arfoundation-samples, primarily attaches an anchor to the plane AttachAnchor(ARPlane, Pose). Otherwise the ARAnchor is added to a new GameObject with the ARRaycastHit’s Pose. It’s possible that these two methods works differently, as the first one is anchored to ARPlane, which is a type of Trackable and AFAIK updates similarly to an ARAnchor, while the latter is a Trackable of its own and can be created with any Pose. I found attach-anchors-to-planes helpful (from the ARFoundation 6 docs).
I haven’t tried attaching an ARAnchor to an ARPlane - I might try this to see it it changes anything.
I was able to get both TrackingState.Limited and TrackingState.Tracking on iOS for both ARAnchors (with AddComponent on a GameObject at a given Pose), and manually placed AREnvironmentProbes.
I don’t understand the exact conditions where an ARAnchor’s TrackingState becomes TrackingState.Limited on iOS. It only happened a couple of times for me, much more often with AREnvironmentProbes.
Regarding ARAnchors on Android, I’d double check the Pose where the ARAnchor is being created. I believe that ideally, the Transform of the GameObject holding the ARAnchor should be in the center of the ARCamera’s field-of-view when it is created. If it is created behind the camera, I think that might yield varying results.
I Hope it at least helps confirming that the TrackingState changes are working on iOS.
This behavior is controlled by ARCore itself. AR Foundation reports the tracking state to you, but ARCore controls it. In my recent experience, ARCore has great difficulty relocalizing anchors if tracking is lost. As an application developer you should expect that platforms may not be able to recover, and give users a way to recreate an anchor and delete the old one.
You could consider giving this feedback to Google. I suspect this issue is caused by different ARCore versions used by different versions of our Google ARCore XR Plug-in.
5.1.4 upgrades to ARCore 1.42
5.0.0 uses ARCore 1.31
Today I was able to reproduce this ‘bug’ many times in Unity’s sample app, so it really seems to be something with ARCore. I’m still intrigued about why it happens 100% of the time in some sessions, while in others it always relocalizes perfectly.
Anyway, it’s also good to point out that it’s not just an ARAnchor issue - it happens with all trackables in the scene.
