1

Closed

Ar appears to be inaccurate

description

When using the provided 'Simple AR' sample, the 3D labels appear to be inaccurately positioned. I have tried this many times on two handsets and in different geographical locations, and also have ensured that my handset's GPS is accurate, which it is to about 5 or 6 metres. However the in-vision labels of Location 1, 2 and 3 are often reported as being in the complete opposite direction to their reported position on the Bing Maps display.
 
I have also hardcoded a 4th geolocation in, and the same problem occurs with this, too. They (and my current position) appear accurately on the Bing map display (note that MY position appears accurately on the Bing Map display, which shows that the GPS is at least relatively accurate, but yet the 3D 'in-vision' labels appear at the completely incorrect position.
 
Repro Steps:
1 - Ensure that you have a good GPS connection and are standing outside
2 - Begin the application
3 - Tap the Add Locations button
4 - Ensure that the map mode is open, and that labels are visible.
 
Result - Observe that the direction that the labels are displayed at is generally far away from the position reported on Bing Maps, and the position reported when checking the GPS coordinates for these positions. Also note that this continues when walking around outside.
 
Repro Rate - 80%
Closed Oct 19, 2011 at 4:10 AM by jaredbienz

comments

jaredbienz wrote Oct 13, 2011 at 2:58 AM

This sounds like a serious issue, but I'm having trouble reproducing it myself. What devices are you using to test? Also, any chance you could grab some photos / screen shots / video?

Thanks for reporting.

tommydudehead wrote Oct 13, 2011 at 3:04 PM

I have tested it on two HTC Titan handsets.

I have created a (very amateur :) ) video and have put it on youtube, as it was too big to attach to the bug. The video can be found at:

http://www.youtube.com/watch?v=v9L-qZ0k9YQ

Please note that I have made it a private video, so it can't be found in youtube searches. I hope it is of some use to you.

As you can see in the video, the in-vision labels are not lining up with the map, and they are not offset by a consistent amount. Also note that the map position appears to be correct, including the user's position.

In case it is useful, my approx. coordinates for testing are pasted below. As I said before, I have tested at other coordinates, but all within 100 miles of this point.

X: 52.2919851,
Y: -1.5357872

If you have any other questions and want to asme me, I would be happy to help, so please let me know. I am looking forward to using this functionality in our app, which is aimed at corporate clients.

jaredbienz wrote Oct 13, 2011 at 5:05 PM

Thank you for the video, that is incredibly helpful. I agree that it's absolutely not doing what it's supposed to be doing. What I'm seeing in your video is not what I'm seeing on my device.

Since the map is aligned correctly and since the heading indicator is rotating correctly, I'm going to assume it's not an issue with the sensor reports on your device. Instead, I'm going to assume the issue is with WorldView. More specifically, I think the problem is in my math inside of ARHelper.DistanceBetween. This method is supposed to calculate the distance between two Latitude and Longitudes. But instead of calculating the distance in a direct line (as most samples you'll find do) it attempts to calculate distance as rise over run in meters. In other words "that building is 50 meters to the North and 20 meters to the East".

In your video, North and South appear to be correct but East and West appear to be flipped. That means latitude is correct but longitude is backwards. When you gave me your GPS coordinates I realized you were in the UK and I thought sure the answer was going to be that I didn’t account for crossing the prime meridian. However, the coordinates you gave are around Warwick which is still on the west side of the meridian.

Obviously I still need to do some work on this incredibly important method (there is another open issue around it not calculating differences in altitude). Unfortunately I’m traveling until next Tuesday so I won’t be able to get to it until then. If you have time and want to try your shot at fixing that method, by all means please do. And if you manage to fix it, could you please attach the fix to this issue?

Thank you for your interest in the project!

wrote Oct 19, 2011 at 4:10 AM

Resolved with changeset 63068.

jaredbienz wrote Oct 19, 2011 at 4:11 AM

Should be fixed with the 1.0.1 release. Let me know if it is not.

Sign in to add a comment