Re: Feedback on the DeviceOrientation API

On Wed, Aug 20, 2014 at 3:08 PM, Tim Volodine <timvolodine@google.com> wrote:
> I guess it makes sense to separate the magnetic field data, especially
> because some apps do not seem to require alignment with the magnetic pole.
> However I am somewhat concerned about how the apps that do require absolute
> orientation would compute it reliably if we always set absolute=false. I
> think this is something to consider in more detail.

Calculating absolute orientation is already a problem on iOS. iOS does
not provide absolute, compass-oriented deviceorientation values. For
this reason they shipped two additional properties:
'webkitCompassHeading' and 'webkitCompassAccuracy'. I have not yet
figured out or seen someone explain how to apply the provided compass
heading to the provided non-absolute deviceorientation values but, in
theory at least, this should be possible.

Of course, a Magnetometer API would have other use cases besides
absolute deviceorientation calculation but if we could introduce
'compassHeading' or some other type of compass offset property this
could also solve this use case.

- Rich

>
> Tim
>
>
> On Wed, Aug 13, 2014 at 2:54 PM, Mandyam, Giridhar <mandyam@quicinc.com>
> wrote:
>>
>> Hello All,
>> Please note that this suggestion has been out there for ten days now with
>> no additional comments.  Please try to provide feedback to the list on
>> Rich's proposals below by August 23.   In particular, if you know of any web
>> applications currently using DeviceOrientation that would break without
>> magnetometer input, please make the group aware of them.
>>
>> -Giri
>>
>> -----Original Message-----
>> From: Rich Tibbett [mailto:richt@opera.com]
>> Sent: Friday, August 01, 2014 2:58 AM
>> To: public-geolocation
>> Subject: Feedback on the DeviceOrientation API
>>
>> We have received feedback that impacts how we should be calculating and
>> delivering DeviceOrientation data for VR and 3D gaming use cases on the web.
>>
>> The first issue [1] is there is currently no way for web pages to interact
>> with the magnet button that is present on Cardboard VR headsets. Native
>> applications do have a way to detect proximal magnetic field changes that
>> can be used to represent a 'click' as demonstrated in the video at [2].
>>
>> Secondly, the presence of a strong magnet (i.e. the magnet button) placed
>> close to a user's device can cause DeviceOrientation to behave incorrectly
>> where DeviceOrientation values are calculated with Magnetometer sensor
>> readings. [3] outlines the general problem using Magnetometer in
>> DeviceOrientation data calculation can lead to.
>>
>> The second issue above is not currently a problem in iOS browsers since
>> they do not use the magnetometer to calculate DeviceOrientation data. Other
>> web browsers e.g. Chrome, Opera and Firefox for Android do use the
>> magnetometer to derive DeviceOrientation data that can lead to the magnet
>> interference issue described above. We should be looking for ways to
>> reconcile these fundamentally different implementations so DeviceOrientation
>> data means the same things across all web browsers.
>> DeviceOrientation should ideally always be compass-oriented or it should
>> always not be compass-oriented - but it should not be a mix of the two.
>>
>> I'd like to propose the following changes to the DeviceOrientation Events
>> API based on the feedback above and on the current implementation situation:
>>
>> 1. We add a requirement to the specification to say that we must not use
>> magnetometer data in the calculation of DeviceOrientationEvent alpha, beta
>> and gamma properties. Thus, the DeviceOrientationEvent.absolute property
>> will always become 'false'.
>> This change would align all implementations with each other. It would also
>> not break existing web applications with the assumption they are not relying
>> on _world-oriented_ device orientation data and covers the major use cases
>> for non-compass-oriented VR and 3D gaming on the web.
>> In practical terms this change would mean calculating DeviceOrientation
>> data using a combination of Accelerometer, Gyroscope but not Magnetometer at
>> all times.
>>
>> 2. We introduce a new API for web developers to obtain continuous
>> magnetometer sensor data readings from their browser that can be used to a.)
>> detect proximal magnet button 'clicks', b.) be used more generally to
>> interact with proximal magnetic fields and
>> c.) be used in
>> combination with other provided sensor data e.g. gravity to perform sensor
>> fusion to derive world-oriented device orientation (i.e. given gravity and
>> magnetometer sensor values a web developer could derive world-oriented
>> device orientation based on e.g. [4]).
>>
>> Making these changes to DeviceOrientation would not break existing web
>> pages that rely on DeviceOrientation Events assuming they do not rely on
>> that also containing the compass heading. These changes also allow us to
>> cleanly delineate VR and 3D gaming use cases (things that don't rely on
>> compass direction) from compass-oriented use cases (things we could then
>> calculate with additional sensor data input from e.g. a Magnetometer Events
>> API).
>>
>> Feedback and thoughts from others on this list would be very helpful in
>> deciding how we can reconcile DeviceOrientation implementations without
>> breaking existing web code, cover VR and 3D gaming use cases as well as
>> compass-heading use cases.
>>
>> br/ Rich
>>
>> [1] https://mail.mozilla.org/private/web-vr-discuss/2014-July/000056.html
>>
>> [2] https://www.youtube.com/watch?v=DFog2gMnm44&feature=youtu.be&t=19m00s
>>
>> [3] https://code.google.com/p/chromium/issues/detail?id=397824
>>
>> [4]
>> https://github.com/android/platform_frameworks_base/blob/8868d1290afd96997f=
>>
>> ef671f4a7a4c7bbf94fa1a/core/java/android/hardware/SensorManager.java#L776-L=
>> 970
>>
>

Received on Thursday, 21 August 2014 08:52:30 UTC