Skip to content
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

Open
alexshalamov opened this issue Mar 14, 2017 · 11 comments · Fixed by #39
Open

Define GeomagneticOrientationSensor interface #15

alexshalamov opened this issue Mar 14, 2017 · 11 comments · Fixed by #39
Assignees
Milestone

Comments

@alexshalamov
Copy link

alexshalamov commented Mar 14, 2017

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.:

  • AbsoluteOrientationSensor : OrientationSensor, uses gyroscope, acceleromter and magnetometer.
  • GeomagneticOrientationSensor : OrientationSensor, uses accelerometer and magnetometer.
  • RelativeOrientationSensor : OrientationSensor, uses gyroscope and accelerometer.
@pozdnyakov
Copy link

SGTM

@kenchris
Copy link
Contributor

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?

@kenchris
Copy link
Contributor

Apart from that, I think this is fine.

@anssiko
Copy link
Member

anssiko commented Mar 14, 2017

@kenchris, it seems your explainer doc does identify high value use cases for all three:

https://w3c.github.io/motion-sensors/#orientation
https://w3c.github.io/motion-sensors/#geomagnetic-orientation
https://w3c.github.io/motion-sensors/#relative-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.

@alexshalamov
Copy link
Author

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?

@kenchris Yes, we can always check what low level sensors are supported by the platform.

@pozdnyakov
Copy link

@kenchris in that perspective (and looks like we all agreed :) ) do you think it's worth renaming Orientation Sensor into Absolute Orientation Sensor in https://w3c.github.io/motion-sensors/#orientation ?

@kenchris
Copy link
Contributor

If we can do that without instantiating them, awesome, then let's go with this :-)

@kenchris
Copy link
Contributor

@pozdnyakov yes that makes sense.

@pozdnyakov
Copy link

pozdnyakov commented Mar 14, 2017

If we can do that without instantiating them, awesome, then let's go with this :-)

we can :D

alexshalamov pushed a commit to alexshalamov/orientation-sensor that referenced this issue May 9, 2017
alexshalamov pushed a commit to alexshalamov/orientation-sensor that referenced this issue May 9, 2017
alexshalamov pushed a commit to alexshalamov/orientation-sensor that referenced this issue May 9, 2017
alexshalamov pushed a commit to alexshalamov/orientation-sensor that referenced this issue May 10, 2017
@alexshalamov
Copy link
Author

Reopening the issue, as it should be closed only when last GeomagneticOrientationSensor is specified.

@alexshalamov alexshalamov reopened this May 10, 2017
@anssiko anssiko changed the title Define OrientationSensor interfaces Define GeomagneticOrientationSensor interface Oct 5, 2017
@anssiko
Copy link
Member

anssiko commented Mar 8, 2018

Marked as "Level 2" per WG call decision.

@anssiko anssiko added this to the Level 2 milestone Oct 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants