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

Steve and Dean,

* Ok, let us then stick to Euler angles in this first version. I realize that it is easy to convert to rotation matrixes if needed. 

* Acceleration vs linearAcceleration: Maybe the latter makes it more clear for developers that this is linear acceleration and has nothing to do with rotation or gravity. However, I have no strong opinion here.

Regards
  Claes 

> -----Original Message-----
> From: Dean Jackson [mailto:dino@apple.com]
> Sent: den 2 september 2010 04:56
> To: Steve Block
> Cc: Nilsson, Claes1; public-geolocation@w3.org
> Subject: Re: Comments on DeviceOrientation Event Specification,
> Editor's Draft 24 August 2010
> 
> 
> 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.
> 
> http://www.lunar.org/docs/LUNARclips/v5/v5n1/Accelerometers.html
> 
> Dean

Received on Friday, 3 September 2010 13:30:12 UTC