Didn't find the anchor

[BartJV]

Description

I'm having a tough time locating anchors consistently on Hololens 2 When I locate an anchor (ID from file) the first time, the anchor is correctly found and placed in my world.

If I attempt to look for it again, I get LocateAnchorStatus.AlreadyTracked, but often the CloudNativeAnchor:CloudToNative(CloudSpatialAnchor) call results in "Didn't find the anchor". This is similiar to another bug on here (#157,#121) but I am already using CloudManager.AnchorLocated += OnCloudAnchorLocated; rather than session, and not removing callbacks.

If I then create a new anchor, and look for it again, subsequent "AlreadyTracked" notifications are fine, and have a correct anchor associated.

Steps to reproduce the issue

Expected behavior

Upon receiving a AlreadyTracked call, a valid cloud anchor is expected. If no valid anchor was found, I expect NotLocated In the error instance we are seeing, I would expect some error code be raised, rather then an identity pose and no indication of a fault.

Screenshots

Development information (please complete the following information)

• OS: Windows
• Unity 2020.3.8f1
• Azure Spatial Anchors SDK version: 2.10.2
• MRTK 2.7.2, ARFoundation 4.1.7

AR Device information (please complete the following information):

Hololens 2

Additional context

[VipulKakkad-MSFT]

Hey @BartJV,

"LocateAnchorStatus.AlreadyTracked" status code indicates that this anchor is already being tracked on the native platform, and it is being returned from this client-side cache, and not being relocalized with fresh visual data. If you're looking to localize the anchor again (say, because you're now closer to the location of the anchor), then set the "BypassCache" property to ensure that it doesn't get returned from the local cache.

We're looking into why the SDK returns an identity pose and logs the "Didn't find the anchor warning" in this case, but I hope this helps clarify things in the meantime.

[BartJV]

Thanks @VipulKakkad-MSFT . Yeah, it being tracked already is fine, its the fact it doesn't return the previous answer that surprised me. I'd rather not cache them myself obviously. I'll use the bypass cache for now, and just deal with the extra time delay.

Thanks!

[VipulKakkad-MSFT]

Hey @BartJV,

A follow-up: while the BypassCache solution will work, it's worth noting that it may have other consequences than just added latency, since it will relocalize the anchor again with new visual data, and may give you a slightly different location for it, or even fail to relocalize it if the user is no longer looking at an area with visual similarity to where the anchor was created.

For anchors that are AlreadyTracked, the current best practice would be to cache them with spatial anchor ID as the key. In the meantime, we are tracking a bug in our SDK (internal tracking number 36539781) for why an AlreadyTracked anchor logs that warning. Thank you for bringing this to our attention!

[phamqduc]

Hi @BartJV , we'd like to let you know that ASA SDK 2.11.0 was released recently that addresses the bug 36539781 mentioned above. Please give SDK 2.11 a try and let us know if you still have any concern. Thanks.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.