ASA appears to add many ARAnchors at the start of the session

[mschult2]

Description

According to the ARAnchorManager.anchorsChanged event, as soon as I create and start the ASA session, many ARAnchors are added. I don't think my code could be doing this, and the only other culprit is ASA.

Details: I have an ASA service with many anchors stored on it. I am not "locating" spatial anchors when this issue occurs, but in previous app runs I have located spatial anchors with the unusual criteria of BypassCache=true, and of course a list of Identifiers. (probably unrelated) Dozens of ARAnchors are added as I look around the room, as if it's recognizing stuff.

Is this expected? Perhaps my understanding of how ASA works is flawed.

Impact

Memory consumption increases by about 40 MB (when viewing one 10x10ft room). You can imagine walking around a multi-room space; it's possible a mobile app would run out of memory and crash.

Steps to reproduce the issue

1. Start my app
2. App creates/starts ASA session (issue will not occur if this step is removed)

Expected behavior

No ARAnchors are made. As I understand it, ASA is supposed to only make ARAnchors if I invoke SpatialAnchorManager.Session.CreateWatcher(criteria), but I'm not doing that here.

Development information (please complete the following information)

• iOS (ARKit)
• Unity 2022.1.17
• Azure Spatial Anchors 2.13.3
• ARFoundation 4.2.7

AR Device information (please complete the following information):

• iPhone 12 Pro
• iOS 16.13.1

[mschult2]

Also note that CloudSpatialAnchorSession.IsLocating is false.

And if I delete these ARAnchors, ASA simply creates them again, ad infinitum.

[mschult2]

It looks like this happens on my Android device, too.

[darax]

Hi @mschult2 ASA does create anchors even if there is no watcher. This is to reduce the amount of scanning time required to create an anchor, should one need to be created.

[mschult2]

I see, so it doesn't have anything to with spatial anchors already saved to the ASA service.

Is my workflow correct then? -I create one ARAnchor, I add a CloudNativeAnchor to it, I add a CloudSpatialAnchor to that, and save it to the ASA service. I can then load that spatial anchor in a new app run, at which point an ARAnchor gets automagically created and attached.

At no point in the save process do I interact with these ARAnchors being made under the hood. Is the load process grabbing one of the ARAnchors made under the hood? Is that what they're for?

[darax]

that sounds right. The loading process creates an ARAnchor based off of visual information in the cloud compared to visual information seen locally in the current session. Under the hood we use the other ARAnchors we are creating to establish a relative pose between what we call a 'query anchor' and the calculated position. To keep it simple for the SDK, we create a new anchor at that position. There are subtle differences between iOS, Android, and HoloLens (even with ARFoundation) so we've tried our best to hide this in extension methods.

[mschult2]

Cool, everything is working great then. I'm able to save ASA anchors for an entire floor, and then restore them on both an Android phone and an iPhone. Btw I used to work on the HoloLens team :D

While I have you, some other things I'm curious about, then I'll close out:

1. Are you guys still working on ASA? Are you going to add other platforms?

2. How do I make a bunch of ARAnchors, then save them all at once? If I create a bunch of ARAnchors (immediately invoking CloudNativeAnchor.NativeToCloud() on each one), then save them all at the end via SpatialAnchorManager.CreateAnchorAsync(), the result is I can only locate these ASA anchor IDs by standing in that one final spot where I saved all of them. Which is also the spot of the last ARAnchor, if that's relevant. But I feel like I should be able to locate any of these ASA anchor IDs by standing at the spot where the anchor is supposed to be. My current workaround: make an ARAnchor, then immediately invoke SpatialAnchorManager.CreateAnchorAsync() to save it to the cloud (because I'm still standing in the same spot, I suppose), then rinse and repeat. This allows me to locate the entire set of ASA anchor IDs while standing at any of the anchor spots, which is good. But it also means I feel compelled to go back and delete the saved ASA anchors if the app exits (such cleanup being an ASA recommendation).

[Varnauld]

Hi @mschult2 - I believe you are now connected to our Azure Spatial Anchors team who can discuss your first question here. On the second one, re-tagging @darax to help address, thanks!

[mschult2]

Great, thanks!

[darax]

@mschult2 I missed the second question. There isn't a 'batch' method of saving anchors to the cloud. Your rinse and repeat methodology sounds correct. Instead of deleting all the anchors, perhaps maintain a set of anchors in a grid, 5 meters apart. The issue of too many anchors is most severe if you are using coarse reloc.

[mschult2]

Great, thanks for the info!