Gyroscope input issues

[planiitis]

The current vec3 gyroscope uniform provides incomplete gyroscope data, as it reduces the 3DOF gyroscope data into a 2DOF constant-length vector.

Furthermore, I have trouble interpreting the data. As I understand it, the current gyroscope uniform starts as a vector at [1.0, 1.0, 1.0]. This vector then continuously gets rotated according to gyroscope input. The vector appears to be relative to the device's frame of reference, as by my observations, rotating the device around a single particular sensor axis results in the vector being rotated correspondingly around that particular axis. I haven't been able to make much sense of it beyond that. In particular, I've tried to interpret the gyroscope vector as being in the same frame of reference as gravity, linear and magnetic, but no matter how I try to flip and rotate it, it doesn't fit with the rest of the vectors.

I'm no geometer, but could it be that something is backwards in GyroscopeListener.java? Something tells me either the rotation angles should all be negated, or the vector should rather be multiplied by the inverse of deltaRotationMatrix there in order to make sense.

Possibly, if GyroscopeListener.rotation were a rotation matrix rather than a vector, the data might make sense, and if provided as a uniform similar to rotationMatrix, could be used to create vectors that appear to be in the same frame of reference as gravity and magnetic. I understand the following to apply to the existing rotationMatrix uniform and would expect it to apply for deltaRotationMatrix, and by extension, any matrix rotated by deltaRotationMatrix as well:

Note that because OpenGL matrices are column-major matrices you must transpose the matrix before using it. However, since the matrix is a rotation matrix, its transpose is also its inverse, conveniently, it is often the inverse of the rotation that is needed for rendering; it can therefore be used with OpenGL ES directly.

Additionally, often one might only care about the angular speed of device rotation. Then a uniform providing either direct access to the gyroscope data or to deltaRotationMatrix would make sense.

[markusfisch]

Well, the code in GyroscopeListener is based on the documentation, so I think it's correct. But I may be wrong, of course!

Unfortunately, I haven't got a shader at hand to test whether this correct or not at the moment. But since this open source, you may of course play around with it and see if you can make it work for your sample 😉

Something tells me either the rotation angles should all be negated, or the vector should rather be multiplied by the inverse of deltaRotationMatrix there in order to make sense.

I think inversing isn't required because:

However, since the matrix is a rotation matrix, its transpose is also its inverse, conveniently, it is often the inverse of the rotation that is needed for rendering; it can therefore be used with OpenGL ES directly.

[planiitis]

Well, the code in GyroscopeListener is based on the documentation, so I think it's correct. But I may be wrong, of course!

Looking at the comment in the example code:
// rotationCurrent = rotationCurrent * deltaRotationMatrix;
I believe rotationCurrent here is meant to be a matrix, not a vector as in the case of GyroscopeListener.rotation. A rotation matrix can be inverted as needed (and will be by default when provided to OpenGL), a rotated vector cannot be inverted in the same way to get the "inverse-rotated" vector.

I think inversing isn't required because:

However, since the matrix is a rotation matrix, its transpose is also its inverse, conveniently, it is often the inverse of the rotation that is needed for rendering; it can therefore be used with OpenGL ES directly.

Here's how I understand it: If the gyroscope uniform were a matrix, you'd be right. But it's a vector, so the transposition does not happen.

[planiitis]

I made a shader to explore the different orientation vectors: https://gist.github.com/planiitis/d940919503d442f0c7287ae10f74b466

Set Sensor Delay to Game or UI for best results.

The shader provides a view of the gyroscope, gravity, magnetic and linear vectors, as well as rotationMatrix. Assuming the device is in its non-rotated screen configuration, you can turn the device around to get a "camera view" of the various vectors.

• The four small circles around the horizon (denoted by a purple line) show the cardinal directions given by rotationMatrix.
• A green circle shows the direction of magnetic, pointing to magnetic north.
• The red and purple circles show gravity and gravity + linear, both negated so that they point downwards for convenience and a more intuitive view.
• The yellow line goes through the gravity and gyroscope circles.
• The yellow circle represents the gyroscope vector.

Current code negates the x and y coordinates of the gyroscope vector. That makes the gyroscope circle move correctly with respect to the others when rotating the device about its x or y coordinate. However, rotation around the device's z coordinate is still backwards: Try laying the device on a level, non-magnetic surface with its screen facing up, then rotate the device clockwise. If the magnetic circle is in view, you should see it stay in place relative to yourself, or moving counter-clockwise relative to the device screen, as expected. However, the yellow line that points to the gyroscope vector will rotate clockwise relative to the device screen, rotating at double speed relative to yourself.