-
Notifications
You must be signed in to change notification settings - Fork 21
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
Define GeomagneticOrientationSensor interface #15
Comments
SGTM |
Can we actually implement this. I mean on Android the above "AbsoluteOrientationSensor" might use different impl if magnetometer isnt available. Is it possible for us to detect that? |
Apart from that, I think this is fine. |
@kenchris, it seems your explainer doc does identify high value use cases for all three: https://w3c.github.io/motion-sensors/#orientation That said, the use case for Relative Orientation Sensor ("This avoids the delay which low and high pass filters introduce.") could be more explicit. |
@kenchris Yes, we can always check what low level sensors are supported by the platform. |
@kenchris in that perspective (and looks like we all agreed :) ) do you think it's worth renaming |
If we can do that without instantiating them, awesome, then let's go with this :-) |
@pozdnyakov yes that makes sense. |
we can :D |
Partially fixes w3c#15
Partially fixes w3c#15
Partially fixes w3c#15
Partially fixes w3c#15
Reopening the issue, as it should be closed only when last GeomagneticOrientationSensor is specified. |
Marked as "Level 2" per WG call decision. |
The OrientationSensor interface could define methods and internal slots (quaternion), while subclasses can explicitly define model and what kind of low-level sensors are used for fusion, e.g.:
The text was updated successfully, but these errors were encountered: