# Revision history [back]

I think the "cleaner" answer is to launch the nodes within a separate namespace. You can specify a namespace for each node as shown here. Depending on how the node is set up, all "local" topics should then be published under this separate namespace.

<node pkg="skeleton_markers" name="skeleton_markers" type="skeleton_markers.py" ns="system1"/>


I think the issue you're seeing above is that when you run rostopic list on a running system, it shows both the published and subscribed topic names. My guess is that when you modify the published topic names as shown above, you forget to also remap the topic that a different node is subscribing to. If you run rostopic info on a particular topic name (as shown by rostopic list), it will list out exactly which nodes are publishing/subscribing to each topic. This may help you troubleshoot.

I have not used skeleton_markers before, but it's possible that you may need to also tell the nodes to publish the markers in different rviz namespaces. Note that these namespaces are distinct from normal ROS namespaces. RViz requires that all markers have unique names, as a combination of their id and namespace values. It looks like the skeleton_markers node supports this through the use of the ~ns parameter. You can specify this parameter in your launch file also:

<node pkg="skeleton_markers" name="skeleton_markers" type="skeleton_markers.py" ns="system1">
<param name="ns" value="skeleton1"/>
</node>


I think the "cleaner" answer is to launch the nodes within a separate namespace. You can specify a namespace for each node as shown here. Depending on how the node is set up, all "local" topics should then be published under this separate namespace.

<node pkg="skeleton_markers" name="skeleton_markers" type="skeleton_markers.py" ns="system1"/>


I think the issue you're seeing above is that when you run rostopic list on a running system, it shows both the published and subscribed topic names. My guess is that when you modify the published topic names as shown above, you forget to also remap the topic that a different node is subscribing to. If you run rostopic info on a particular topic name (as shown by rostopic list), it will list out exactly which nodes are publishing/subscribing to each topic. This may help you troubleshoot.

I have not used skeleton_markers before, but it's possible that you may need to also tell the nodes to publish the markers in different rviz namespaces. Note that these namespaces are distinct from normal ROS namespaces. RViz requires that all markers have unique names, as a combination of their id and namespace values. It looks like the skeleton_markers node supports this through the use of the ~ns parameter. You can specify this parameter in your launch file also:

<node pkg="skeleton_markers" name="skeleton_markers" type="skeleton_markers.py" ns="system1">
<param name="ns" value="skeleton1"/>
</node>


Edit:
According to your comments, it looks like the <include> file is pulling in additional topics in the root namespace, not your sub-namespaces. I suggest you read up on the roslaunch XML syntax.

When you review that documentation, you'll see that the <include> tag has an optional namespace parameter just like we used for the <node> tag: ns="system1". You can add this to the <include> tag to force it to publish its nodes in a sub-namespace as well.

At this point, though, there's a better way to set the namespace for multiple different roslaunch tags. Use the <group> tag. If you use this in combination with an <arg> tag, you can use the same launch file for both client machines and pass in the desired namespace on the command line when you call roslaunch:

<arg name="skel_ns"/>
<group ns="$(arg skel_ns)"> <include file="$(find skeleton_markers)/launch/skeleton.launch"/>
<node pkg="skeleton_markers" name="skeleton_markers" type="skeleton_markers.py" output="screen">
<rosparam file="$(find skeleton_markers)/params/marker_params.yaml" command="load"/> <param name="ns" value=$(arg skel_ns)"/>
</node>
</group>

roslaunch skel_client.launch skel_ns:="system1"


Good luck!