Location Based AR (AFRAME) android - gps-entity-place floating in random spaces, relative to starting orientation. It works okey on iOS.

[janpaweljanusz]

Do you want to request a feature or report a bug? a bug

What is the current behavior? Location Based AR (AFRAME) doesn't work on android I've used this repository several times last year. All these apps stopped working on android. The camera on device turns on, but objects gps-entity-place or gps-new-entity-place are floating in random positions. Location based AR still works great on iphone, but is messed up on android. I've checked on several devices: samsung S22, Samsung S8, Samsug S7. In general it seems that the location of points is related to a direction in which I start the app. Of course I've tried to run current Location Based example, with the newest library versions (both aframe and ar-js (aframe-ar-nft.js, aframe-ar.js)

If the current behavior is a bug, please provide the steps to reproduce.

Just run Location Based Example from this github page. It will work great on iOS, but entities will be floating in wrong positions on Android.

Please mention other relevant information such as the browser version, Operating System and Device Name

Any android and chrome. In particular: Samsung S22, model name SM-S901B/DS, Android 13, Chrome: 114.0.5735.61

What is the expected behavior? Displaying gps-entity-place or gps-new-entity-place in correct positions, exactly how it works on iOS.

[janpaweljanusz]

It seems that a gps-camera (new-gps-camera) is getting placed and oriented in wrong positions.

[nickw1]

Odd, I've just tested the basic-js example from the new-location-based directory in the A-Frame examples. It works for me.

This is running Android and Chrome on a Pixel 3 and LineageOS.

This is with the current version, just checked out of GitHub.

Can you confirm, or otherwise, whether that specific example works? Try pressing the Go button straight away to get it to use the 'fake' location on the form.

[janpaweljanusz]

Thank you for your comment. I tested this version and in fact it works! I will check what is the difference between versions I tested.

[Platform-Group]

In general it seems that the location of points is related to a direction in which I start the app. Of course I've tried to run current Location Based example, with the newest library versions (both aframe and ar-js (aframe-ar-nft.js, aframe-ar.js)

@janpaweljanusz What was the difference, I'm having this issue right now. I can't find the example @nickw1 is referring to, I'm assuming it's not this one as that example is currently broken and there's an open issue for fixing it.

[nickw1]

@Platform-Group I have now updated the docs, so the linked example should work.

The examples I am specifically referring to are the ones bundled with the distribution, in aframe/examples/location-based. These have the correct A-Frame version. Do these work for you? These are definitely working for me.

[nickw1]

Sorry aframe/examples/new-location-based.

[Platform-Group]

@nickw1 which example would you recommend? My current code uses the latest version of ar.js and a-frame with new location based components, and sets a north arrow entity to help me figure out the problem. I've tried most of these examples before and still have issues with accurate placement of entities at their latitude and longitude.

However I don't believe this is the fault of AR.js, and it's simply that phone compasses/magnetometers are inaccurate, when I start up the webapp it can believe north is in basically any direction in 180 degrees. Most of the time it's mostly correct, within about 20 degrees, but that's not good enough for me. As my use case is to point a camera out of a skyscraper to overlay clickable pins over buildings, I need true north to be very accurate.

I just mentioned this in a comment to you in another issue, but I'll repeat it here. I'm currently looking to try and find a way to accurately help ar.js figure out which way is north. Ideally with a marker image of a real compass that points north, but I'm still trying to figure out how to manage that implementation or something similar. If you have any advice on that it would be great.

[janpaweljanusz]

Please, mark this library as "unstable", "experimental", "not-working", because your are doing serious problems to people claiming that it is stable. I know that it is free, but now I have serious problem, because it doesn't work on majority of Android phones and my contract will probably end up in court. In the past (few years from now) it worked on androids, but now it doesn't. The north direction is always recognized as a start point. Tested on over 100 devices. Only a few newer devices like s22, s23, newest pixel etc work with the "new" system. Others are totally messed up.

Next few days I will debug it and try to make it working.

[marlo22]

Hello :slightly_smiling_face:

I worry, @janpaweljanusz is right. On Android devices there is probably a problem with initial orientation of an AR view. I have three points and these points are in different geographical places, depending on the device rotation. It looks like they are sticked to the screen and don't respect geographical coordinates. After start the app I always have these points on the left, right and the front of the screen, even if I turn the device left/right/around before initializing the app.

I've noticed another interesting fact. Generally speaking I tried to find the source of the problem. To verify this I used an online compass (I chose this one https://lamplightdev.github.io/compass/) and this app always shows the north on „the top of device”. If you turn the phone right and refresh the page it shows the north in a different place according to the top of the device. Maybe this issue has the same root as our problem? Chrome 50 has changed implementation of the deviceoriantion event and from this version calculates some values in a different way. https://developer.chrome.com/blog/device-orientation-changes/ Is it not related? :thinking: Could someone confirm/deny?

As long as it doesn't work as a workaround I plan to force Android users of my app to calibrate the orientation of their devices manually. Before the AR app start, I'll show a page with a working compass and ask an user to rotate their device to the north. This is of course not perfect, but this is better than nothing.

I think it's a critical thing for everyone so if I can help in any way, let me know. please. :slightly_smiling_face:

[Platform-Group]

@marlo22 I'd be very interested in that compass page if you make it, I was under the impression that the app not being able to find north accurately was an issue with mobile devices in general. I find even 'compass' apps on various devices that I've tested aren't particularly accurate.

My current plan was to just have the user drag on the screen to calibrate north. Although this only seems to work if the GPS is turned off which really sucks. I'll probably have to go into the library's source code to try and figure out how to implement manual rotation. Let me know if you find anything helpful on this front.

[nickw1]

@nicolocarpignoli @kalwalt apologies for contacting you on this but could you, if you have a moment, give some input to @janpaweljanusz ?

Do note that in general, open source software comes with NO WARRANTY. The license is specifically the MIT license, which includes the clause below:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

The real problem is that this issue is not very reproducible, and only happens on some devices.

I don't believe it's related to Chrome 50 because it works on many devices running current versions of Chrome. It is almost certainly to do with sensor issues.

What I can do, with the blessing of @kalwalt / @nicolocarpignoli, is to specifically highlight this as an issue with the library.

What we are really looking for is more developers, we are a small team and all volunteers, and (speaking personally) am struggling to find time for AR.js at the moment.

@marlo22 contributions are always welcome, if you are willing to spend time to try and resolve this issue, then please, please do so.

[nicolocarpignoli]

Hi everyone. We have no problem to report this bug, if present, and if so problematic, in the Readme of AR.js - for me there is no problem even to add the label "experimental" if that would help. Now I have to remind you that we are in Open Source environment and all the work you find here, for free, is offered by months and years of work of other passionate developers like you. As pointed out by @nickw1 AR.js is just one of thousands of libraries in OSS with MIT license. Any developer who decides to base part/all of their project on AR.js or other Open Source library should know the "risks" and gains. Support is limited; it can stop at any moment. As happened in the past, sometimes OSS libraries could be bringing even serious security problems to projects using it. The responsibility lies-and always will lie-with those who decide to use these libraries in their projects.

Is there a problem with AR.js? You can:

• try an old version
• work around the problem from your project
• fix the problem on AR.js
• create your own modified version of AR.js (and keep it private and market it if you want)
• use another library (even a paid one).

Under no circumstances is nor should the solution be to present issues in an accusatory way on this repository.

This is not a problem with a specific post on this thread, it is a more general suggestion as I sometimes see people claiming help, fast and for free. We can, I repeat, argue in reporting AR.js as experimental, but that status is implicit in my opinion - it is in the eyes of everyone that this project is maintained by very few people, with occasional releases and a feature development that has been at a standstill for years.

So thanks for all who are working hard, when they have time, on this project and please continue keeping this a cool environment.

In the end:

What I can do, with the blessing of @kalwalt / @nicolocarpignoli, is to specifically highlight this as an issue with the library.

Absolutely ok to me.

Please, mark this library as "unstable", "experimental", "not-working",

Rather than labelling as unstable I would prefer to highlight the specific problem and the environment (devices, OS, browsers) where this happens for sure, as a list. But if you think it is more helpful to label it, then we can do so.

[nickw1]

@nicolocarpignoli many thanks for your very useful and insightful post.

I would echo Nicolò in pointing out that AR.js is, indeed a free and open source library which is maintained for free in our own time, and I do hope everyone reading this does understand and appreciate that. We are all too happy to fix bugs if we are able, but please do realise that we have many other commitments outside of this project.

In the meantime, we absolutely welcome PRs and bugfixes, and particularly welcome new developers on the project. Owners of iOS devices are particularly welcome.

[marlo22]

Hello 🙂

I worry, @janpaweljanusz is right. On Android devices there is probably a problem with initial orientation of an AR view. I have three points and these points are in different geographical places, depending on the device rotation. It looks like they are sticked to the screen and don't respect geographical coordinates. After start the app I always have these points on the left, right and the front of the screen, even if I turn the device left/right/around before initializing the app.

I've noticed another interesting fact. Generally speaking I tried to find the source of the problem. To verify this I used an online compass (I chose this one https://lamplightdev.github.io/compass/) and this app always shows the north on „the top of device”. If you turn the phone right and refresh the page it shows the north in a different place according to the top of the device. Maybe this issue has the same root as our problem? Chrome 50 has changed implementation of the deviceoriantion event and from this version calculates some values in a different way. https://developer.chrome.com/blog/device-orientation-changes/ Is it not related? thinking Could someone confirm/deny?

As long as it doesn't work as a workaround I plan to force Android users of my app to calibrate the orientation of their devices manually. Before the AR app start, I'll show a page with a working compass and ask an user to rotate their device to the north. This is of course not perfect, but this is better than nothing.

I think it's a critical thing for everyone so if I can help in any way, let me know. please. 🙂

I have to correct this message. I investigated more deeply this bug and now I'm almost sure that there is no problem with AR.js, but with the device. I noticed that the device's compass/gyroscope is not calibrated correctly and because of that the position of AR location based objects is not accurate. If you have a similar problem:

• verify your device's heading in another application like Google Maps for example
• check there is no any interference affecting the comapss/gryoscope - I have a case with a magnet :man_facepalming: (to make closing the flap easier). If I take my phone out the case it starts working so much better.
• try to calibrate the compass by making the "figure 8 moves" like so https://www.youtube.com/shorts/R1hDZUb_1ec

I am sorry for the last post, I hadn't verified my problem good enough, but I didn't have bad intentions. :pray: I hope these tips will be useful to someone with similar problems. :wink:

Maybe it's worth to add a note to the docs about the relation between device physical components (like compass) and AR.js? I know it's obvious for many people but sometimes we forget about the simplest things. :wink:

Finally, I would like to say a big thank you to every person involved in the development of this cool library :muscle:

[nickw1]

@marlo22 many thanks for your investigations and advice to other people facing the same problem.

I will add something to the docs (sorry, been meaning to for a few weeks, but haven't had the chance of late...)

Thanks also for your appreciation of all of us involved in contributing to the project! :-)

[beachgrub]

I am having this exact problem but only on iOS. Multiple devices. Android works fine. Opened an issue describing it based on the simple location example.