-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS alpha drift #3
Comments
This is an interesting problem and this drift is certainly being introduced in to the data at the platform level. To compensate for this drift we actually need more data. What we could try to do is to periodically 'reset' the Performing this drift compensation may make the orientation data jerky as we 'snap' the orientation to the correct heading. Thus, it may also make sense to establish what the drift is and then use e.g. a low-pass filter to smoothly apply that drift compensation over a short time period to avoid this 'snap'. Not trivial but this idea may have potential. Pull requests welcome of course :) |
That low-pass filter may be simple to implement, although I've had some difficulty adding it to this repo. http://stackoverflow.com/questions/491738/how-do-you-calculate-the-average-of-a-set-of-angles What has been confusing me is that webkitCompassHeading isn't what I expect when my device isn't flat on a table. I think I need to convert webkitCompassHeading to another number before I use this filtering process from stack overflow. |
+1 on accounting for iOS compass drift |
would something like this work?
|
On iOS the alpha value can drift pretty dramatically. This seems to be less a function of time, and more a function of how much the phone is moved while listening to the device orientation event i.e. the more that the phone is moved, the more the alpha drifts and not the more time passes the more the alpha drifts.
This happens on both Safari and Chrome for iOS.
Since the raw values are affected by the same problem, it seems to be an issue with the underlying deviceorientation event on iOS browsers, but perhaps there is a way to compensate for it during the normalization process.
The text was updated successfully, but these errors were encountered: