Revision history [back]

You don't make it very explicit, but I believe you are referring to the way the Writing a tf broadcaster (Python) and Writing a tf listener (Python) tutorials are setup.

In those tutorials, the broadcaster example creates a Subscriber, and the listener example creates a Publisher.

However, the publisher and subscriber are in there for a different reason. There is no requirement for them to be there, nor are they needed for either broadcaster or listener to work.

In both tutorials the publisher and subscriber are created to do 'something useful'.

In the case of Writing a tf broadcaster the subscribers callback takes in geometry_msgs/Pose messages (on the /<name_of_your_turtlebot>/pose topic) and broadcasts them as TF frames.

In the case of Writing a tf listener a listener is created to -- at 10 Hz -- lookup the current relative poses of the two simulated turtles. The result of that lookup is then converted into a geometry_msgs/Twist and the publisher is used to publish the conversion result on the topic turtle2/cmd_vel.

The publisher and subscriber are thus not part of the TF infrastructure (in this example), but used to either publish the result attained by listening to TF or to drive a conversion process and then broadcast something to TF.

You don't make it very explicit, but I believe you are referring to the way the Writing a tf broadcaster (Python) and Writing a tf listener (Python) tutorials are setup.

In those tutorials, the broadcaster example creates a Subscriber, and the listener example creates a Publisher.

However, the publisher and subscriber are in there for a different reason. There is no requirement for them to be there, nor are they needed for either broadcaster or listener to work.

In both tutorials the publisher and subscriber are created to do 'something useful'.

In the case of Writing a tf broadcaster the subscribers callback takes in geometry_msgs/Poseturtlesim/Pose messages (on the /<name_of_your_turtlebot>/pose topic) and broadcasts them as TF frames.

In the case of Writing a tf listener a listener is created to -- at 10 Hz -- lookup the current relative poses of the two simulated turtles. The result of that lookup is then converted into a geometry_msgs/Twist and the publisher is used to publish the conversion result on the topic turtle2/cmd_vel.

The publisher and subscriber are thus not part of the TF infrastructure (in this example), but used to either publish the result attained by listening to TF or to drive a conversion process and then broadcast something to TF.

You don't make it very explicit, but I believe you are referring to the way the Writing a tf broadcaster (Python) and Writing a tf listener (Python) tutorials are setup.

In those tutorials, the broadcaster example creates a Subscriber, and the listener example creates a Publisher.

However, the publisher and subscriber are in there for a different reason. There is no requirement for them to be there, nor are they needed for either broadcaster or listener to work.

In both tutorials the publisher and subscriber are created to do 'something useful'.

In the case of Writing a tf broadcaster the subscribers callback takes in turtlesim/Pose messages (on the /<name_of_your_turtlebot>/pose topic) and broadcasts them as TF frames.

In the case of Writing a tf listener a listener is created to -- at 10 Hz -- lookup the current relative poses of the two simulated turtles. The result of that lookup is then converted into a geometry_msgs/Twist and the publisher is used to publish the conversion result on the topic turtle2/cmd_vel.

The publisher and subscriber are thus not part of the TF infrastructure (in this example), but used to either publish the result attained by listening to TF or to drive a conversion process and then broadcast something to TF.