Revision history [back]

Now when i move the teleop key, i am publishing messages to bothe the turtlesim nodes. I do not want this but i guess by default it is so that the teleop node will publish the messages to all the turtlesim_nodes present.

No, that is not how this works. The teleop node publishes to the turtle1/command_velocity topic, to which all instances of turtlesim_node subscribe. That is why they all receive the same message.

1 . How can i have multiple turtlesim_node running but publish only to 1.

Technically, you can't, as publications are not "to" a certain node, but to a topic. Any node can subscribe to that topic, and publications are anonymous. You have no way to specify a recipient.

What you could do however, is use remapping to effectively 'rewire' a node to publish or subscribe to a different topic. You could use this to make one turtlesim_node subscribe to turtle1/command_velocity (the default) and the other to turtle2/command_velocity. Now if turtle_teleop publishes to turtle1/command_velocity, only the first turtlesim_node will receive the messages.

This effectively achieves what you are asking, but do please note the difference: you're still not sending messages "to" a specific turtlesim_node, you're just making sure that only one of them "tunes in" on the data stream sent out by turtle_teleop.

2 . Using rosservice, how can i clear the content of both the turtlesim nodes at the same time ? using rosservice call /clear clears the default node.

You can't.

In contrast to messages, service invocations are directed to one particular recipient, namely the service provider (or server). In this case most likely the last turtlesim_node that came up 'claims' the name clear and responds to calls to the service.

Remapping can help you here as well, but only to make sure the clear services are reachable for both (or all) instances.

3 . Is it possible to modify its code or there is some understanding problem from my side ?

From the above, it would seem there is no 'need' to modify the code, as remapping seems to solve issue 1, and issue 2 is not possible, even if you'd modify the source.

If you'd still like to take a look, see ros/ros_tutorials/turtlesim. Clone it into a Catkin workspace, build it and be sure to source the devel/setup.bash.

Now when i move the teleop key, i am publishing messages to bothe the turtlesim nodes. I do not want this but i guess by default it is so that the teleop node will publish the messages to all the turtlesim_nodes present.

No, that is not how this works. The teleop node publishes to the turtle1/command_velocity topic, topic (here), to which all instances of turtlesim_node subscribe. That is why they all receive the same message.

1 . How can i have multiple turtlesim_node running but publish only to 1.

Technically, you can't, as publications are not "to" a certain node, but to a topic. Any node can subscribe to that topic, and publications are anonymous. You have no way to specify a recipient.

What you could do however, is use remapping to effectively 'rewire' a node to publish or subscribe to a different topic. You could use this to make one turtlesim_node subscribe to turtle1/command_velocity (the default) and the other to turtle2/command_velocity. Now if turtle_teleop publishes to turtle1/command_velocity, only the first turtlesim_node will receive the messages.

This effectively achieves what you are asking, but do please note the difference: you're still not sending messages "to" a specific turtlesim_node, you're just making sure that only one of them "tunes in" on the data stream sent out by turtle_teleop.

2 . Using rosservice, how can i clear the content of both the turtlesim nodes at the same time ? using rosservice call /clear clears the default node.

You can't.

In contrast to messages, service invocations are directed to one particular recipient, namely the service provider (or server). In this case most likely the last turtlesim_node that came up 'claims' the name clear and responds to calls to the service.

Remapping can help you here as well, but only to make sure the clear services are reachable for both (or all) instances.

3 . Is it possible to modify its code or there is some understanding problem from my side ?

From the above, it would seem there is no 'need' to modify the code, as remapping seems to solve issue 1, and issue 2 is not possible, even if you'd modify the source.

If you'd still like to take a look, see ros/ros_tutorials/turtlesim. Clone it into a Catkin workspace, build it and be sure to source the devel/setup.bash.