why point correspondence to rotation matrix calculation is not my expected?

for example, at first ,one point P1(1,0,0) rotate pi/2 angle by y-axis,then get the point P2(0,0,-1), then rotate pi/2 angle by x-axis, then get the point P3(0,1,0). i use eul2rotm function to specify eular angle to get rotation matrix,then get the destination point by premultipy format,but get the result is not my expected P3?

P1 = [1,0,0]; 
eular = [0,pi/2,pi/2]

eular = 1×3

0 1.5708 1.5708

r = eul2rotm(eular,'ZYX'); % premultipy format
destinationPt = r*P1' % not same as P3 ?

destinationPt = 3×1

0.0000 0 -1.0000

if i take eular decompose into two component, ie rotate pi/2 angle correspondance to y-axis,x-axis, then i can get my expected result P3.

eularY = [0,pi/2,0];
eularX = [0,0,pi/2];
ry = eul2rotm(eularY);
rx = eul2rotm(eularX);
destiPt = rx*ry*P1' % is same as P3, which is my expect result.

destiPt = 3×1

0.0000 1.0000 -0.0000

i don't understand why eular angles vector three components not write together?

Answer 1

[Matt J]

r needs to be pre-multiplied by P1, not post-multiplied.

P1 = [1,0,0]; 
eular = [0,pi/2,pi/2];

r = eul2rotm(eular,'ZYX'); 
destinationPt = P1*r 

destinationPt = 1×3

0.0000 1.0000 0.0000

[cui]

pre-multiplied means r should put before coordinates, see here example "Rotation Matrix" setction and this pre post multiply definition.("Extract Quaternions from Transformation Matrix" setction)

Even according to your meaning, if I change eular to [0,pi/2,0] and keep everything else the same, the result should be [0,0,-1], but according to the code you provided, the result is [0,0,1], how can I explain this?

P1 = [1,0,0]; 
eular = [0,pi/2,0];
r = eul2rotm(eular,'ZYX'); 
destinationPt = P1*r 

destinationPt = 1×3

0.0000 0 1.0000

is it if i can get this conclusion?

eul2rotm get the rotation matrix is premultiply format, ie, the following homogeneous transformation matrix format:

rigid3d get the rotation matrix is postmultiply format, ie, the following homogeneous transformation matrix format:

This rotation matrix obtained by eul2rotm still bothers me!

reference here:

Rotations, Orientations, and Quaternions for Automated Driving topic: "Extract Quaternions from Transformation Matrix" setction

[Matt J]

If the coordinates are supposed to be multiplied to the right of the rotation matrix, then it looks like the transformations are applied from right to left, i.e. ZYX means that first there is a rotation in X, then Y, then Z. I've attached some files that do elemental rotations (in degrees) to corroborate this.

eul=randi(90,1,3)  %random angles in degrees

eul = 1×3

84 27 9

%Test1
r1=eul2rotm(eul*pi/180,'ZYX')

r1 = 3×3

0.0931 -0.9749 0.2024 0.8861 0.1739 0.4296 -0.4540 0.1394 0.8800

r2=Rz(eul(1))*Ry(eul(2))*Rx(eul(3))  

r2 = 3×3

0.0931 -0.9749 0.2024 0.8861 0.1739 0.4296 -0.4540 0.1394 0.8800

%Test2
r1=eul2rotm(eul*pi/180,'XYZ')

r1 = 3×3

0.8800 -0.1394 0.4540 0.4623 0.0326 -0.8861 0.1087 0.9897 0.0931

r2=Rx(eul(1))*Ry(eul(2))*Rz(eul(3)) 

r2 = 3×3

0.8800 -0.1394 0.4540 0.4623 0.0326 -0.8861 0.1087 0.9897 0.0931

[cui]

Now that your experiment looks more reasonable, remember that you should change your answer to the following code.@Matt J

P1 = [1,0,0];
eular = [0,pi/2,pi/2];% ZYX order,Normal way
r = eul2rotm(eular,'XYZ');% first rotate around Z,then Y,final X, Looks a bit counter intuitive
destinationPt = r*P1'

destinationPt = 3×1

0.0000 1.0000 -0.0000

The correct code for the counterexample given in response to your answer would be as follows：

P1 = [1,0,0];
eular = [0,pi/2,0];% ZYX order,Normal way
r = eul2rotm(eular,'XYZ');% first rotate around Z,then Y,final X
destinationPt = r*P1'

destinationPt = 3×1

0.0000 0 -1.0000

[Matt J]

That's if the multiplication is supposed to be done with the coordinates on the right. Your documentation links are not consistent on this. An equivalent interpretation is that the coordinates go on the left and the angles are measured clockwise instaed of counter-clockwise.

[cui]

@Matt J I think the definition and examples of pre post multiply given in the document link are correct, but the order of the input parameters of the eul2rotm function sequence is easy to misunderstand, contrary to the norm. pre-multiply means that the coordinates are on the right side of the rotation matrix, and the counter-examples I gave above can be successfully verified.

[Matt J]

Either way, haven't we resolved your question? My tests above seem to show definitively how the rotation matrices are constructed by eul2rotm.

[cui]

Haha, your experiment did verify how eul2rotm constructs the rotation matrix, but it also indirectly gave the answer. As the answer to my recent reply above, it's just a matter of the order of the eul2rotm function parameters.@Matt J thank you!

BTW, The official documentation of the input parameter "sequence" from the eul2rotm function is written in the wrong order? It's not the intuitive order, it's the opposite.

[Matt J]

You're quite welcome, but please Accept-click the answer if it resolved your question.

[Matt J]

BTW, The official documentation of the input parameter "sequence" from the eul2rotm function is written in the wrong order? It's not the intuitive order, it's the opposite.

There are many contradictions in the documentation. The documentation for the "sequence" input explicitly says that ZYX means the Z rotation is done first,

As we've seen in tests above, that can only be true if coordinates are multiplied to the left of the matrix, and if the angle is measured clock-wise. Measuring angles clock-wise would indeed be non-intuitive and unconventional.

The highlighted text from the documentation below does say that the coordinates are to be multiplied on the left side of the matrix and the formula shown for rotm is consistent with a clock-wise, not a counter-clockwise rotation by α when multiplied on the left. However the code highlighted in blue after that is equivalent to pre-multiplying with rotm', not rotm. So, it's a mess...

[cui]

I took the time to feed this mess back to MTW to fix the correct documentation and hopefully give correct easy to understand examples in future versions.

[Matt J]

Great!

[cui]

It is good to hear that since R2022b, the computer vision toolbox and image process toolbox have started to support the use of the pre-multiply convention as a priority，while the default for other toolkboxs is the pre-multiply convention remains unchanged.