Re: DeviceOrientation Clarification

On Sat, Nov 1, 2014 at 10:41 AM, Rich Tibbett <richt@opera.com> wrote:

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

I feel your pain:
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/Qal4EQ1s2E0/yDM6JbtAGhwJ

(been ranting about the faulty specs and implementations for years - but
apparently you will quickly be put on the ignore list if you don't agree
with the spec'er in charge ;))

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