Euler vs Tait-Bryan Angles

[dknguyen]

Can someone clarify the difference between the two? Tait-Bryan angles seem to make sense to me- you first align the rotating coordinate system to the fixed coordinate system, and then from there you just always rotate things relative to the axes of the rotating coordinate system. There are 3 relative axes of rotation being used.

But I'm a bit confused about euler angles. I would have though it would be rotating with respect to the fixed coordinate system all the time. But from the animations on wiki:
https://en.wikipedia.org/wiki/Euler_angles
it appears that only one of the 3 rotations occurs about a fixed axis, and the other two occur about relative axes.

Is anyone able to ballpark the processing power and frequency/processing time required to do the following:

-sample readings from 3-axis gyro simultaneously
-multiple these readings by the time between this and the last sample to get the change in orientation between samples
-do the matrix calculations to convert these relative orientation changes into the orientation changes of a fixed external frame
-add these changes in orientation relative to the fixed external frame to the previously calculated orientation in the fixed external frame (to update the absolute orientation measurement)
-repeat

 

[Nigel Goodwin]

From the title I thought it was a boxing match!

 

[dknguyen]

Yeah Tait-Bryan does sound like a boxer like Frederick Tatum from the systems.. Euler vs Cardan sounds more like mathematicians going at it.

 

[dknguyen]

It seems I *might* be able to make it fit onto a dsPIC and run far faster than I thought. It seems the matrix calculations aren't the killer. It's the trig calculations, but if my understanding is correct about vectors (I'd hope so! I had to take that mechanical course twice!), then if I used vectors to represent rotations about an axis I can use dot products to project rotations from one axis onto another (similar to how what is done when using vectors to represent regular magnitudes with a linear direction like a force). If this is true, then that means I can completely avoid any trig calculations and reduce the execution time by at least a couple hundred times if the dsPIC math library timings are what they say they are.

We never did any 3D math in that course. Only 2D where we used 2 vectors to indicate the two axes and we used a third to represent an angular speed in the 2D plane. I don't see why I wouldn't be able to represent rotations in all 3 axes by using vectors and using the same operations.

But this seems TOO simple because Euler angles and Bryan-Taint angles are chock full of trig expressions in their matrices. I wonder if I am missing something. Because they use angles that are applied in a specific order to orient an object. What I described depends on simultaneously rotating (and therefore sampling) each axis- all rotations on all axes happen at the same time...

This article seems to support what I am thinking:
https://farside.ph.utexas.edu/teaching/301/lectures/node100.html

But on the condition that the angles are small enough such that you can assume the rotation is constant about a single arbitrary axis in space. It says that only small angular changes are commutative (which is what I care about). Stemming from this, because of the way angular velocity is related with very small angular changes over a very small period of time you can always represent angular velocity as a vector (which is what we did in class). So it means it just means I have to be extra careful that I satisfy this requirement since angular changes are my interest and not angular velocities.

I should take another MecE class.

 

[3iMaJ]

Matrix operations are far more compuationally intenstive than trig operations. A trig operation can just be approximated by a few terms of a taylor series. But for example a matrix multiply takes N^2 operations, and that only assumes real number entries in the matrix. A matrix inverse requires N^3 operations.

If you get to make the small angle assumption then the taylor series can be even shorter. Recall for small angle sin(b) = b.

 

[dknguyen]

Matrix operations are far more compuationally intenstive than trig operations. A trig operation can just be approximated by a few terms of a taylor series. But for example a matrix multiply takes N^2 operations, and that only assumes real number entries in the matrix. A matrix inverse requires N^3 operations.

If you get to make the small angle assumption then the taylor series can be even shorter. Recall for small angle sin(b) = b.

I dunno. THese dsPIC libraries are giving me things like 3000 cycles for a trig function and 100 cycles for a vector dot product.

 

[3iMaJ]

How big are the matricies that you're dealing with? And why not just use a taylor expansion of the trig functions you require that'll be a lot faster than using the library functions. You only need a few terms of each of the functions since you're dealing with small angles, maybe just a few terms.

Yes, dot products are fast, I thought you were doing matrix - vector multiplications.

 

[dknguyen]

I would think they are 3x3 matrixes using the rotational formulas (and those have trig functions in trig functions and I don't understand them entirely yet).

 

[3iMaJ]

Yeah 3x3 is no problem, I guess I was thinking about upwards of 100x100 or larger, thats when matrix operations become quite slow.

All you need to do is write a function that approximates the trig functions you need and if you require trig functions in trig functions thats easy to adjust to.

I attached a quick simulation of a 2nd order taylor expansion approximation of a sin function, it holds reasonably well up to 17 degrees. I also included a 5th order approximation on the same plot that holds up to probably 3/2*pi.