Re: DeviceOrientation Clarification

Hi Jonathan, Lars,

On 31 Oct 2014 16:17, "Jonathan Ross" <jonross@google.com> wrote:
>
> Hi,
>
> I am currently working on implementing the DeviceOrientation Event
Specification for Chrome OS.
>
> I wanted to get a clarification on one of the examples. The final example
in Section 2 Introduction:
>
>>> A device is mounted in a vehicle, with the screen in a vertical plane,
the top uppermost and facing the rear of the vehicle. The vehicle is
travelling at speed v around a right-hand bend of radius r. The device
records a positive x component for both acceleration and
accelerationIncludingGravity. The device also records a negative value for
rotationRate.gamma:
>>>
>>>       {acceleration: {x: v^2/r, y: 0, z: 0},
>>>
>>>        accelerationIncludingGravity: {x: v^2/r, y: 0, z: 9.81},
>>>
>>>        rotationRate: {alpha: 0, beta: 0, gamma: -v/r*180/pi} };
>
>
> From the description of the device I would have expected that the gravity
component would be applied to the Y-axis. Giving
accelerationIncludingGravity: {x: v^2/r, y: 9.81, z: 0}. Is that a correct
interpretation?
>
> Furthermore, while testing implementations of the API I have noticed a
discrepancy between the Chrome Android, and the Safari iOS implementations.
Currently Android orients gravity in the same manner as the specification,
with a flat device reporting accelerationIncludingGravity: {x: 0, y: 0, z:
9.81}. However I am seeing the gravity reversed with iOS, which reports
accelerationIncludingGravity: {x: 0, y: 0, z: -9.81}.
>
> Currently I am planning to follow the specification and Android
implementations. I wanted to bring this up because the inconsistency could
make the API hard for web developers to use.
>
> Please advise.

I sent an email to this list in July with the same observations:

http://lists.w3.org/Archives/Public/public-geolocation/2014Jul/0024.html

I'm also not sure how we proceed here. My current interpretation is that
Chrome for Android is providing the correct values and iOS values are
inverted according to the spec guidelines.

In that previous email I provided a demo of the problem.

Is it possible to fix this inconsistency without breaking some existing
content?

On 31 Oct 2014 16:33, "Lars Knudsen" <larsgk@gmail.com> wrote:
>
> See this nice little compensation lib:
https://github.com/richtr/Full-Tilt

I wrote this library. I did not include any normalisation between iOS and
Android DeviceMotionEvent.acceleration or
DeviceMotionEvent.accelerationIncludingGravity data as I considered browser
detection the incorrect way to fix inconsistencies at the time (e.g.
if(iOS) then invert accelerometer values). Using browser detection would
also make this library not future compatible in the case that either iOS or
Android want to invert their implementations to provide consistency.

I'm as uncertain what to do as you both are.

What could we do? We can add whatever solution we decide on to the spec of
course.

- Rich