Re: DeviceOrientation Clarification

Hi Jonathan,

it's true that - for some reason - iOS and Chrome Android have exactly
opposite readings for X,Y and Z (very annoying).  Apart from this, you
should probably also beware that there are devices out there considered
"landscape devices", where the X and Y axis are rotated 90 degrees compared
to their "portrait" counterparts.  This is *also* very annoying when
designing apps and games to be run in portrait mode - not knowing what is
up.

IMO, for your implementation, assuming ChromeOS will come to tablets or
other devices where it would make sense to make use of the sensor readings,
it would be a good idea to consider to map the XYZ as it would on any other
android phone or tablet, where (afaik), the Y axis is parallel to where the
device is "long" (= portrait).  Consistency will make developers happy.

Unfortunately, the specs for fullscreen and devicemotion/orientation were
not done in a very coherent way - leaving implementors and web developers
with a lot of uncertainty.

See this nice little compensation lib:  https://github.com/richtr/Full-Tilt

br
Lars

On Fri, Oct 31, 2014 at 6:28 PM, Jonathan Ross <jonross@google.com> wrote:

> Hi,
>
> I am currently working on implementing the DeviceOrientation Event
> Specification <http://www.w3.org/TR/orientation-event/#deviceorientation>
> 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.
>
> Regards,
> Jonathan Ross
>