Re: deviceorientation calibration

Steve Block wrote:
>> I think its unclear in particular for beta and gamma values that to not tend
>> to have a continuous gradation in 360 degree space.
> I'm not sure what you mean by this. Why are beta and gamma not continuous?

That explanation may not have been entirely complete.

What I meant was that as a device travels 360 degrees around any beta or 
gamma plane we don't observe readings of 0 to 360 from the 
deviceorientation event. None of the implementations tested return 
0<->360 degree readings across all three axis of their orientation data.

For example, gamma readings progress as follows during a full 360 degree 
CW rotation of the device around a gamma reference plane in both Firefox 
and Opera implementations:

0 -> 90 -> 0 -> -90 -> 0.

It's not clear to me that these readings are sufficiently accounted for 
by the explanation that an xyz device frame rotates around a fixed XYZ 
Earth frame as currently described in the specification. Other 
implementations return different values for the same turn.

>
>> Based on the provided photo the device is in a [0, 0, 0] position based on
>> the xyz system included in the spec. The fact that both z (beta) and x
>> (gamma) values are zero is inferred from the fact that the device is resting
>> on a (presumably level) table top. In reality the only important component
>> is that y (alpha) is oriented towards the north (as determined by an
>> independent compass).
> OK, it sounds like you mean that the body's y axis is in a horizontal
> plane and pointing north. In this case, alpha is zero.

Yes.

>
>> It's a simple rotation so that, as we rotate the device towards us, we are
>> able to observe changes to the gamma reading (rather than a beta reading if
>> the device was not rotated 90 degrees as per the beta reference plane
>> described).
> You don't need to apply this initial rotation (alpha = -90 degrees) in
> order to vary gamma. Gamma is rotation about the body's y axis (the
> long axis of the device pictured) and can be applied irrespective of
> the value of alpha (or beta).

Yes. To be honest, we don't have to rotate that initial 90 degrees to 
conduct this test. It just happens that describing the rotation around 
the gamma plane is much easier pictorially if we do that initial 90 
degree CW alpha rotation so that the gamma rotation can be observed by 
rotating the device towards us around the y-axis rather than across our 
rotating around the y-axis across our viewing angle.

The rotation produces the same effect either way (since we then rotate 
the device around the body's y axis anyway).

>
>> Each user agent has implemented this differently which hints that we could
>> provide more information in this regard.
> Agreed.
>
>> I still think we should go further to include radar charts describing the rotation in each of three reference
>> planes for alpha, beta and gamma.
> I'm not sure a radar chart is appropriate. They're intended to
> simultaneously display multiple variables, with each variable
> presented on a separate axis of the chart. For your 'reference
> planes', there is only one variable (alpha, beta or gamma) being
> varied in each case.

Assuming a non-linear plot around 360 degrees of rotation I believe we 
would be plotting normative sensor values (in degrees) against device 
frame rotation in Euclidean space (in degrees). I'm hoping that a test 
operator (e.g. an implementer) conducting the relatively simple tests 
described could then compare the reading provided from their device in 
each described orientation in a well-defined reference plane against a 
normative reading provided in the spec and evaluate if that reading is 
therefore correct or not.

If a polar plot is not appropriate perhaps there is another simple 
visualization that we could produce and include? Any suggestions in that 
regard would be welcome considering the current non-standard state of 
implementations.

Thanks,

Rich

Received on Monday, 25 June 2012 14:04:00 UTC