Should OrientationSensor interface provide Euler angles?

[alexshalamov]

All modern 3D JavaScript frameworks support quaternions and rotation matrices to represent rotation, however, sometimes, it might be useful to have Euler angles representation, so that web developers would not need to do manual conversion.

interface OrientationSensor : Sensor {
  readonly attribute FrozenArray<double>? quaternion;
  readonly attribute double? yaw;
  readonly attribute double? pitch;
  readonly attribute double? roll;
  void populateMatrix(RotationMatrixType targetMatrix);
};

[anssiko]

Sounds good. My assumption is we want to facilitate migration of legacy web content to this new API, and as such should align this feature with the Device Orientation API on details such as:

• Conventions. Use Tait–Bryan angles (as implied by your choice of attribute names) vs. classic Euler angles.
• Rotation order. Since the order in which the rotations are executed matters, we should probably use the same order used by the Device Orientation API: z-x-y.
• Intrinsic vs. extrinsic rotations. Again, for compatibility with the Device Orientation use intrinsic Tait-Bryan angles.
• Active vs. passive rotations. Use active rotation where the point is rotated relative to the coordinate system vs. the coordinate system rotates with respect to the point.
• Coordinate system conventions. Use right-handed Cartesian coordinate system with right-handed rotations aligned with the Accelerometer, Gyroscope, and Magnetometer specs.

It should be noted the Device Orientation API states:

the angles [alpha, beta and gamma] do not match the roll-pitch-yaw convention used in vehicle dynamics

@alexshalamov can you clarify whether this would be an issue. Also fix any false assumption I may have made.

The conventions checklist is borrowed from the practical definition of Euler angles conventions from an aerospace engineer. The Device Orientation API spec references Euler angles wikipedia entry, but I found it lacking in terms of conventions.

[anssiko]

Marked as "Level 2" per WG call decision.