A bit of mechanics today. We continued the assembly of the ball. The printed part and the case are fitting together. The next step is about placing the LEDs, which is not going to be easy. We haven’t decided the pattern we will use yet. It will strongly influence the future development of our project.

I also worked on the IMU and on the visualization of the data. I noticed a strange behavior related to the axes. The datasheet of the BNO055 gives the default axes for the measurements (see figure below). However, the default axes for the fusion algorithm are never mentioned. As the heading angle can be retrieved from the register EUL_DATA_X, we can logically think that the heading angular defines a rotation around the X axis. But no ! The heading angle defines a rotation around the Z axis, which is by the way the most used convention. This was not a big deal. A few rotation and parameters to modify and it is now all right. These hours of openGL were usefull.

Are you *really* sure you want the Euler Angles? They carry inherently quite a few problem (discontinuities, ambiguities). The quaternion approach doesn’t have these problems…

What do you mean by ambiguities ?

I am not sure but it seems to be a simple approach for our project. With Euler angles, we are in a simple 3D space. We need to “convert” Euler angles into transformations over images. Is that simpler with quaternions ? By now, I really don’t know. That’s not very clear.

However, using quaternions with openGL is really simple (if glRotatef() is correctly implemented). The passage from Euler angles to quaternions is easy for our little soft. The other way is a bit more difficult.

We’ll talk about it tomorrow, but I’m not sure that Euler angles are best suited for you.

Any rotation in 3D space can be modeled in two main ways (well, there are others ways, let’s forget them for the moment) :

– Euler angles : the rotation is decomposed in 3 successive rotations around the main axis of the main referential. But this decomposition in 3 rotations is not unique. And some positions (upside-down for example) suffer from unavoidable discontinuities, which are very uncomfortable to deal with in software.

– quaternion : any 3D rotation is simply one single rotation of a certain angle around a particular vector. As quaternions don’t carry the angle, but its sinus / cosinus, there are never any discontinuity. Quaternion can be very easily composed to build successive rotation, and can be very easily transformed to Euler angle if you wish. Basically, a quaternion is just a 4 dimensional vector specifying the axis of rotation in the referential space and the rotation angle : [rotation angle, X, Y, Z]. To make calculations more easy, they are in fact defined as [cos(a/2), 0, 0, 0] + sin(a/2)*[0, X, Y, Z]. With “a” the rotation angle, and “X”, “Y” and “Z” the coordinates of the rotation axis. One usually scales X, Y and Z so that that the quaternion has a unitary norm.

Quaternions easily can be derivated, integrated, interpolated (try to do the same with Euler angles :p …). And if anyway you need the Euler angle, as they are simpler to visualize for us human, they are very easy to get from quaternions.

Getting a rotation matrix from a quaternion is very simple. From Euler angles, this might be tricky (especially if the object is pointing toward the sky). But anyway, almost every OpenGL transformation accept quaternions as input.

More details here: http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation

Alexis, did you implicitly mention the gimbal lock problem in your explanation?

(if the object is pointing toward the sky?)

@Drix I didn’t know such problems could occur. Have you experienced it ?

@drix : yep, exactly !

@Clestrelin: I am currently testing it but I suspect I experience the problem, I’ll keep you updated 😉