Re: DeviceOrientation Clarification

On 1 Nov 2014 11:19, "Lars Knudsen" <larsgk@gmail.com> wrote:
>
>
>
> 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 ;))

Tim and I only recently picked up  the editing of this spec. Please know we
are very keen to get some consistency here any way we can.

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