This is a very interesting comment. I totally missed that.Parity wrote:I can code, but didnt work with smartphone so far.
But looking into your code I saw you use the Sensor.TYPE_ORIENTATION
Playing around a bit, I realized that this sensor does this strange 180° jump when device is close to vertical, while Sensor.TYPE_ROTATION_VECTOR does not change that way.
Seems to be a different interpretation of the sensor data. Tried playing around with that?
Ever since the Sensor Fusion on Android video, I was really hoping to avoid issues like those of Euler angles (see 38:26)
Source: http://stackoverflow.com/a/11068878In API 8 and above, there are "virtual" sensors which are generated by combining the inputs of all available sensors and appropriate filters. The "TYPE_ORIENTATION" sensor gives you the allover orientation of your device, but this interface is deprecated due to failure states at certain orientations. The new sensor is TYPE_ROTATION_VECTOR (API 9 and above) which gives your device orientation as a quaternion. This is really the best sensor to use, but the math behind it is a little heavy.
Failing that, what you do is call SensorManager.getRotationMatrix(), passing the latest gravity and magnetometer data. This will return a rotation matrix which could be used to convert a vector from device coordinates to world coordinates or vice-versa (just transpose the matrix to invert it).
The getOrientation() function can give you heading, pitch, and roll, but these have the same failure states as the TYPE_ORIENTATION sensor.
More documentation about the TYPE_ROTATION_VECTOR sensor:
http://developer.android.com/guide/topi ... ion-rotate
And here: http://developer.android.com/reference/ ... Event.html
I'm starting to think that we should have been using TYPE_ROTATION_VECTOR all along.
But the phone needs the hardware to support it (just accelerometer won't work) otherwise you might get a NULL-value according to this guy
Good catch Parity