W3C home > Mailing lists > Public > public-geolocation@w3.org > September 2010

Re: Comments on DeviceOrientation Event Specification, Editor's Draft 24 August 2010

From: Dean Jackson <dino@apple.com>
Date: Thu, 2 Sep 2010 12:55:51 +1000
Cc: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Message-Id: <0B2B9F88-19BC-4B64-8E34-2A480A9A02F6@apple.com>
To: Steve Block <steveblock@google.com>

On 01/09/2010, at 8:39 PM, Steve Block wrote:

> Thanks for the comments Claes.
>> -          We propose a  boolean 'needsCalibration' property that indicates
>> that the magnetometer needs calibration.
> This seems reasonable to me. Unless there any objections, I'll add
> this to the spec.

On both interfaces?

I wonder if a simple "calibrated" property is better? Using "needs" in the name implies that the user might have to do something (which they probably do, but the property is exposing the status of calibration).

>> -          In the current version of the specification the device
>> orientation data is provided as Euler angles. However, there are other ways
>> of providing sensor data. I looked at the following interesting
>> presentation: http://www.youtube.com/user/GoogleTechTalks#p/u/0/C7JQ7Rpwn2k
>> . At the end of the presentation different ways of exposing sensor data for
>> developers are described. There are apparently limitations with Euler angles
>> that occurs when the device is pointing right up, Gimbal lock,
>> http://en.wikipedia.org/wiki/Gimbal_lock. Do you consider this limitation
>> acceptable meaning that applications using the Device Orientation Event have
>> to be constrained taking the Gimbal lock problem into consideration?
> I'm aware of gymbal lock but I think that it's probably not a problem
> in most applications. The use of Euler angles still allows us to
> always express the orientation of the device. The only limitation is
> that certain device motions will cause extremely rapid changes in some
> of the angles and I think that for the simple use-cases for which the
> API is intended, this shouldn't be a problem.

Yeah, I think it will be a problem when becomes a readwrite API - then we could have rapidly flipping devices :)

I think the angles are the easiest to use. Converting into a rotation matrix is simple - going the other way isn't.

>> So, have you considered to also provide orientation data as a rotation
>> matrix?
> We chose Euler angles rather than a rotation matrix as for simple
> use-cases (such as determining the device's heading for a compass
> application, or its tilt for a gaming application), they're easier to
> work with. If we were to provide a rotation matrix, I think this
> should be an additional property.
> Personally, I'd prefer to leave this out, rather than increase the API
> footprint with properties that can be computed with a JavaScript
> library. If we see lots of user-feedback for this to be included
> natively, we could consider adding it in a later version of the spec.
>> -          As the attribute “acceleration” does not include the gravity
>> component we propose to call it “linearAcceleration”.
> I'm not sure why the term 'linear' would suggest anything about
> whether or not gravity is included? Have you seen the latest version
> of the draft spec, which provides both acceleration and
> accelerationIncludingGravity? Is this sufficiently clear?
>> -          It would be nice to have more examples on the Device Motion
>> Event.
> I've added a couple more. Feel free to suggest any further examples
> you think would be helpful.

Regarding the example "A device in free-fall, with the screen horizontal and upmost, has an accelerationIncludingGravity of zero and the following value for acceleration:"

I believe an accelerometer will not be able to tell the direction of gravity in this situation.


Received on Thursday, 2 September 2010 02:56:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:57 UTC