Robotics StackExchange | Archived questions

Multimaster gazebo_ros_control plugin causes excessive slowdown

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 robotdescription on parameter server"), there is both a `robotdescriptionand arobotname/robotdescription` 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 basecontrollerspawner is spun up is included with a ns=$(arg robot_namespace) argument in the 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?

Asked by JLiviero on 2016-09-14 20:33:22 UTC

Comments

Answers