Multimaster gazebo_ros_control plugin causes excessive slowdown

asked 2016-09-14 20:33:22 -0500

JLiviero gravatar image

updated 2016-09-14 20:58:00 -0500

I am attempting to run a robot simulation in a multimaster context. Gazebo runs on one master, the robot's navigation and control processes run on another.

The gazebo_ros_control plugin runs on the Gazebo master. It is set up in the robot's .xacro file like so:

  <gazebo>
    <plugin name="gazebo_ros_control" filename="libgazebo_ros_control.so">
      <robotNamespace>$(arg robot_namespace)</robotNamespace>
      <robotParam>robot_description</robotParam>
    </plugin>
  </gazebo>

If I comment out that plugin, Gazebo runs at a reasonable rate. Note that the launch file to spawn the robot is included from within a <group ns="$(arg robot_namespace"> tag. gazebo_ros_pkgs is built from source, kinetic-devel branch

Possibly of note: to prevent a consistent Gazebo crash which occurred every time the controllers were spawned ("[/gazebo]: Could not find parameter robot_description on parameter server"), there is both a robot_description and a robot_name/robot_description param on the Gazebo master parameter server. However, the slowdown is encountered with or without this unfortunate hack.

On the robot master, we have a controller manager spawner node, launched like so:

  <rosparam command="load" file="$(find rzr_control)/config/rzr_control.yaml" />

  <node name="base_controller_spawner" pkg="controller_manager" type="spawner"
    args="rzr_joint_publisher rzr_lift_controller rzr_velocity_controller
          --shutdown-timeout 1
          --timeout 300
          --namespace /sim/$(arg robot_name)"/>

(a 300 second timeout may seem excessive, but is required because Gazebo is running so slowly. It takes a very long time to actually advertise the mutlimaster-relayed topics)

The launch file by which base_controller_spawner is spun up is included with a ns=$(arg robot_namespace) argument in the <include> tag, but otherwise without a namespace.

gz stats output the following with the current configuration:

administrator@vm-jliviero-trusty-ws:~/ws$ gz stats
Factor[0.00] SimTime[1.70] RealTime[253.26] Paused[F]
Factor[0.00] SimTime[1.71] RealTime[256.12] Paused[F]
Factor[0.00] SimTime[1.72] RealTime[259.05] Paused[F]
Factor[0.00] SimTime[1.73] RealTime[261.86] Paused[F]
...etc

In a single-master context, Gazebo works as expected - there is no significant slowdown of the real-time factor.

We are using Gazebo 7 and ROS Indigo.

Is there anything obvious or missing that would cause Gazebo to drag in this way?

edit retag flag offensive close merge delete