Location-Based Algo: Tests for Relative vs Absolute Heading?

[evaristoc]

Describe the bug There is a chance for the current location-based implementation not to be universal. According to this reference, the orientation algorithm of some devices might be based on a frame of reference that is not absolute to Earth's North, but rather to the position of the device by the time the page opens (relative reference).

So far there is no evidence that the error is present and when. This issue is to explore that the current solution is generalizable.

Expected behavior

1. "For every device it is possible to get a reference to the Earth's North; geolocation of marks are correct for every device".
2. "If not, a list of non-working devices should be on hand. When required, please share any solution you might know".

Screenshots Please check the aforementioned reference for more information.

To Reproduce

We can start by using the test suggested in the reference, checking the outcome, and then seeing if that might explain what it is observed from opening @nicolocarpignoli examples. A detailed procedure could be as following:

1. Test for Relative vs Absolute heading using the following link: http://www.grantholtes.com/compass.html (see the aforementioned reference for details) Take note of the result.

2. Whatever the result, test one of the examples below as given by @nicolocarpignoli at the original repository of the location-based component:

   • https://nicolo-carpignoli.herokuapp.com/examples/basic.html
   • https://nicolo-carpignoli.herokuapp.com/examples/places-name/

3. See if the expected result from activty 1 matches what it is seen from activty 2.

4. In case of results not being as expected by point 1 of EXPECTED BEHAVIOUR, please report? We would interested in the following: Smartphone (please complete the following information):

   • Device: [e.g. iPhone6]
   • OS: [e.g. iOS8.1]
   • Browser [e.g. stock browser, safari]
   • Version [e.g. 22] Additional context Add any other context about the problem here.

NOTE Based on this discussion: https://github.com/jeromeetienne/AR.js/issues/663#issuecomment-560033972, #663

[evaristoc]

@nicolocarpignoli

1. Test for Relative vs Absolute heading: RELATIVE; also the North indicator moves while testing heading and its position changes even more drastically after rotating device relative to ground
2. Basic Example: locations don't stay in place and are wrongly located, even under high accuracy
3. Not expected behaviour: Wrong geolocation; North indicator moves widely
4. Samsung 7/8; Android; [Samsung Internet, Chrome]; last versions to date

Tested outdoors, directly connected to provider (no wifi). Google Maps won't affect behaviour.

[evaristoc]

The following seems to be the implementation suggested for the existing project:

• https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation

Are these references to be taken in consideration in order to work around a solution to this issue (in case more tests show it is actually an issue...)?:

• https://developers.google.com/web/updates/2016/03/device-orientation-changes
• https://blog.getwemap.com/introduction-to-geo-ar-measuring-position-and-orientation-in-the-browser-dd152a5fef29
• https://developer.mozilla.org/en-US/docs/Web/API/Coordinates/heading

Other relevant references:

• The absolute and relative measures as specified by W3C: https://www.w3.org/TR/orientation-event/
• A description of the measuring in Android, apparently suggesting the use of relative: https://developer.android.com/guide/topics/sensors/sensors_position
• A simple positioning test: https://www.w3schools.com/jsref/prop_geo_coordinates.asp

[evaristoc]

My TESTS:

Comparing Properties and Algos for True North for Device's Attitude

• Unless said otherwise, data usually observational by building a simple digital 2d compass in 3d space on my phone and comparing its heading to an analogue one; no data stored
• [ ] compass heading: a rough compass heading based on Euler angles as described by W3C, Example 10 is the current implementation (_computeCompassHeading module at gps-camera module); however the same reference already mentions the gimbal lock issue for that specific example; What about the other implementations recommended by the same reference?
  • [x] compass with compass heading algorithm from Example 10 of W3C reference: RESULT very unstable, unreliable
  • [x] compass with compass heading algorithm from Example 11 of W3C reference: TODO close, apparently better, to results obtained by implementing a simple offset alpha
  • [x] compass with compass heading algorithm from Example 12 of W3C reference: ~TODO~ - implemented in someone else project, using the device orientation control approach at Three.js to get user pose; unreliable
• [x] Coordinates.heading (https://developer.mozilla.org/en-US/docs/Web/API/Coordinates/heading):
  • [x] alone: RESULT reading having similar problems as reported previously, unstable and inconsistent, unreliable (single-tested)
  • [ ] Coordinates.heading with Noise reduction
    • [ ] Kalman filter - also here - kalmanjs library over coordinates.heading, Euler angles; kf parameters roughly estimated, constant: PRELIMINARY RESULT ; points usually to North but apparently the sensor relies on the user walking; stationary is not ok => sensors likely accelerometer and gyroscope; apparently the observation is right according to this reference
• [ ] alpha when absolute orientation available: based on references, absolute alpha should be already oriented to true North, so why compass heading? RESULT alpha with absolute orientation is more stable than compass heading;
  • [x] recently tested modifying heading at https://nicolo-carpignoli.herokuapp.com/examples/basic.html example and adding hard-coded locations -> the BEST results so far (Google Chrome, Samsung Internet)

Stability

• Attitude evaluated based on Euler angles implementation
• Attitude evaluated based on Quaternions implementation: OBSERVATION: pose and user/object matrix upadting largely handled by the look-controls method of a-frame, which is based on THREE.js and quaternions in particular

  Other

  • [x] WebXR specifications: check if there is already an implementation on its way: so far advances are the following: https://www.infoq.com/news/2019/11/webxr-chrome-79/; to-date there is no mention of location-based algorithms, which should be ported with the WebAR part when finished

[evaristoc]

Although I will still check some aspects of this issue, I am turning it into a Closed Issue.

Some aspects of my tests were already worked on in a different project. That project didn't solve the inaccuracies faced with the Location-Based AR.JS, despite of being an improved version. Going further with my tests might "not be like raining but pouring".