VPS needs to return an ID for the wayspot that has been identified

I'm Stuck
1

In ARDK the WayspotAnchors example successfully allows you to place, save, clear, and load anchors in relation to a wayspot.

However, the example will also place those same anchors on top of any wayspot you localize to. It appears there is currently no way to verify what wayspot you’ve actually localized to. The accuracy of your localization will be right on, but the accuracy of the information that gets associated with it will only be as good as your gps and best guess.

I asked an engineer and got this response:

The Wayspot information is provided via the coverage API, so you’d have to get the Wayspot identifier based on the users proximity to a Wayspot based on the coverage API.

If this is indeed true, then VPS is pretty broken on launch which is frustrating because the private beta version worked flawlessly and easily. What was once one step will now require new code to build another layer of localization based on GPS and plugging into another different API that I don’t actually need or want to use. What was once immediately apparent is now buried behind multiple layers of abstraction and unreliable even in the best case.

5 Likes
2

Hi Sam,

We tested creating, saving, and loading anchors at two separate localization points using the WayspotAnchors scene found in the ARDK Example Scenes 2.0 package. The first localization point tested was a public VPS-activated wayspot and the second was a private scan, and we were unable to reproduce the issue — each localization point was able to save and load distinct anchor payloads.

Can you confirm that you’ve experienced issues with creating, saving and loading anchors at separate localization points using the WayspotAnchors example scene? And if so, would you mind providing information about the package versions you’re using, as well as your Unity version?

Also, the updated method of locating wayspots shown in the Using the VPS Coverage API documentation allows for greater flexibility as mapIDs and map nodes could be eliminated as maps get updates. The new method of locating the wayspots prior to localization is meant to address this issue.

1 Like
3

The issue I am having is that there appears to be no way to determine anything about what wayspot you have successfully localized to. I can’t figure out any way to actually verify which wayspot the user has localized to.

I don’t necessarily want to follow the flow of showing the user what to point the camera at first and then relying on them to do it. This approach is prone to errors. Specifically, if there is more than one vps wayspot nearby the accuracy of gps may not be high enough to verify which wayspot your user has localized to. A user could break things by localizing to incorrect wayspots that are nearby/within the margin of error of gps.

An anchor will load regardless of which VPS wayspot you have localized to.

To reproduce this issue:

  1. Find two wayspot vps points within the gps margin of error.
  2. Localize to wayspot A. Place and save an anchor.
  3. Localize to wayspot B. Reload your anchors. They appear and are not correctly placed.

The wayspots don’t actually need to even be close to each other. The example as implemented will identify any vps waypoint anywhere and reload the anchors you have saved in some arbitrary incorrect location.

In short: the accuracy of vps relies on gps and users not breaking things. GPS is not accurate enough to differentiate between wayspots. Users will break things 1,000 times before they even do it the way you intended.

Proposed solution:

Option 1: Return a unique ID and a reliable origin anchor. It’s position doesn’t matter as long as it’s the same every time.

Option 2: Wayspot anchors should not load successfully when trying to load based off of a wayspot different than the one they were placed.

Forgive me if I am missing something obvious here.

4

Hi Sam,

We appreciate your patience as we look into the issue of localizing against two wayspots in close proximity. It may require a little extra time to diagnose and test as the reproduction steps have specific physical requirements.

As for not wanting to follow the flow of having the user point their camera at the localization target… that’s going to be a hard-and-fast requirement as VPS requires visual input from the camera in order to orient the device within the world and scene.

I will update this thread when more information about the above issue becomes available.

5

As for not wanting to follow the flow of having the user point their camera at the localization target

That is not the flow I am referring to. Obviously a visual positioning system is going to require visual input. The flow I am referring to is this, as proposed by niantic:

  1. Go to a VPS activated Wayspot (guided by the VPS Coverage API)
  2. Start VPS localization (no map specified, VPS will attempt to localize device with any maps in vicinity).
  3. Create and/or resolve WayspotAnchors. These are what you should be “anchoring” your experiences around (ie link game content to a WayspotAnchor instead of to a map identifier).

Step 1 requires me to guide a user to a specific location before localizing them. This is backwards. I want the VPS to tell me where I am. I don’t want to have to tell the VPS where I am and then have it just trust me so long as it can reach a state of “localized” anywhere.

Step 2 points out that this is by design. The VPS will attempt to localize to any maps in the vicinity. What is that vicinity exactly?

It may require a little extra time to diagnose and test as the reproduction steps have specific physical requirements.

As I stated before, you can repeat this bug with any two VPS wayspot anywhere regardless of vicinity. Load the demo scene. Place anchors. Save Anchors. Go localize to any other scene. Reload anchors. They will appear and they will be wrong.

Niantic proposes that we build our own gps-based geo-fencing system to try to guess at what wayspot has been localized (this is what I was told at the summit). What I am pointing out is that such a system would not be reliable as it would have to be based off of gps and would fail when multiple wayspots are “in the vicinity.”

The issue doesn’t necessarily have to do with proximity, just that the proposed workaround would not work due to proximity and the paradoxical design choice to make us rely on GPS to try to localize to ~cm accuracy. The issue is the wayspots provide no meaningful information off of which we can build or confirm what wayspot has been scanned.

IMHO the VPS works beautifully but the implementation is fully broken and backwards. I can’t rely on players in a competitive game to just not scan the wrong vps point on their honor, as an example.

Lastly, I have three wayspots I can localize to without standing up from my desk. You can follow the documentation here to make your own as well. VPS provides no way to differentiate between them. Again, we are being required to tell VPS where we are when it should be able to tell us.

Working around this issue is requiring a huge amount of development time and I am being forced into a user flow I don’t want to implement or use. I have my own ideas.

7

I realize that there is some misunderstanding around all these terms and I’m not the best communicator, so I’m going into verbose mode to try to reach mutual understanding with the Niantic team.

What I would like to get back from VPS is localization state, unique ID associated with wayspot, and a reliable 0,0,0 origin tied to it.

As far as I can tell in the current implementation the visual positioning system returns no actual positioning data. It only returns a true/false state for “localized.” The positioning data seems to be obfuscated behind the black box of the anchor object and whatever that serialized chunk of text is that we have to save.

Scenario:

I am building an interactive RPG-type experience. I am the editor working on a scene at a graveyard. I go to a wayspot and localize using a custom app [I’ve] prepared. I want to place an asset that will be persisted later for others to see.

Option 1: Using wayspot anchors:

  1. Build an interface for placing and saving anchors
  2. Implement some kind of web hosting solution to store the persisted data
  3. Build out the networking required for communicating with web host and sending/retrieving the data
  4. Create a user flow that instructs users exactly where to go using an image and text
  5. Create a geofencing system of some kind using GPS to query which wayspots are in a user’s vicinity
  6. Implement communication with the wayfairer API
  7. Load anchor
  8. Implement asset relative to anchor
Summary:

Steps 1 seems unneeded. Each wayspot is already associated with one listing in the wayfairer API. There is no need for more than one anchor to be associated with it. I shouldn’t have to make it. It should just be there.

Steps 2-3 are troublesome both in implementation time and introducing further ongoing hosting and server management costs. This limits the potential persistence of an experience.

Step 4 is a paradigm that Niantic uses and is great, but I have other things in mind.

Step 5-6 must be implemented because there is no way to >>verify<< (programmatically) which wayspot has been scanned. A best guess must be made. You must either 100% rely on the user to do everything correctly or you must rely on a best guess from GPS as to which wayspot is closest. In this case you must also implement step 6.

Step 7 is again confusing. There is one listing for a wayspot in the wayfairer API. Why do we need multiple anchors associated with it? We only need one anchor - a reliable origin from which to reference. In this case we have to create the origin ourselves. Feels like a wasteful API call and potential point of failure.

Step 8 Finally l can load the asset into the scene and record its placement relative to the anchor.

I am currently working on implementing this approach. I think it will take me 5-7 days to get a basic working demo done another 5-7 days to refine and bug fix. In the end I will have spend two or three weeks and the solution will still not allow me to validate my vps localization and will be prone to errors or cheating.

Option 2: Using a unique ID and reliable origin

  1. Implement any kind of user flow you want
  2. Implement scene relative to wayspot
Summary:

Step 1 I’d rather show than tell, but I have lots of ideas that don’t work well with being directed by an image, text, audio instruction or otherwise.

Step 2 Off to the races.

If I am localized then implementation is done. So… an hour or two max?

Conclusion:

With option 2 there is no need to implement storage APIs, buy and manage cloud storage, talk to wayfairer, build a geo-fencing query bounding system, rely on correct/honest user input, or build and manage the systems around anchors. No servers of any kind are needed as all content can be baked in. The only network communication needed is the localization call. All of these things are clear advantages.

An example scenario I might want to implement would be “objective: explore this section of the graveyard to discover 5 spirits and their stories.” That will fit the design of my experience much better than “go here and look for this gravestone, go there and look for that one, look here’s a jpg so you can’t discover it on your own.”

With option 1 this scenario would be impossible to implement. Users would begin to explore the graveyard, localize, and get the wrong point loaded because there is another one a few yards away. VPS provides no localization data, only localization status.

With option 2 I could implement this scenario as well as niantic’s proposed user flow as well as many other options.

Option 2 is the clear winner.

Please provide a unique ID associated with each wayspot and a reliable 0,0,0 origin attached to it. Thank you!

8

Now that I’m finally getting successful localization at all in my test project, this is very much an issue. Particularly since, during development, we can’t always (or ever, in our area) use approved public VPS-enabled wayspots, and Private Wayspots aren’t even accessible via the Coverage API.

In my current demo, we’re looking to pre-pack several anchor payloads for several different sites with the expectation that when the user examines a designated site, they will get content keyed to that site. What we’ve been advised so far is to pre-attach an anchor to each wayspot and make a determination based on whether or not that anchor successfully restores, but if, as Sam_Garfield reports (contrary to my interpretation of my own observations, but on second glance, my code is structured in a way that would mask this if it is occurring) ALL anchor payloads do restore successfully on ANY wayspot, this approach would become entirely impossible.

My original interpretation of my observations, in case it helps, is that while all valid payloads will succeed through WayspotAnchorService.RestoreWayspotAnchors (aside: a single invalid/malformed payload in the array will throw an exception and abort the whole process…), it was only returned anchors actually bound to the current wayspot which would receive TrackingStateUpdated events. I still think that might be the case, but I’d need to do further testing, and if I’m wrong, it would explain why anchors placed on Private Wayspots we’ve done multiple scans of might be coming back entire feet away from their placed locations even with accuracy requested to 1cm: rather than the API being unable to remotely meet that 1cm ask, we may just be placing with 1cm accuracy against the wrong wayspot entirely with no way to know this!

2 Likes
9

…or, it occurs to me, we may be coming at this from entirely the wrong direction, having been previously corrupted by the ideas of e.g. marker-tracking wherein there is an absolute local origin against which everything can resolve.

If I were Niantic, and I were dreaming BIG, I would probably be dreaming of a future world entirely without wayspots, where everything was just one enormous contiguous localizable mesh. And if I were that Niantic, I would absolutely propose and support pivoting the API in advance to completely abstract away from explicit wayspot IDs and leave it to the developer to place, directly into The World, anchors with their own trackable IDs where they wanted their own content 0,0,0 origins to be. This would allow even crusty old legacy experiences made on their ancient 2022 beta/launch API to not only keep functioning but reap the benefits of ongoing refinements to their world mesh into the far future.

This, however, presupposes that anchors placed in The World as currently localized will reliably be restored in their World placed positions irrespective of wayspot, and that anchors NOT placed in the immediate environs of the user will NOT erroneously restore in a way that leads the app to believe the user is engaging with content that they are not in fact anywhere close to. Empirically, as of 2.0.0,

  • Irrespective of requested accuracy, it does not seem like the stack is able to restore anchors to much within about 0.5m accuracy to the real world camera feed.
  • All provided anchor payloads do in fact seem to restore, with varying levels of accuracy, against any wayspot, but
  • only “nearby” anchors (possibly those keyed to a particular wayspot behind the scenes) are tracked for position updates
  • Under TBD circumstances (tried on a whim and it’s reproducible some directions but not others), it is possible to localize to a wayspot, “restore” anchors for several wayspots, get tracking on anchors for the immediate wayspot, and, within the same session, walk to a location where you placed anchors against a different wayspot, and have those anchors show up and track despite no visible transition or re-localization between wayspots having taken place. Meaning anchor<->wayspot mappings are probably not 1:1.

So if I were designing an app to the presumptive grand future state, I would in fact let go of the notion of wayspot IDs and rely upon the anchors themselves (after the user has localized to a/any wayspot in the world from which their position can be reliably derived, and thereby relying upon the fact that any Tracked anchors that come near the user are in fact near the user), and only trigger content within the app if a restored anchor came within some [view-of-camera] x [distance] functional threshold of the user. This does mean, as spelled out in The Docs, that anchor payloads would need to be generated and retained, although if it’s a 1-time asset placement as in my current concept and Sam’s described app, the anchor payloads for those individual assets can be logged upon generation and hardcoded locally with no need for a web storage back-end. And yes, it means you need to make a dedicated app or debug mode for placing the anchors into a localized world to begin with, but there’s template code for that in the docs and iirc at least one demo. I’d hazard this very app takes under an hour to build if you just hack up Tap To Place, a bit longer if you build your own UI to refine placement.
I’d also look to get the documentation rephrased a bit to make it clearer that anchors were not intended to be strictly assoicated with individual wayspots but instead with the real-world geographic locations the wayspots represent, and also describe what failure flow to expect if a payload was provided corresponding to an entirely different location, abstracting away from whether that location was nearer, or placed against, one wayspot or another. And I’d expect the API to uphold its end of the bargain and not give inconsistent positions based on how many scans of an area had been submitted and whether localization happened against one scan vs another.

In lieu of a “wayspot ID,” then, perhaps a useful feature consistent with an abstract wayspotless future state would be a per-anchor sort of globally consistent GPS microcoordinate that would allow the developer to determine, upon anchor parse, where that anchor is “supposed to be in the real world” independent of whether it was set up against one wayspot vs another, and thereby isolate/filter their experience to their intended geofence without having to take bankshots off of other APIs for very rough inference of what anchors are “supposed to be” restoring/tracking based on a user’s GPS and wayspot? The back-end is then free to evolve so as to juggle, stitch, and redefine the wayspots as it sees fit, without exposing this to the developer, so long as putting the same physical landmark on camera restores the geo-pinned anchors the same way each time. There could also, then, be an independent anchor creation API where a developer who happens to know (or believe they know) the ultra-precise GPS lat/lon microcoordinate of an anchor they want to create could create that anchor programmatically without needing to localize/scan anything from a real app first, and when that anchor successfully parses and begins tracking, the developer knows where the user is within a defined relative space.

And if developers can’t, architecturally, be allowed to know precisely which wayspot they’re localized to, or precisely which anchors are associated/trackable against which wayspot, or even where an anchor was supposed to be in an absolute sense, it might instead be reasonable to add an explicit flag to the anchor objects to quick-confirm at least whether, de-facto at runtime, a given anchor is expected to be trackable against the current localized wayspot, thereby codifying the idea of placing an anchor on/near a wayspot to determine if the user is “at” that wayspot, whatever it is or isn’t ID’d under the hood, and whether or not there are multiple known nearby wayspots that may eventually be used in tandem, merged, or discarded/replaced.

10

I thought of that also - Niantic did say they want to merge all of the wayspots eventually - but right now they are positioned relative to each other with GPS, so it’s very difficult to start patching things together.

My argument against this approach is that it is an approach for a service that doesn’t yet exist. VPS is based off of object recognition and it does only place content relative to those objects. So if it’s trying to do something else it’s introducing room for error and confusion.

To try to make the markers universal now will result in them being off later as the map moves and shifts around to fit everything into place. I think a better approach would be to let us position relative to the wayspot for now. Later if they come up with a better way to do universal anchors they can convert the old anchors to new ones still based off of that reference point.

They did mention at the conference that they were not close to tying their system to any kind of GPS world positioning.

The reason MapID’s didn’t work is that wayspots seem to be made up of multiple maps. So what we need is not a MapID but the ID of the wayspot that map belongs to. They are all getting combined into something - that’s the thing that should have an origin that we can reference.

11

Hi Sam,

I again attempted to reproduce the original reported error of two localization targets placing the same anchors regardless of which target the device is localized to, using the WayspotAnchors example scene.

This time around, I used two private scan locations in my office that are roughly 2 meters apart, and I was again unable to reproduce the issue – each localization target was able to create, save, and load distinct anchor payloads.

To reiterate — Can you confirm that you’ve experienced issues with creating, saving and loading anchors at separate localization points using the WayspotAnchors example scene? And if so, would you mind providing screenshots/video and information about the package versions you’re using, as well as your Unity version? Without being able to reproduce the original issue, we won’t be able to make much progress on our end.

1 Like
12

Hi Rob -

Thanks for looking into this. I have done more digging and found that I was recalling the anchors incorrectly so they were loading regardless. I believe I have it working now - anchors do indeed only load where they should be and not on incorrect wayspots.

But the larger point and problem remains. The way this is implemented still requires a bunch of round-about work to figure out which wayspot you are localized to. In this case I will need to try to spawn all the anchors in the gps area and then watch the scene to see which anchor actually appears, then match that to a db of my own creation to get a wayspot ID.

I am in my second week of building such a system - that just abstracts everything back down to a wayspot ID and single reliable anchor. It has been a major setback compared to the beta where I was flying building content and scenes on day 1.

13

Glad you were able to resolve the wayspot anchor issue.

As for the VPS localization system not exposing an identifier for the currently localized wayspot, I’ve filed a feature request to have this surfaced internally.

Additionally, you may wish to visit the Lightship roadmap here and vote on upcoming and planned additions to the Lightship suite to indicate their level of importance to your project. If I understand your use-case correctly, then the Real World Content Service feature may be a valuable future addition, and adding feedback this way helps our teams understand and prioritize project needs.

real_world_content_service
real_world_content_service850×799 97.8 KB

1 Like
14

hey there would you be so kind as to elaborate on what exactly you did to ensure you recalled anchors “correctly”? I’m currently looking at the wayspot anchor sample scene and have no idea how ARDK knows which anchors to load? It seems like it always loads all anchors as you said, but yet only those anchors tied to the current wayspot loads in-scene. The documentation isn’t offering any advice on this either.

@rob_link

Is the info on which wayspot the anchor belongs to part of the payload? But in that case does that mean if I want to persist anchors, I need to load ALL anchors across ALL wayspots, and then let the app figure out which anchors to actually load in-game based on the current wayspot?

1 Like
15

AFAIK that’s basically the process. The only abstract reference I saw in the docs implies it’s on the developer to store their own payloads and put them in for recall, meaning it’s on the developer to tag their own payloads in their own storage with any metadata to limit the payloads they try to restore to only ones relevant to the given context.

One way to do this would be, as suggested, by GPS. Another might be to have an initial set of 1 “identification” anchor per wayspot, try to restore all the identification anchors, and when/if an identification anchor successfully tracks, then try to restore all the anchors which you as the developer have keyed to that wayspot.

But that is definitely an extra step vs simply having a wayspot ID to key to up front, or minimally, a pre-filtering API to say which payloads have a chance of restoring to the current wayspot.

16

Just wanted to vote for including a wayspot ID or some other way of narrowing down the anchors in your vicinity. It seems like such a simple solution to avoid having to download all the content from a cloud DB in order to just display one.

4 Likes
18

Are there any updates on this issue? VPS is really hard to use without the ability to get the ID of the current VPS that the app is localised to.

19

Same here? Any updates?

@rob_link as far as I understand there is no chance to get location information out of the way spots you are localised to and this will also not be doable in the future?