As we get ramped up on our own ROS environment, we've found the tf2 implementation extremely hard to understand. So this is a bit of a plea for folks who understand it well, to improve the tutorials, provide implementations of complete tf2 framework doing useful things, and a more up-front explanation of how it is implemented, why it is implemented that way and meant to work.
Let me say at the outset, this is meant to be wholly constructive. The amount of work that has gone into these packages and their documentation is extraordinary and we are wholly thankful for all of it. When we have a better understanding, we'll be in a better place to make contributions ourselves. But until then, we're asking for some help.
The concepts of reference frames in general, the REPs for ROS conventions, and the need for them is clear enough.
The rub is in exactly how one implements tf2 to provide utility in transforming a point, pose, vector, or arrays of any of these, between any two arbitrary reference frames quickly and seamlessly.
The basic tutorials here provide a nice gentle introduction to the mechanics. But I think the broadcaster example is confusing to first-time users in that it does not clearly introduce the tf2 library along the lines of the other turtle_sim tutorials. For example, rather than creating a transform from a pose message with little explanation as to why, it might be clearer, to set the problem up a bit first. Explain that turtle1 will be driven around using key-board commands and its location will be calculating using odometery and reported as a Pose message in the odom frame. Then, the broadcaster is implemented explicitly to define the transform between the odom and base_link frames.
The Listener is also confusing. The spawning of a new turtle simulation deserves some comment, as it is not done in most of the other tutorials. Also, the process does not explicitly define the reference frame for the position of turtle2. Given that this is a tf2 tutorial, doing so would make things more clear. Finally, although it is not part of the "listening", because this is somewhat of a contrived example, some discussion of why one is listening to the published transform and creating Twist messages from the result. Driving one turtle based on the pose of another through broadcast of a transform is just not a model that most, if anyone, would ever use, and for first timers it needs some comment.
Finally, what is perhaps most confusing and frustrating is that the tutorial doesn't actually provide an example of how to transform a Pose, Vector, Point or anything else having a reference frame into its equivalent in another reference frame. Since this is the whole point of the tf2 package it is a HUGE omission. Understanding how to do this, how to optimize it for large data sets, how to troubleshoot it - all important pieces.
There are some other things that are not explained well and leave us baffled include the following (I'll be showing my ignorance and total lack of understanding here):
It seems that tf2 is not doing the transforms itself at all, or maybe it is, but has the option of calling any of several back-end libraries (KDL, eigen linear algebra library, or the Bullet physics engine) to do the transform?. Clearly the various back-ends provide other functionality that is useful. What does one back-end do that another does not? Why would I want to chose one over another?
Why what it chosen not make one back-end the default and embed all the data conversion necessary to use it into wrapper functions allowing the ROS programmer to use native common_msgs (e.g. geometry_msgs/)? It is hard to understand why, having created a geometry_msgs/PoseStamped, upon which the rest of ROS common libraries depends, should one have to convert it to a tf2_geometry_msg/PoseStamped, or further into some other library's message type. All this data type conversion seems hugely inefficient and largely unnecessary unless you want to support all those other libraries (which most people probably don't need and can implement themselves if they do). Why was the choice made to completely redefine the geometry messages within tf2 rather than reusing the already defined ones and creating this incompatibility with the rest of ROS?
Thanks for listening. I hope this doesn't come across as a rant. And thanks again for all the fantastic work.
Originally posted by vschmidt on ROS Answers with karma: 242 on 2018-05-30
Post score: 3
Original comments
Comment by Nicolas on 2019-11-20:
I agree that the documentation needs work. People who started with tf can figure out most things, but I guess starting right away with tf2 is challenging. For the Python part, it would already help to have real auto-generated docs, e.g. on http://docs.ros.org/melodic/api/tf2_ros/html/python/tf2_ros.html .
Comment by gvdhoorn on 2019-11-20:
The infrastructure to generate the documentation would appear to all be there.
The quickest way to move this forward would be for more community contributions to add content.
Comment by bassline on 2021-10-19:
I also am learning tf2 (on Foxy) without having used tf and found the examples hard to follow, even when I had worked out the textual errors, sought guidance and then submitted fixes. I don't yet know enough to help, particularly as I am just an amateur doing this for fun.
