Rosanswers logo

ROS Kinetic
Gazebo 7.0
RedHat Linux

I'm running into an issue with a roslaunch file that attempts to start a Gazebo node within a group tag that has the namespace parameter set. The Gazebo node appears to start, but other nodes that wait on gazebo services hang. Specifically, when using rospy, the following calls do not complete.


The launch file is as follows:


<!-- ********************* Begin Gazebo Defaults ******************************** -->

<!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="paused" default="true"/>
  <arg name="use_sim_time" default="true"/>
  <arg name="gui" default="false"/>
  <arg name="headless" default="true"/>
  <arg name="debug" default="false"/>

  <!-- these are the arguments you can pass this launch file, for example paused:=true -->
  <arg name="extra_gazebo_args" default=""/>
  <arg name="physics" default="ode"/>
  <arg name="verbose" default="true"/>
  <arg name="world_name" value="$(find basicbot_gazebo)/worlds/basicbot.world"/>
  <arg name="respawn_gazebo" default="false"/>
  <arg name="use_clock_frequency" default="false"/>
  <arg name="pub_clock_frequency" default="100"/>
  <!-- set use_sim_time flag -->
  <group if="$(arg use_sim_time)">
    <param name="/use_sim_time" value="true" />
  <!-- set command arguments -->
  <arg unless="$(arg paused)" name="command_arg1" value=""/>
  <arg     if="$(arg paused)" name="command_arg1" value="-u"/>
  <arg unless="$(arg headless)" name="command_arg2" value=""/>
  <arg     if="$(arg headless)" name="command_arg2" value="-r"/>
  <arg unless="$(arg verbose)" name="command_arg3" value=""/>
  <arg     if="$(arg verbose)" name="command_arg3" value="--verbose"/>
  <arg unless="$(arg debug)" name="script_type" value="gzserver"/>
  <arg     if="$(arg debug)" name="script_type" value="debug"/>

  <group if="$(arg use_clock_frequency)">
    <param name="gazebo/pub_clock_frequency" value="$(arg pub_clock_frequency)" />

<!-- ********************* End Gazebo Defaults ******************************** -->    

<!-- <group ns="basicbot_ga_1"> -->
<group ns="ga1">
  <!-- start gazebo server-->
  <env name="GAZEBO_MASTER_URI" value="http://localhost:11345"/>
  <node name="gazebo" pkg="gazebo_ros" type="$(arg script_type)" respawn="$(arg respawn_gazebo)" 
    output="screen" args="$(arg command_arg1) $(arg command_arg2) $(arg command_arg3) -e $(arg physics) 
    $(arg extra_gazebo_args) $(arg world_name)">

  <!-- Load the transporter node -->
  <node name="basicbot_transporter" pkg="basicbot_ga" type="basicbot_transporter.py" output="screen"></node>

    <!-- Load the turn_drive_scan node -->
    <node name="turn_drive_scan" pkg="basicbot_ga" type="turn_drive_scan_node.py" output="screen"></node>

    <!-- Load the step world node -->
  <node name="step_world" pkg="world_step" type="step_world_server"/>

  <!-- Load the URDF into the ROS Parameter Server -->
  <param name="robot_description"
    command="$(find xacro)/xacro '$(find basicbot_description)/urdf/basicbot.xacro'" />

  <!-- Run a python script to the send a service call to gazebo_ros to spawn a URDF robot -->
  <node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description"/>


I've tried the following while troubleshooting the problem.

  1. Remove group tag completely. Behavior: Simulation runs fine, nodes initialize and execute after the initial spool up.
  2. Add group tag without ns attribute. Behavior: Simulation again runs fine.
  3. Add ns attribute. Behavior: Gazebo node appears to launch, but the previously mentioned services do not appear to be available to other nodes inside the group tag. rostopic list and gz topic -l do not show the topics being published either.

As far as I can tell, adding the ns attribute breaks communication/publication of the topics somewhere in the pipeline, but I have not been able to isolate it yet. Does anyone have any experience with this issue, or thoughts on how to proceed? I am reasonably sure that I need the namespace attribute as it will allow me to run multiple gazebo simulations in parallel. Perhaps there is an alternative that I have missed?

Thank you in advance!

Edit 1 I added the namespace tags as suggested by F.Brosseau, however, I'm still running into the same issue. Output from my launch is as follows:

roslaunch basicbot_ga basicbot_ga.launch
... logging to /user/moore112/.ros/log/2095c3d2-5a3f-11e6-ada1-d4ae52e9ffc7/roslaunch-robo10-64979.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

xacro: Traditional processing is deprecated. Switch to --inorder processing!
To check for compatibility of your document, use option --check-order.
For more infos, see http://wiki.ros.org/xacro#Processing_Order
started roslaunch server http://robo10:33181/


 * /ga1/robot_description: <?xml version="1....
 * /rosdistro: kinetic
 * /rosversion: 1.12.2
 * /use_sim_time: True

    basicbot_transporter (basicbot_ga/basicbot_transporter.py)
    gazebo (gazebo_ros/gzserver)
    step_world (world_step/step_world_server)
    turn_drive_scan (basicbot_ga/turn_drive_scan_node.py)
    urdf_spawner (gazebo_ros/spawn_model)

auto-starting new master
process[master]: started with pid [65002]

setting /run_id to 2095c3d2-5a3f-11e6-ada1-d4ae52e9ffc7
process[rosout-1]: started with pid [65015]
started core service [/rosout]
process[ga1/gazebo-2]: started with pid [65022]
process[ga1/basicbot_transporter-3]: started with pid [65046]
process[ga1/turn_drive_scan-4]: started with pid [65047]
process[ga1/step_world-5]: started with pid [65050]
process[ga1/urdf_spawner-6]: started with pid [65054]
Gazebo multi-robot simulator, version 7.0.0
Copyright (C) 2012-2016 Open Source Robotics Foundation.
Released under the Apache 2 License.

spawn_model script started
[ INFO] [1470313789.450543774]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1470313789.451556715]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[Msg] Waiting for master.
[Msg] Connected to gazebo master @
[Msg] Publicized address:
[Err] [RenderEngine.cc:699] Can't open display:
[Wrn] [RenderEngine.cc:97] Unable to create X window. Rendering will be disabled
[Wrn] [RenderEngine.cc:301] Cannot initialize render engine since render path type is NONE. Ignore this warning ifrendering has been turned off on purpose.
[INFO] [WallTime: 1470313789.568306] [0.000000] Loading model xml from ros parameter
[INFO] [WallTime: 1470313789.574665] [0.000000] Waiting for service /gazebo/spawn_urdf_model

"SPINNING UP WAITS" is a print debug statement to let me know where the turn_drive_scan node is stopping. Still waiting on the gazebo services. It looks like the URDF is also not being translated into an actual gazebo robot as the service /gazebo/spawn_urdf_model does not appear to be coming up as well.

Originally posted by JaredMoore on ROS Answers with karma: 71 on 2016-08-03

Post score: 0


1 Answer 1


Rosanswers logo

I was able to solve this issue this morning. I did not end up needing the robotName or robotNamespace tags as suggested. Instead, my issue was due to the fact that gazebo was launching as /ga1/gazebo, forcing the services it offered to be changed from /gazebo/ to /ga1/gazebo/. The launch file was still however looking for /gazebo/, especially in the case of the urdf_spawn node. Accordingly, I changed

<node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description"/>


<node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
    args="-urdf -model basicbot -param robot_description -gazebo_namespace /ga1/gazebo"/>

by adding the -gazebo_namespace /ga1/gazebo attribute at the end of the call. Be sure also to make changes to any scripts that use rospy and wait_for_service or ServiceProxy as you will need to prepend the namespace to those as well by calling rospy.get_namespace().

Originally posted by JaredMoore with karma: 71 on 2016-08-04

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by JaredMoore on 2016-08-04:
Not enough points to accept this as an answer, but it is the fix.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.