search

ros / geometry

Packages for common geometric calculations including the ROS transform library, "tf". Also includes ROS bindings for "bullet" physics engine and "kdl" kinematics/dynamics package.
173 stars 274 forks source link

TF results are inconsistent in partial transformations in TF tree #128

Closed akifh closed 8 years ago

akifh commented 8 years ago

Hi there,

Today I came across with a strange problem. Maybe I'm confused but I could not figure it out.

I have a TF tree like this; frames_tf

The transformation between /robot1/base_footprint and /robot1/base_laser_link is only translation in x and z axes.

Shouldn't I get same result with /map -> /robot1/base_laser_link and /map -> /robot1/base_footprint + /robot1/base_footprint -> /robot1/base_laser_link ?

I expected it to be the same but I got different results if I did not miss anything.

/map -> /robot1/base_laser_link
[ INFO] [1473329639.843549539, 10063.431000000]: Map to Laser, X: 0.101805473884, Y: 0.557398219037
/map -> /robot1/base_footprint
[ INFO] [1473329639.843598957, 10063.431000000]: Map to Robot, X: 0.364210011456, Y: 0.564434361285
/robot1/base_footprint -> /robot1/base_laser_link
[ INFO] [1473329639.843633645, 10063.431000000]: Robot to Laser, X: 0.262500000000, Y: 0.000000000000

As we can see, even we do not have any offset in y axis and any rotations between robot and laser, map to robot and map to laser transformations result in different x and y values. I though it may be due to round off errors but the difference in Y is 0.007036142, which is too large to be such an error. I got similar results with tf_echo between these links.

Any idea on this? Did I miss a point?

tfoote commented 8 years ago

In general those numbers should be equivalent. Without the ability to reproduce your problem I can only guess at possible reasons, such as queries at different times across different parts of the tree. Note that you have three sources with different latest timestamps.

Please ask this on answers.ros.org with enough information how to reproduce your problem, both with data sources and your query logic. The underlying transform math is heavily unit tested and I doubt that this is an underlying bug.