surfaceTransformPoints rollPitchYaw inconsistent

I am using the surfaceTransformPoint utiity from the official latest release v1812 and found the results from using the utility with roll, pitch yaw angle at the same time inconsistent with using the utility three times sequentially specifying the same angles.

Also, when comparing the location of an arbitrary point on the STL with the results from octave using the rollPitchYaw rotation matrix the results are consistent with the sequential use of surfaceTransformPoints but not with the use in one shot.

Am I missing something or could be this a bug?

assigned to @mark

Hi Riccardo @Ricky-11 ,

Can't really tell if it is a bug, user error, or inconsistent definitions in octave. It might be some confusion of forward vs reverse transformation (ie, local to global vs global to local) that typically messes people up. It might also be something else.

The best way to start figuring things out is probably with the applications/test/quaternion/Test-quaternion.C - it currently has roll/pitch/yaw as well as yaw/pitch/roll options, and an axis-angle as well. It dumps out the rotation matrix, which makes it a good place to start.

To further with investigation, I just added in some additional options for testing euler angles as well as manual x-y-z and z-y-x transformations, but for a simple test it looks okay to me. Eg,

Test-quaternion -rollPitchYaw '(10 20 30)' -yawPitchRoll '(10 20 30)' -xyz '(10 20 30)' -zyx '(10 20 30)'

Yields the same for rollPitchYaw as doing the x-y-z manually. Might still need to check if there still isn't something odd lurking elsewhere. I'll push the update test file so that you can play around with it.

mentioned in commit d23c4b661ecb42aeaba154ba28b82c125f56dc40

Thanks for the quick feedback and the info @mark.

One thing I'm not sure I got: if you do the following:

surfaceTransformPoints -rollPitchYaw '(30 0 0)' geo01.stl geo02.stl surfaceTransformPoints -rollPitchYaw '(0 -15 0)' geo02.stl geo03.stl surfaceTransformPoints -rollPitchYaw '(0 0 -5)' geo03.stl geo04.stl

or:

surfaceTransformPoints -rollPitchYaw '(30 -15 -5)' geo01.stl geo04.stl

should you get the same result for geo04.stl?

By Riccardo Rossi on 2019-04-26T18:03:52 (imported from GitLab project)

It is indeed a bit confusing (need to recheck the maths), but the order of operations is likely the opposite from what you are attempting. To make sure we are both on the same page, we'll use the wigley hull geometry (from tutorials/resources) and stick with our (10 20 30) rotations. Paraview will help here.

If we look at the code for the -rollPitchYaw option, we see that it forwards to the quaternion with an XYZ rotation sequence. Further digging in quaternionI.H shows that we indeed have this:

case XYZ:
    operator=(quaternion(vector(1, 0, 0), angles.x()));
    operator*=(quaternion(vector(0, 1, 0), angles.y()));
    operator*=(quaternion(vector(0, 0, 1), angles.z()));
    break;

So the roll-pitch-yaw corresponds to Rx & Ry & Rz.

For testing:

surfaceTransformPoints -rollPitchYaw '(10 20 30)' wigley.stl full-r10p20y30.obj

If we apply the transformations sequentially, we would unroll from right to left, peeling off the Rz first and leaving the Rx & Ry:

surfaceTransformPoints -rollPitchYaw '(0 0 30)' wigley.stl y30.obj

Next peel off the Ry, leaving only Rx:

surfaceTransformPoints -rollPitchYaw '(0 20 0)' y30.obj p20y30.obj

Finally the Rx:

surfaceTransformPoints -rollPitchYaw '(10 0 0)' p20y30.obj r10p20y30.obj

This geometry should now be the same as full-r10p20y30.obj.

As at least this one link shows (http://petercorke.com/wordpress/roll-pitch-yaw-angles) there is some uncertainty whether a ZYX or XYZ sequence should be applied. Having said that, my first reaction (subject to revision later) is to tend to agree with you that the roll-pitch-yaw sequence should mean that rotate about X, followed by Y and finishing with Z. Ie, Rz & Ry & Rx. In which case our current definition of quaternion rotation sequence is backwards or originally laid out for local-to-global instead? At this point, I'm not entirely certain, but we'll need to continue the discussion.

changed title from surafaceTransformPoints rollPitchYaw inconsistent to surfaceTransformPoints rollPitchYaw inconsistent

@Sergio @matej - what are your thoughts on this? My tendency is that reading 'XYZ' from left to right should correspond to the rotation order, but within the quaternion this has been mapped to matrix order (ie, backwards). The only places using this are the transform points (this topic), and these:

• SDA.C
• oscillatingRotatingMotion.C
• tabulated6DoFMotion.C
• sixDoFRigidBodyState.C

Hey @mark.

Just wanted to let you know I've performed the tests you suggested on my geometry and double checked with the calculation using the rotation matrices in Octave and everything is consistent.

My problem was indeed looking at the rollPitchYaw option in surfaceTransformPoints and thinking straight it would have applied that sequence (roll->pitch->yaw) instead of using the (literature consistent) backward convention.

By Riccardo Rossi on 2019-05-03T21:50:03 (imported from GitLab project)

Hi @Ricky-11 I was still bothered by this apparent inconsistency and dug some more. The real issue is not just ordering, but more importantly the intrinsic vs extrinsic rotation angles (forget what I wrote before about the Rx & Ry Rz).

To make for an extreme example, suppose we have `-yawPitchRoll (90 0 90)' and an airplane with global x-axis pointing East, and y-axis pointing North (z is up). The airplane is initially heading East.

Intrinsic (using the body's internal coordinates):

• Applying a 90deg yaw means the airplane is heading north, the 90deg roll (around its own axis) means that it is still heading north but with its belly to the west.

If we do the same as extrinsic rotation (using the global x-y-z axes), this corresponds to what happens if you call surfaceTransformPoints in two separate stages.

• The result of the 90deg yaw is the same as above. However, if the "roll" is applied as an extrinsic angle, this rotation around the global x-axis means that the airplane is now heading straight up.

BTW: I doubled-checked with -rollPitchYaw (45 0 45) and the result looks OK, but will never be the same as applying each separately.

mentioned in commit 2c0dfaed5656513b12f7bd17e4073d02c26d77fa

@Ricky-11 - okay to close?

Hi @mark.

Sorry for taking so long to reply.

Not sure if we are on the same page, but I went back double checking by performing the following tests:

surfaceTransformPoints -rollPitchYaw '(30 -15 -5)' input1.stl output1.stl surfaceTransformPoints -rollPitchYaw '(0 0 -5)' input2.stl tmp1.stl surfaceTransformPoints -rollPitchYaw '(0 -15 0)' tmp1.stl tmp2.stl surfaceTransformPoints -rollPitchYaw '(30 0 0)' tmp2.stl output2.stl

The output1.stl is equal to output2.stl in Paraview.

Also, using:

surfaceTransformPoints -rollPitchYaw '(-30 0 0)' output1.stl tmp1.stl surfaceTransformPoints -rollPitchYaw '(0 15 0)' tmp1.stl tmp2.stl surfaceTransformPoints -rollPitchYaw '(0 0 5)' tmp2.stl output3.stl

gives output3.stl equal to input1.stl.

In my humble opinion, the utility works as expected both in "forward" and "backward" mode. The only possible confusion follows from the option flag, which may suggest the rotation order applied is roll->pitch->yaw instead of the actual yaw->pitch->roll sequence (consistent with theory).

Let me know what you think.

R

By Riccardo Rossi on 2019-05-15T21:06:45 (imported from GitLab project)

A side note: the transform filter in Paraview seems to work the opposite way, e.g.: roll->pitch->yaw when specifying the three rotation angles in the input panel in one shot.

By Riccardo Rossi on 2019-05-15T21:22:30 (imported from GitLab project)

mentioned in commit 9fa4561d89ce0e2f325b5fc214f9b4087487af1e

mentioned in commit 34df86cf11d79dac167e497cbe5ae648bce58ac2

closed