Proposal: Smooth GPS changes on mobile devices

[blairmacintyre]

Problem:

GPS on mobile devices updates slowly (~1 report / second) and is inaccurate (sometimes 10+ meters of error. When using GPS as the location of the AR user, this leads to nearby content (even things a few hundred meters away) appearing to jump suddenly each second.

The first time someone sees this effect, they find it distracting and would like to find a way to deal with it.

Possible Approach

The underlying issue cannot be fixed through software: if it was possible for the mobile GPS accuracy to be improved, it would already be done at the system level. Use of WIFI to improve location, for example, is common in modern operating systems.

The most commonly suggested solution is that argon.js smooth the GPS changes: when a new report arrives, we could smoothly change to it over a short period of time, by interpolating from the "current" location to the newly reported location.

There are different ways of doing this, each of which has pros and cons:

• transitioning over a fixed time (such as 1/4 second) would eliminate the sudden "jump" and ensure the location is updated in a timely manner, but since the GPS error varies over time (with some changes being small, others being large, and occasionally large outliers in the data) this would do little to eliminate large occasional errors.
• transitioning with a maximum rate (such as 1 meter / second) would smooth out jumps and eliminate problematic transient errors that are large, but would be problematic if the user is actually moving at a high speed
• using some sort of easing function (slow in, slow out) to make changes less jarring
• move at a maximum rate until the different between the GPS and the user is greater than some amount for some number of reports
• using the GPS reported speed and heading to figure out a maximum interpolation speed.

None of these solutions would be perfect, but they would eliminate the sudden jumps.

Doing these adjustments at the application level is problematic, as developers would implement different solutions, and the result (if multiple channels are displayed at once) would be problematic.

Also, as we being getting high precision local sensors (Tango, Hololens) that we want to combine with geolocation (e.g., by anchoring the coordinate frames of those sensors in the world using the geolocation of the device), the sudden GPS changes will be less visible, and application-side smoothing may interfere with local tracking. Smoothing (or not) the GPS reports themselves, before they are using argon.js, would be the only "correct" solution.

Proposal

We could add a one or more smoothing functions to argon.js, which could be turned on/off by the end user via a menu item. The menu item would be in Argon4's menu, or the argon.js menu displayed in non-Argon4 browsers.

The advantage of this solution is that we also educate users to the underlying problem, helping set user expectations.