# Calculating pose in terms of Euler angles for a plane using direction vectors.

I'm trying to find the pose of a rectangular plane in 3D space. I have two orthogonal vectors a and b that lie on the plane and centered at origin.

I take the cross product of the two and get another vector c. I compute the norm of the vectors a, b, and c and calculate the Euler angles using the following equations:

roll = tan^-1(bk/ck)

pitch = sin^-1(ak)

yaw = tan^-1(aj/ai)

Here, i, j, and k represent the components along X, Y, and Z axes.

Now, during the in-plane rotation (when the plane is rotated along Z axis), if the plane is rotated towards the right it outputs the correct pose, but when it's rotated left or flipped it gives the wrong pose (verified in rViz).

I'm wondering whether there are any limitations of calculating Euler angles like this or maybe my calculations are wrong?

Edit:

I have added the following images for better understanding. The blue axis should point towards the camera, when I rotate the book left-ward, the blue-green plane rotates around red axis.

### Same pose without pointcloud

edit retag close merge delete

Sort by ยป oldest newest most voted

Couple of thoughts:

• I think you might want to be asking why you even want the Euler angles. Given the three orthonormal vectors you already have a unique representation of the orientation of that plane in terms of an SO(3) rotation matrix (the three vectors can be thought of as the columns of the rotation matrix). Euler angles have issues with ambiguity (there are 24 different 3-parameter representations of orientation... which one do you mean when you say "Euler angles"), and every one of the 24 representations has singularities. If you can instead do whatever you are trying to do directly with SO(3) or Quaternions, I think your life will actually be a lot easier.
• If you do need to convert the three vectors into some notion of Euler angle, rather than reinventing the wheel, I'd use a library that already supports this. For example in the tf2::Matrix3x3 class there is both getEulerYPR and getRPY.
• I'd double check that the vectors you are computing (however you are getting them) are staying consistent relative to the plane. Many algorithms I've used in the past for plane segmentation have ambiguities and can sometimes return, for example, either the normal vector Z or the inverse of the normal vector. If the vectors are switching signs it's possible that's the root cause of your issue.
• Also, FWIW, I think the equations you list don't actually work for compound rotations. Your expressions are much simpler than what is typically used. See for example, this PDF that lists many of the conversions
more

@jarvisschultz I've tried the first two points that you suggested and the output was the same. The third point is what, I think, actually happening. Could you elaborate a bit on vectors are staying consistent relative to the plane. I'm detecting a book using SIFT; and using homography I'm computing the center and x, y vectors on the plane of the book and then the corresponding 3D values to further generate orthonormal 3D vectors. When the book rotates in the image so do the 2D vectors. Is it something to do with calculating the z-axis?

( 2021-02-12 21:43:58 -0500 )edit

Based on the images you added, I'd agree that the third bullet seems like the most-likely issue you are encountering. You mention that the 2D vectors do rotate when the book rotates, but it doesn't seem like that statement holds true for the entire circle of rotation. The problem you are trying to debug is very different than the problem you originally posted about. Moreover, I'm not so sure the problem has anything to do with ROS (it barely had anything to do with ROS to begin with). Perhaps the OpenCV forums would be a better place to ask follow-up questions: https://forum.opencv.org/

( 2021-02-15 17:30:25 -0500 )edit