Different cmd_vel msgs to multiple robots on Gazebo

edit

similar to the previous answers, here is probably a very round-about example for you. First off, in gazebo controller manager plugin implementation, each controller plugin starts a rosnode with a custom robot namespace, i.e.:

this->rosnode_ = new ros::NodeHandle(this->robotNamespace);

So each robot has its own plugin with a uniquely namespaced rosnode.

To assign namespaces, I left the option to assign robot namespace as a model XML parameter to be parsed by the plugin, or optionally insert the parameter at time of spawning the robot (e.g. spawn_model -namespace xxx .... This should be done along with starting all the non-simulation controller nodes in grouped namespace as mentioned in other answers. As an overall example, please see this launch file.

Any suggestions to make this process cleaner and more scalable are welcome. Thanks!

Hi,

I can not spawn two turtlebots. I have looked through this post and others ([http://answers.ros.org/question/33981/multiple-turtlebots-in-gazebo/?answer=41388#post-id-41388]) but I can not see neither /odom nor /cmd_vel in different name spaces. Here follows one configuration file for one robot.

Thank you for the attention,

    <launch>

  <param name="robot1/robot_description" command="$(find xacro)/xacro.py '$(find turtlebot_description)/urdf/turtlebot.urdf.xacro'"/>

  <node name="spawn_turtlebot_model" pkg="gazebo" type="spawn_model" args="$(optenv ROBOT_INITIAL_POSE) -unpause -urdf -param robot_description -x 9 -y 5 -z 0.05 -model turtlebot1 -robot_namespace robot1" respawn="false" output="screen" ns="robot1"/>

  <node pkg="diagnostic_aggregator" type="aggregator_node" name="diagnostic_aggregator" ns="robot1" >
    <rosparam command="load" file="$(find turtlebot_bringup)/config/diagnostics.yaml" />
  </node>

  <node pkg="robot_state_publisher" type="state_publisher" name="robot_state_publisher" output="screen" ns="robot1">
    <param name="publish_frequency" type="double" value="20.0" />
  </node>


  <!-- The odometry estimator -->

  <node ns="robot1" pkg="robot_pose_ekf" type="robot_pose_ekf" name="robot_pose_ekf1" >
    <param name="freq" value="30.0"/>
    <param name="sensor_timeout" value="1.0"/>
    <param name="publish_tf" value="true"/>
    <param name="odom_used" value="true"/>
    <param name="imu_used" value="false"/>
    <param name="vo_used" value="false"/>
    <param name="output_frame" value="odom"/>
    <param name="output_frame" value="odom" />
  </node>


  <!-- throttling -->
  <node pkg="nodelet" type="nodelet" name="pointcloud_throttle" args="load pointcloud_to_laserscan/CloudThrottle openni_manager" respawn="true" ns="robot1">
    <param name="max_rate" value="20.0"/>
    <remap from="cloud_in" to="/camera/depth/points"/>
    <remap from="cloud_out" to="cloud_throttled"/>
  </node>

  <!-- Fake Laser -->
  <node pkg="nodelet" type="nodelet" name="kinect_laser" args="load pointcloud_to_laserscan/CloudToScan openni_manager" respawn="true" ns="robot1">
    <param name="output_frame_id" value="/camera_depth_frame"/>
    <!-- heights are in the (optical?) frame of the kinect -->
    <param name="min_height" value="-0.15"/>
    <param name="max_height" value="0.15"/>
    <remap from="cloud" to="/cloud_throttled"/>
  </node>

  <!-- Fake Laser (narrow one, for localization -->
  <node pkg="nodelet" type="nodelet" name="kinect_laser_narrow" args="load pointcloud_to_laserscan/CloudToScan openni_manager" respawn="true" ns="robot1">
    <param name="output_frame_id" value="/camera_depth_frame"/>
    <!-- heights are in the (optical?) frame of the kinect -->
    <param name="min_height" value="-0.025"/>
    <param name="max_height" value="0.025"/>
    <remap from="cloud" to="/cloud_throttled"/>
    <remap from="scan" to="/narrow_scan"/>
  </node>


</launch>

You probably should run each simulated robot in its own namespace.

I know this is an old question, but if you struggle with this, just I did, maybe you need to comment the topics "commandTopic" and "odometryTopic" on your gazebo file. This way the group namespace will be valid, at least, this was the way I solved this problem on kinetic