ROS Answers: Open Source Q&A Forum - RSS feedhttps://answers.ros.org/questions/Open source question and answer forum written in Python and DjangoenROS Answers is licensed under Creative Commons Attribution 3.0Thu, 10 Nov 2016 23:59:46 -0600tf fixed transformshttps://answers.ros.org/question/247673/tf-fixed-transforms/Hello ROS users,
I'm slightly confused about how TF handles transforms.
I'm using the `tf::TransformBroadcaster` class in a node called `tf_broadcaster_node` for publishing transforms to TF, resulting in the following TF tree:
![image description](/upfiles/14787408397710589.png)
These frames have fixed transforms (only rotations), represented below as RPY(in degrees) :
- `base_link --> camera_frame` : **Rotation (-90, 0, 50)**
- `camera_frame --> bundler_camera_frame` : **Rotation is (0, 180, 0)**
I also have a `tf_listener_node` which is used to query and print these transforms from TF. My expectation was that the fixed-value transforms will be printed exactly as defined above. However, I was surprised to note that they were different:
![image description](/upfiles/14787399249395574.png)
**Question : Why do the fixed transform values differ from their definitions?**
I'd appreciate any assistance in helping me understand TF better. Thanks!Wed, 09 Nov 2016 19:23:56 -0600https://answers.ros.org/question/247673/tf-fixed-transforms/Answer by rbbg for <p>Hello ROS users, </p>
<p>I'm slightly confused about how TF handles transforms. </p>
<p>I'm using the <code>tf::TransformBroadcaster</code> class in a node called <code>tf_broadcaster_node</code> for publishing transforms to TF, resulting in the following TF tree:</p>
<p><img alt="image description" src="/upfiles/14787408397710589.png"></p>
<p>These frames have fixed transforms (only rotations), represented below as RPY(in degrees) :</p>
<ul>
<li><p><code>base_link --> camera_frame</code> : <strong>Rotation (-90, 0, 50)</strong></p></li>
<li><p><code>camera_frame --> bundler_camera_frame</code> : <strong>Rotation is (0, 180, 0)</strong></p></li>
</ul>
<p>I also have a <code>tf_listener_node</code> which is used to query and print these transforms from TF. My expectation was that the fixed-value transforms will be printed exactly as defined above. However, I was surprised to note that they were different:</p>
<p><img alt="image description" src="/upfiles/14787399249395574.png"></p>
<p><strong>Question : Why do the fixed transform values differ from their definitions?</strong> </p>
<p>I'd appreciate any assistance in helping me understand TF better. Thanks!</p>
https://answers.ros.org/question/247673/tf-fixed-transforms/?answer=247699#post-id-247699Hi Venkat,
As you might be aware, a rotation can be expressed in several different representations. RPY is often used as it is fairly easy to visualize and recognize what the rotation is, but it has some problems with regards to singularities. Under the hood, TF uses quaterions, which means that if you are broadcasting and listening to a transform in euler angles like RPY, it will have to translated *to* and *from* quaternions. A single rotation can be expressed in several different set of RPY angles, for instance, a Pitch of 180 degrees is identical to first a roll of 180 degrees and then a yaw of 180 degrees (Like your `camera_frame --> bundler_camera_frame`) For your `base_link --> camera_frame`, it also works out.
An easy way to check that the transforms are what you intend for them is to use the TF plugin in RVIZ. If they are not what you intended, there is another problem, but I suspect this was the root cause.Thu, 10 Nov 2016 00:10:44 -0600https://answers.ros.org/question/247673/tf-fixed-transforms/?answer=247699#post-id-247699Comment by rbbg for <p>Hi Venkat,</p>
<p>As you might be aware, a rotation can be expressed in several different representations. RPY is often used as it is fairly easy to visualize and recognize what the rotation is, but it has some problems with regards to singularities. Under the hood, TF uses quaterions, which means that if you are broadcasting and listening to a transform in euler angles like RPY, it will have to translated <em>to</em> and <em>from</em> quaternions. A single rotation can be expressed in several different set of RPY angles, for instance, a Pitch of 180 degrees is identical to first a roll of 180 degrees and then a yaw of 180 degrees (Like your <code>camera_frame --> bundler_camera_frame</code>) For your <code>base_link --> camera_frame</code>, it also works out.</p>
<p>An easy way to check that the transforms are what you intend for them is to use the TF plugin in RVIZ. If they are not what you intended, there is another problem, but I suspect this was the root cause.</p>
https://answers.ros.org/question/247673/tf-fixed-transforms/?comment=247826#post-id-247826I don't know which convention you are using, but this is the reason for the difference. The [quaternion api](http://docs.ros.org/api/tf/html/c++/classtf_1_1Quaternion.html) mentions RPY around fixed axis for the `setRPY` function.Thu, 10 Nov 2016 23:59:46 -0600https://answers.ros.org/question/247673/tf-fixed-transforms/?comment=247826#post-id-247826Comment by Venkat Ganesh for <p>Hi Venkat,</p>
<p>As you might be aware, a rotation can be expressed in several different representations. RPY is often used as it is fairly easy to visualize and recognize what the rotation is, but it has some problems with regards to singularities. Under the hood, TF uses quaterions, which means that if you are broadcasting and listening to a transform in euler angles like RPY, it will have to translated <em>to</em> and <em>from</em> quaternions. A single rotation can be expressed in several different set of RPY angles, for instance, a Pitch of 180 degrees is identical to first a roll of 180 degrees and then a yaw of 180 degrees (Like your <code>camera_frame --> bundler_camera_frame</code>) For your <code>base_link --> camera_frame</code>, it also works out.</p>
<p>An easy way to check that the transforms are what you intend for them is to use the TF plugin in RVIZ. If they are not what you intended, there is another problem, but I suspect this was the root cause.</p>
https://answers.ros.org/question/247673/tf-fixed-transforms/?comment=247811#post-id-247811Thanks! The rotation convention I've followed is:
- (yaw around Z, then pitch around new Y, then roll around new X)
I assume you are talking about rotating around fixed X, Y, Z axes?Thu, 10 Nov 2016 17:12:01 -0600https://answers.ros.org/question/247673/tf-fixed-transforms/?comment=247811#post-id-247811Comment by Venkat Ganesh for <p>Hi Venkat,</p>
<p>As you might be aware, a rotation can be expressed in several different representations. RPY is often used as it is fairly easy to visualize and recognize what the rotation is, but it has some problems with regards to singularities. Under the hood, TF uses quaterions, which means that if you are broadcasting and listening to a transform in euler angles like RPY, it will have to translated <em>to</em> and <em>from</em> quaternions. A single rotation can be expressed in several different set of RPY angles, for instance, a Pitch of 180 degrees is identical to first a roll of 180 degrees and then a yaw of 180 degrees (Like your <code>camera_frame --> bundler_camera_frame</code>) For your <code>base_link --> camera_frame</code>, it also works out.</p>
<p>An easy way to check that the transforms are what you intend for them is to use the TF plugin in RVIZ. If they are not what you intended, there is another problem, but I suspect this was the root cause.</p>
https://answers.ros.org/question/247673/tf-fixed-transforms/?comment=247812#post-id-247812Please view [this link](http://answers.ros.org/question/247808/tf-api-axesorder-of-rotation/) to get a better idea of my API usage.Thu, 10 Nov 2016 17:12:19 -0600https://answers.ros.org/question/247673/tf-fixed-transforms/?comment=247812#post-id-247812