Gazebo | Ignition | Community
Ask Your Question

JLiviero's profile - activity

2017-06-28 05:27:59 -0500 edited answer Get Real Time Factor (RTF) Programmatically?

I had the same problem and went though basically the same attempted solutions. I eventually re-implemented the same alg

2017-06-28 05:23:38 -0500 commented answer Get Real Time Factor (RTF) Programmatically?

Ha, you're right @chapulina. I grabbed from my notes quickly and misremembered where in the source it cam from. Edited

2017-06-27 15:10:27 -0500 received badge  Nice Answer (source)
2017-06-27 14:52:39 -0500 received badge  Teacher (source)
2017-06-27 14:31:14 -0500 commented answer Is there a way to run Gazebo on an AWS server?

@levya, you could try running Xvfb ( on such a headless machine.

2017-06-27 14:26:09 -0500 answered a question Programmatically restart simulation with different object poses

Have you tried Model::SetWorldPose() (as opposed to SetLinkPose())? Seems like it would be more effective than setting

2017-06-27 14:22:49 -0500 commented answer Get Real Time Factor (RTF) Programmatically?

Not exactly. RTF is calculated over several passes. I actually tried what you suggest at one point, and it always prod

2017-06-27 14:21:01 -0500 answered a question Get Real Time Factor (RTF) Programmatically?

I had the same problem and went though basically the same attempted solutions. I eventually re-implemented the same alg

2017-05-07 21:42:51 -0500 received badge  Famous Question (source)
2017-04-28 12:45:11 -0500 received badge  Good Question (source)
2017-02-23 11:51:48 -0500 commented question Gazebo crashes on model deletion

Output has been posted below - let me know if you need anything else.

2017-02-13 14:19:41 -0500 answered a question Gazebo crashes on model deletion

Responding to @chapulina 's request here so I can attach the file. The full backtrace is attached. The model that caused this particular crash was a simple static cylinder primitive with a blink_visual plugin (but no custom plugins), though I have seen similar (not backtraced) crashes occur on a variety of models.

The attachment is just a text file, but has a .msg extension since this board only allows certain file types.


2017-02-13 13:36:50 -0500 received badge  Notable Question (source)
2017-02-08 13:03:59 -0500 received badge  Popular Question (source)
2017-01-26 08:27:13 -0500 commented answer How to change Gazebo client framerate?

@nkoenig, even if FPS doesn't affect real-time factor, it would be good to control the frame rate to reduce overall CPU load. Is this something that is already implemented?

2017-01-24 12:13:03 -0500 answered a question Decreasing trolley drift (cart: front steering)

What do your inertias for the trolley look like?

2017-01-24 10:05:36 -0500 commented question Gazebo crashes on model deletion

Wilco. Is there a method for getting debug symbols *without* building Gazebo from source? Just setting `debug=true` indicates: `Reading symbols from gzserver...(no debugging symbols found)...done.`

2017-01-23 12:16:27 -0500 asked a question Gazebo crashes on model deletion

I am attempting to delete (and subsequently re-spawn, with a different 3D mesh) a static model in Gazebo. When I do, Gazebo is crashing consistently.

Here is an excerpt from the gazebo log:

gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Inertial; typename boost::detail::sp_member_access<T>::type = gazebo::physics::Inertial*]: Assertion `px != 0' failed.

(truncated some plugin output here, which looks sane)

Aborted (core dumped)
================================================================================REQUIRED process [gazebo-2] has died!
process has died [pid 23768, exit code 134, cmd /opt/simulation/lib/gazebo_ros/gzserver -u -r -e ode /var/tmp/ros/ __name:=gazebo __log:=/home/administrator/.ros/log/eb76bd24-e192-11e6-a6dd-005056b4a883/gazebo-2.log].
log file: /home/administrator/.ros/log/eb76bd24-e192-11e6-a6dd-005056b4a883/gazebo-2*.log
Initiating shutdown!

I'm calling the delete service from Python, as follows:

self._delete_env_cli = rospy.ServiceProxy('/gazebo/delete_model', DeleteModel)
        resp = self._delete_env_cli(model_name='barrier')
except rospy.ServiceException as e:
        rospy.logerr("Service did not process request: {}".format(e))

I see this behaviour with or without rospy.wait_for_service().

Gazebo 7.5.0, ROS Indigo. I'm also running GzWeb (head of gzweb_1.3.0) which is connected to this instance - not sure if that would impact anything.

2016-12-22 13:37:40 -0500 received badge  Notable Question (source)
2016-10-31 13:26:53 -0500 received badge  Scholar (source)
2016-10-31 13:26:43 -0500 received badge  Supporter (source)
2016-10-31 13:26:14 -0500 answered a question Running a Camera Sensor Headless

Thanks guys. I've got a solution, which I'll post here for the benefit of anyone else who comes searching for such a thing later.

Because our VMs aren't running NVidia drivers as a rule, I wanted to explore some other options before attempting Jose's solution. Based on Nate and Jose's comments, I went digging into virtual xservers and found this old comment, which led me to Xvfb. With Xvfb, I was able to do the following:

$ Xvfb :1 -screen 0 1600x1200x16  &
$ export DISPLAY=:1.0
$ roslaunch etc etc.launch

...which let me run the camera plugin headlessly on a VM with no problems. Here's a screen grab from the camera, taken remotely by connecting RQT to the robot on the VM:

image description

(This timely Gazebo fix was also helpful.)

Thanks again!

2016-10-24 16:52:16 -0500 commented answer Running a Camera Sensor Headless

As I noted in the question, we already have a camera plugin that runs just fine on a display-enabled machine. Our robot is defined in a URDF and launched using roslaunch. I should have been more clear, sorry - I've updated my original question accordingly.

2016-10-24 16:49:54 -0500 received badge  Critic (source)
2016-10-24 16:49:02 -0500 received badge  Famous Question (source)
2016-10-21 02:25:30 -0500 received badge  Notable Question (source)
2016-10-20 08:19:08 -0500 received badge  Popular Question (source)
2016-10-19 08:02:48 -0500 asked a question Running a Camera Sensor Headless


We are looking to run a camera sensor headless on a VM, however when we do so several of the camera's image topic (notably, camera/image_raw) are not published. At ROSCon, I spoke briefly with Jose, who indicated that this could be done fairly painlessly, and is actually used for Gazebo's CI tests. How would I go about enabling that capability?

To clarify, we already have a camera plugin that runs just fine on a display-enabled machine. Our robot is defined in a URDF and launched using roslaunch. However, note that the "headless" option exposed by gazebo_ros_pkgsdoesn't actually work - see

I also don't see an explicit "headless" option list in the Gazebo code. The Gazebo devs did mention that such a mode was possible, I just can't figure out how.

(Running Gazebo 7 and ROS Indigo)

2016-09-30 08:55:31 -0500 received badge  Popular Question (source)
2016-09-15 07:03:39 -0500 received badge  Enthusiast
2016-09-14 20:58:00 -0500 received badge  Editor (source)
2016-09-14 20:51:12 -0500 answered a question Changing physics engine through URDF

You can specify your physics engine in empty_world.launch:

You can do this by adding <arg name="physics" value="your_preferred_physics_engine" /> in Inverted_pendulum_world.launch, like so:

  <!-- We resume the logic in empty_world.launch -->
  <include file="$(find gazebo_ros)/launch/empty_world.launch">
    <arg name="physics" value="your_preferred_physics_engine" />  <!-- this line added -->
    <arg name="debug" value="$(arg debug)" />
    <arg name="gui" value="$(arg gui)" />
    <arg name="paused" value="$(arg paused)"/>
    <arg name="use_sim_time" value="$(arg use_sim_time)"/>
    <arg name="headless" value="$(arg headless)"/>

If that isn't sufficient, or you need to do more detailed tailoring of the physics, you could make a copy of (in which physics properties are specified), and pass that into empty_world.launch instead.

2016-09-14 20:33:22 -0500 asked a question 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:

    <plugin name="gazebo_ros_control" filename="">
      <robotNamespace>$(arg robot_namespace)</robotNamespace>

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]

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?

2016-08-19 06:18:50 -0500 received badge  Famous Question (source)
2016-08-16 21:53:12 -0500 commented answer Simulating Actuated Joint Stiffness

As Mike mentioned, the actual joint is a screw, but we're using a prismatic joint as a stand-in. Joint friction was something I attempted also. However, I have friction set to an unrealistically high value, and we are still getting backdrive. Also, the "effort" value and p term of the PID need to be set correspondingly high so that the lift can still move, which means that the lift has a hilarious-but-unfortunate tendency to fling its payload across the map when compensating for the backdrive.

2016-08-16 20:14:39 -0500 received badge  Notable Question (source)
2016-08-16 19:26:17 -0500 received badge  Popular Question (source)
2016-08-16 18:46:04 -0500 received badge  Nice Question (source)
2016-08-15 14:02:07 -0500 received badge  Organizer (source)
2016-08-15 12:04:22 -0500 received badge  Student (source)
2016-08-15 11:46:18 -0500 asked a question Simulating Actuated Joint Stiffness


I am trying to simulate a joint which actuates a lift using Gazebo 7 and ROS Indigo. The URDF definition for the joint is as follows:

<joint name="lift_joint" type="prismatic">
  <origin xyz="0 0 0.177" rpy="1.5707963267949 0 0" />
  <parent link="chassis_link" />
  <child link="lift_link" />
  <axis xyz="0 1 0" />
  <limit lower="0" upper="0.08" effort="20000.0" velocity="0.02" />
  <dynamics damping="100.0" />

The lift is driven by a position controller with these parameters:

      left_wheel_joint: { p: 1.0, i: 0.0, d: 0.0 }
      right_wheel_joint: { p: 1.0, i: 0.0, d: 0.0 }
      lift_joint: { p: 100000.0, i: 1000.0, i_clamp: 1000, d: 1000.0 }

The problem is that the lift can be easily depressed by another object. Say the lift is given a command to raise. It does so, but when it comes into contact with the object it is meant to actually lift, it "bounces" back do to a lower position. It will then continually attempt to reach the commanded position, and continually get bounced back down before it can do so.

Is there a way to specify a stiffness for the joint, so that it only moves when commanded to move?