jwick wrote:Christian should be able to scare up the src code for xcube (it may not be meant for outside consumption though). The Windows 3DxWare SDK contains src for several demos that have been scrubbed a bit better.
Ah, good hint. I had a look at the Windows SDK in the past, but somehow I failed to try to look there this time.
jwick wrote:The rotation values are NOT Euler Angles. You do not apply them in a specific order. They represent the axis of rotation.
That's a very interesting statement; I have not found that information anywhere.
jwick wrote:They are more like a quaternion that you mentioned you are familiar with.
OK, "more like" is a bit vague.. I am not sure that I can put that into code.
jwick wrote:You must not accumulate the axis values by themselves. You must accumulate them by applying them as a delta to an existing orientation. E.g., as a delta to a rotation matrix or a quaternion. As mentioned earlier, the Windows SDK contains a C function to convert them to a delta matrix. You must then accumulate that with your existing orientation.
As I said, the accumulating/coordinate spaces/math is not the problem. Your mentioning of "a C function to convert them to a delta matrix" makes me very curious though.
I must confess that I was quite angry when I first noted how much the Linux and Windows SDK APIs and drivers differ from each other. My impression is that the Windows version is more stable, better designed, and contains more features.
Now I will have a look whether "the Windows SDK contains" means "if you used Windows, you could simply use Sensor::Rotation to get an AngleAxis object, but all this is unavailable on Unix/Linux" or whether you mean "look at the example apps, which contain the appropriate conversion math in the provided source code". I thought it was the former, but maybe I was too pessimistic. I hope in the former case you can make the correct formula/algorithm public, so that all Linux users can benefit from it.
jwick wrote:That having been said, you can cheat if the angles are very small. You won't notice the difference if you multiply small X,Y,Z rotations together. You must then append that to your existing matrix. And perform the same step at the next event from the device.
That's what I am doing now, and what the "helix" demo seems to do as well. But you just supported my suspicion that this is not the correct way (tm).
Thanks so far for your insightful answer,