Docstrings for RotXYZ and similar could cause confusion with keyword arguments

[kramsretlow]

Taking RotXYZ(roll=r, pitch=p, yaw=y) as an example, the docstring says

The keyword argument form applies roll, pitch and yaw to the X, Y and Z axes respectively, in XYZ order.

I began somewhat uninitiated on Euler angles, so it took me quite some time to realize that XYZ order refers the the order of matrix multiplication (RxRyRz), rather than the sequence of actually carrying out the rotations. I thought it meant first rotate around the X axis by r, then around Y by p, then around Z by y.

The first sentence in the same doscstring is super clear, indicating the sequence of rotations and which argument is used for each, so maybe this pattern could be used for the keyword arguments case too. Also perhaps it could be made clear that the keyword arguments essentially relate to argument order, e.g. RotZXY(a, b, c) == RotZXY(roll=b, pitch=c, yaw=a). Or maybe just use X, Y, Z as keyword arguments?

Thanks for your work on the package!

[KronosTheLate]

Not a maintainer (or even contributor) but I agree with your point. What do you think about the tables I created in this comment? That are obviously too much for a docstring, which is the issue here, but the docstrings could always refer to the readme as a reference for the "theory" required to understand the package.

[kramsretlow]

I like your table 😄 and thanks for the link to the other discussion. For me, everything became clear when I saw the mathematical expressions in the docs, so maybe just an example and a URL is enough for the docstrings. Adding intrinsic vs. extrinsic rotations to the mix adds more complexity, but good to see this is being discussed in the other issue.

[nlw0]

I'd like to add another observation I believe is quite important. It's great that "yaw" "pitch" and "roll" keywords are offered. But my understanding is that they are always available as simple aliases to the z, y and x parameters. I don´t think this should be offered as such.

These angles "yaw", "pitch" and "roll" have a very specific meaning. When you rotate an object, and you look at the angle of the projection of the object's rotated x-axis onto the x-y plane of your reference frame, that vector's angle is the yaw. When you look at the angle between the x-axis and the x-y plane, that is the pitch. The roll is the rotation around the x axis that would bring the y-axis parallel to the x-y plane. (There might be other conventions).

It is not the case that these angles map generally to the parameters of every RotABC function. It's only for RotZYX. For example, let's compute three different rotations here using the "y-p-r" keywords, then compute the yaw based on the transformation of the x component:

julia> using Rotations

julia> let a = RotXYZ(roll=0.1, pitch=0.1, yaw=0.1) * [1,0,0]; atan(a[2], a[1]) end
0.1099067372983192

julia> let a = RotXZY(roll=0.1, pitch=0.1, yaw=0.1) * [1,0,0]; atan(a[2], a[1]) end
0.10946117877752662

julia> let a = RotZYX(roll=0.1, pitch=0.1, yaw=0.1) * [1,0,0]; atan(a[2], a[1]) end
0.1

This shows only RotZYX really gives you back the desired "yaw".

The fact the keywords are offered in all cases is misleading, in my opinion. It should only be available for the RotZYX case, or it should be only available through a special function that will probably call RotZYX under the hood, because that's the easiest way to implement the desired rotation.

In other words "roll", "pitch" and "yaw" are not really just aliases to the parameters in general, they are properties of the rotation, and they only directly map to parameters for the specific case of RotZYX. We might even have a function that computes the yaw of a certain RotXZY rotation, for instance, and it wouldn't be just copying the z parameter.

Maybe things are more complicated if you consider other conventions instead of x to the front, but I don't it's really helping not to point out what you probably want is to be using RotZYX.