We're using the SensorFusion library to get roll, pitch, and yaw of an IMU. It works well and gives us angles with extrinsic orientation (orientation relative to a global coordinate system). Is there an easy way to convert one or more of the angles to intrinsic orientation (rotation relative to the IMU itself)? Here's the library, if that's helpful (we're using the Mahony algorithm).
For some background, this is for a musical instrument that can vary the sound based on orientation. Currently (with extrinsic orientation) , the roll, pitch, and yaw are all intuitive if the device is held horizontally, but if the device is is tipped (moved out of the global/extrinsic frame of reference) then the roll, pitch and yaw interact with each other and it's not entirely intuitive.
It makes no sense to use Euler angles. There are 12 different definitions, and the order of operations is absolutely critical. Plus there is the problem of "gimbal lock", where the angles become indeterminate.
The quaternion computed by the Mahony algorithm represents the orientation of the object in the Earth reference frame. The inverse operation is easily computed using quaternion multiplication, and is described in many introductory tutorials, for example this one and this much more extensive treatment.
It is further possible to interpolate intermediate orientations in a useful and very intuitive way (look up quaternion interpolation), used extensively in computer graphics virtual reality code.
Thank you. My understanding of all this (and the math involved) is very basic, but if I understand you correctly, you are saying that we should rotate the quaternions to the intrinsic frame before converting to roll, pitch, and yaw, is that correct? Do you know of a library that would do this for us?
For our application we'd like to map rotation around the three axes to three different audio parameters, so that's why we'd like to end up with roll, pitch, and yaw relative to the intrinsic frame.
As you have already indicated, users find those angles to be non-intuitive and not very useful, especially when the object orientation is far from the Earth frame of orientation.
Euler angles are fine for representing small deviations from level flight, but not much else.
I'm not sure I follow you-- my reference to them being non-intuitive was because they currently are relative to the Earth frame of reference. So, for example when the device is pitched forward 90 degrees then roll relative to the body frame becomes yaw relative to the Earth frame. That is definitely non-intuitive but it is our belief that it would become intuitive if the angles were relative to the body frame.
No, sorry, I'm not explaining myself well. We'd like to get rotation about each axis (from 0-90 degrees) that is independent of how the device is held relative to the other two axes. So, our "roll" (maybe not the correct term) should be the rotation around the X axis of the device regardless of whether the device is pitched forward along the Y axis. This is actually what the diagram in the ReadMe for the library shows, but the library actually returns rotations relative to the Earth frame, as you mentioned.
It will take quite a bit of careful thought to implement that idea correctly, given that the Mahony filter quaternion represents one 3D orientation at any one time, and there is no unique way of representing a given transformation from any one orientation to any other.
This reference, linked above, describes the possibly useful axis/angle representation.
Perhaps just integrating the gyro rate data will give you some ideas, as a place to start.
The gyro is tethered to the body coordinate system, whereas the magnetometer and accelerometer references are tethered to the Earth coordinate frame.
You can try gyro-only integration of the quaternion rate of change with this code (MPU6050_gyro_only.ino), intended for the long obsolete MPU-6050.
The resulting Euler angles are always relative to the starting orientation, and will slowly drift, depending on how well the gyro offsets are estimated and removed.
Thanks for all your help-- this is good food for though. Just out of curiosity, because you mentioned that Euler angles aren't intuitive from a user's standpoint, if you were designing a musical instrument that used an IMU to modify the note that is currently playing (by sending MIDI CC messages), is there an alternative approach that you would recommend?
I think your basic idea will work, just not intuitively if you choose to follow conventional Euler angle rules.
Since I work in computer graphic applications, a good case in point is the use of a mouse to rotate an object in 3D, as viewed on a CAD screen. It took a long time for developers to discover the mouse movements and corresponding coordinate transformations that were intuitive to users, and allowed them to quickly achieve the desired object view.
