Gazebo | Ignition | Community
Ask Your Question

Felix's profile - activity

2015-07-03 17:56:26 -0500 received badge  Student (source)
2014-12-17 16:50:38 -0500 received badge  Famous Question (source)
2014-10-09 02:59:40 -0500 received badge  Famous Question (source)
2014-10-08 09:59:46 -0500 commented answer Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

I assume that your PR is on top of latest gazebo4 from source...I will test our model against your PR branch and check whether it behaves differently...hopefully better....I'll report the outcome here...

2014-10-08 09:41:43 -0500 commented answer Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

Early experiments with using effort_controllers were also not very satisfying but this may have been due to wrong models...

We will probably try it again with our latest models but use the (rather hidden) feature offered by DefaultRobotHWSim to set /gazebo_ros_control/pid_gains/ parameters in order to use VELOCITY_PID control_method

This way we could keep the velocity_controllers (HW-Interface) and generate effort commands under the hood of the gazebo_ros_control plugin...

2014-10-08 09:34:32 -0500 commented answer Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

The reason why we also need JointVelocityController is because we also would like to command the arm based on a given Cartesian twist that is then converted into joint velocities using (some kind of) inverse Jacobian...we still use JointPositionController and JointTrajectoryController in according other control modes.

And we wanted to play use the velocity_controllers (HW-Interface) to be 1:1 compatible with our hardware.

2014-10-07 17:52:58 -0500 received badge  Notable Question (source)
2014-10-06 04:29:42 -0500 answered a question Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

Hi there,

I think, I found a way to make my model behave as desired, i.e. execute the commanded velocities (without "dropping" when velocities 0.0 are sent to the joints).

However, I'm not sure whether I should be happy about this or disappointed:
I'm now using a fake inertia in all our links. Therefore, I defined the following xacro macro and use it in all our links without caring about actual mass and distribution of mass of the corresponding link of the real hardware:

  <xacro:macro name="default_inertial">
      <mass value="0.01" />
      <origin xyz="0 0 0" />
      <inertia ixx="0.001" ixy="0.0" ixz="0.0" iyy="0.001" iyz="0.0" izz="0.001" />

This macro corresponds to a box-shaped body of mass 0.01 kg and a size of about 0.8 x 0.8 x 0.8 m³ (x-y-z). With this macro, the arm now moves the joints with the velocities commanded by the controller.

What makes me disappointed about this, is the fact that we put tremendous efforts in assessing the correct inertia values for our (non-primitive) links by assigning mass properties to the CAD data. We also used data from the technical specs sheets of the real hardware for specifying other properties. Even playing around with all the other properties that can be set in the URDF like, damping, effort limits, soft-limits, mechanicalReduction of transmission as well as all the gazebo-/sdf- tags (see also this thread and this thread) did not improve the behaviour.

Thus, I would like to know whether Gazebo is able to correctly model non-primitive inertias? Like inertias of asymmetric links that have values != 0.0 for the entries ixy, ìxz and iyz, i.e. values beyond the diagonal of the inertia matrix?

Is there any robot out there that uses a (URDF or SDF) model that actually corresponds to its real hardware properties? That I could use as a template? That uses a VelocityJointInterface as well and works well in simulation?

What other options do I have to further investigate why our model (with real inertias) is not able to execute the commanded velocities?

Am I using wrong units?

2014-10-06 03:59:24 -0500 received badge  Popular Question (source)
2014-10-01 08:35:14 -0500 asked a question Strange behaviour of robot model when using Joint::SetVelocity (VelocityJointInterface)

Dear all,

the problem stated in the title of this question is a real blocker for us at the moment.

What we try to do:
Our setup is: Trusty, Indigo, gazebo2_2.2.3-1~trusty_amd64

We try to simulate two 7-DoF arms:
- Schunk lwa4d
- Schunk lwa4p
Models can be found here for lwa4d and here for lwa4p_extended

We try to control those robots using velocity_controllers/JointVelocityControllers which uses the VelocityJointInterface hardware interface (specified in transmission). Velocity commands will finally be sent from a higher level node. For testing we simply use a terminal publisher or rqt.

To reproduce the behaviour described below, there exist convenience "bringup"-packages containing all launch- and config files here.

Simply run either
roslaunch schunk_lwa4d lwa4d_sim_urdf.launch or
roslaunch schunk_lwa4p_extended lwa4p_extended_sim_urdf.launch respectively.

The problem we are having
It seems that (for some) joints, the velocity commands cannot be executed by the simulated robot. I.e. the current joint velocity (as published in /joint_states/velocity differs from the velocity command being send from the (forward command) controller velocity_controllers/JointVelocityController (on topic /arm_X_joint_velocity_controller/command).

The following videos visualize the current behaviour.
In video1 it can be seen that arm_2_joint of the Schunk lwa4p_extended already starts to drop/drift right from the beginning of the simulation, i.e. whon no velocity command has yet been send and thus goal velocity is 0.0 for all joints.
In video2 it can be seen that also commanding velocities != 0.0 are not executed correctly.
However in video3 it can be seen that velocity commands actually can be executed without dropping/drifting. (Beside the strange behaviour of arm_6_joint! As this is also of the same motor type as used in the lwa4p_extended, I assume that the behaviour of that arm_6_joint has similar reasons.)

What we already tried to fix it
Of course, I found the following related threads on this list:

  • In this thread and this thread it is suggested to check SetMaxForce. However, as I am using the gazebo_ros_control plugin with DefaultRobotHWSim hardware interface, the value passed to Joint::SetMaxForce is received from the effort limit in the URDF. We use values from the technical data sheets of our motors for our model but of course also tested (arbitrarily) higher values - without success.

  • In this thread the problem was caused by a wrong inertia tag in the URDF. However, in our models, we use inertias derived from CAD data. We also tried to use "simplified" approximations for the inertias using these macros - again: no success.

We also played around with the meshes used for our models in order to guarantee they don't collide thus causing unexpected forces to the joints - again: no success.

It's really frustrating, as I don't have any more ideas what could be causing this strange behaviour.
But as it seems to actually be possible to command joints by sending velocity commands with SetVelocity (see lwa4d arm_2_joint), it doesn't seem to be a general problem with Joint::SetVelocity.

Could it be that it ... (more)

2014-10-01 06:30:57 -0500 received badge  Notable Question (source)
2014-09-24 07:34:05 -0500 received badge  Popular Question (source)
2014-09-22 13:13:39 -0500 received badge  Famous Question (source)
2014-09-20 08:01:02 -0500 received badge  Notable Question (source)
2014-09-20 06:23:48 -0500 commented answer URDF to SDF conversion using gzsdf

Thank you, Nate, for the clarification!

General.6: As to "Using SDF tags in URDF (gazebo extension) directly?" see also this new thread (

Specific.4: Does it make a difference whether those tags are included in the converted SDF or not? I assume default values are used also if the tags are not set in the SDF file.

2014-09-20 06:22:18 -0500 asked a question Using SDF tags in URDF (gazebo extension) directly?

This questions is related to the previous thread: urdf-to-sdf-conversion [1].

Now, I'm reporting my observations when trying to use SDF tags from sdf1.4 in the URDF directly.

As mentioned in [1], it should be possible to use SDF within the gazebo tags referencing a link or joint within the URDF directly.

SDF tags for links

For setting most of the SDF tags relevant for links, URDF does not need the gazebo extensions, i.e. pose, ìnertial, visual and collision related tags are correctly set up using urdf-xml-link.

  1. gravity and self_collide
    It's the same result as mentioned in this issue

  2. kinematic
    It is converted to sdf. But seems to have no effect according to this thread

  3. velocity_decay
    The following can be used to set velocity_decay of a link.
    With this, it's possible to set different values for linear and angular (in contrast to using the gazebo tag dampingFactor).

    <gazebo reference="${name}_base_link">

SDF tags for joints

Similar to the above mentioned, tags that can correctly be set up using urdf-xml-joint are not considered here.

  1. damping and friction (dynamics)
    damping of an axis can only be set using the URDF tag dynmaics -> damping.
    All the following variants are not converted into the SDF file:

    <gazebo reference="${name}_1_joint">

    friction cannot be set from anywhere as it is currently (not yet) supported (see PullRequest)

  2. physics for ode (ode)
    Both following variants are not converted into the SDF file:

    <gazebo reference="${name}_1_joint">

Thus, it seems that using SDF tags directly within a URDF file is not supported - at least the way I tried to use them. In case I used them in the wrong way, please let me know! I'd be happy to test again then...

The only tags that are converted into the SDF file are gravity, self_collide (however, not considered due to issue), kinematic (however, see thread) and velocity_decay.

2014-09-20 03:24:48 -0500 received badge  Popular Question (source)
2014-09-19 04:15:17 -0500 received badge  Editor (source)
2014-09-19 04:14:22 -0500 asked a question URDF to SDF conversion using gzsdf

Dear all,

As I'm currently trying to tune the dynamic behaviour of my robot modelled in a urdf(.xacro) file, I investigated the various urdf and gazebo tags available in order to see their effect to the simulation respectively.

This thread mainly deals with the conversion from urdf to sdf format using the gzsdf tool. So this thread is probably the first of several threads.

In the following I state my observations and would kindly ask someone to confirm them...or give explanations otherwise ;-)

I use the following setup: Trusty, Indigo, gazebo2_2.2.3-1~trusty_amd64 The robot I'm trying to tune is the Schunk lwa4p_extended. URDFs can be found here URDFs and launch files.
Other related links: gazebo-urdf-tutorial and sdf1.4.

I will number the questions so that answers can be referenced accordingly.

General questions

  1. The SDF version used in my setup (trusty, indigo, gazebo2) is SDF1.4?
  2. Where is SDF1.5 used? With gazebo3? Or gazebo4?
  3. You can convert a urdf.xacro file to sdf uding the following commands

    rosrun xacro robotlwa4pextended.urdf.xacro > robotlwa4pextended.urdf
    gzsdf print robotlwa4pextended.urdf > robotlwa4pextended.sdf

  4. When spawning a robot in gazebo using gazebo_ros/spawn_model the same gzsdf is used to convert the parameter /robot_description to sdf format which is then used in gazebo?

  5. Within a urdf gazebo tag (referencing a link or joint), I can use all tags listed in the gazebo-urdf-tutorial? I.e.:

    • material, gravity, dampingFactor, maxVel, minDepth, mu1, mu2, fdir1, kp, kd, selfCollide, maxContacts, laserRetro for links
    • kp, kd, stopCfm, stopErp, provideFeedback, cfmDamping, fudgeFactor for joints
  6. Within a urdf gazebo tag (referencing a link or joint), I can also use sdf tags from sdf1.4 directly?

Tag specific questions

  1. gravity, selfCollide and self_collide (gazebo tag for links)
    Adding one of the tags above for a link, an additional tag is added to the resulting sdf file, i.e. there are then two gravity tags for the same link in the sdf file where the first is always set to true (1) and the second sdf tag holds the value set in the urdf. I assume that when gazebo parses the sdf file, it always finds the first tag using their value, thus always neglecting what has been set in the urdf.
  2. kp, kd, mu1, mu2, maxVel, minDepth, fdir1, maxContacts, laserRetro, dampingFactor (gazebo tag for links)
    All those tags seem to be converted to sdf correctly.
  3. damping and friction (urdf tag for joints)
    friction is currently ignored, i.e. it's value is not even converted into the sdf file?
  4. Empty gazebo tag referencing a joint

    <gazebo reference="${name}_1_joint">
    is converted into 
  5. stopCfm, stopErp (gazebo tag for joint)

    <gazebo reference="${name}_1_joint">
    is converted into 
  6. cfmDamping, implicitSpringDamper, cfm_damping, implicit_spring_damper (gazebo tag ...

2014-07-15 13:44:19 -0500 received badge  Famous Question (source)
2014-07-07 08:35:53 -0500 received badge  Notable Question (source)
2014-07-07 08:35:53 -0500 received badge  Popular Question (source)
2014-07-06 08:20:35 -0500 received badge  Organizer (source)
2014-07-06 08:17:15 -0500 asked a question Configure ROS effort_controllers/JointVelocityController for Gazebo


I am trying to set up effort_controllers/JointVelocityController's for our Care-O-bot in order to be able to send goal velocities to the simulated robot as we do with the real hardware. To begin with, I tried to set up the controllers for a 7DoF version of the Schunk LWA4p.

Unfortunately, I was not yet able to find a good configuration, i.e. PID values for the respective JointVelocityController, where the arm behaved well. It keeps dropping and is not able to execute the desired goal velocities.

On the ROS/Orocos Robot Control SIG mailinglist (!topic/ros-sig-robot-control/hk4vWCUAs5E), I posted my current experiences and the strategy that I was pursuing so far to find good PIDs.

I came across some observations that I could not explain while tuning the PIDs. Many of these seem directly to be related to the gazebo simulation itself.

Thus, I opened this questions as a pointer to the ROS Control SIG thread! Any comments are appreciated either here or there.


2013-07-10 16:18:47 -0500 received badge  Famous Question (source)
2013-05-24 13:34:23 -0500 received badge  Notable Question (source)
2013-05-22 05:36:09 -0500 received badge  Popular Question (source)
2013-05-21 03:51:50 -0500 asked a question How to convert *.urdf.xacro files to *.sdf for gazebo?

Dear all,

as with the latest gazebo version (1.7.12-s1367893033~precise) in groovy, it seems that our *.urdf.xacro files are finally not supported anymore.

I found out about the latest .sdf format (1.3) and already tried to update some of our files. I.e. I replaced

  <xacro:macro name="sick_s300_laser_gazebo_v0" params="name ros_topic update_rate min_angle max_angle">
    <gazebo reference="${name}_link">
      <sensor:ray name="${name}">

        <origin>0.0 0.0 0.0</origin>


        <controller:gazebo_ros_laser name="gazebo_ros_${name}_controller" plugin="">
          <interface:laser name="gazebo_ros_${name}_iface" />
      <material value="IPA/LightGrey" />


  <xacro:macro name="sick_s300_laser_gazebo_v0" params="name ros_topic update_rate min_angle max_angle">
    <gazebo reference="${name}_link">
    <sensor name="${name}" type="ray">

      <material value="IPA/LightGrey" />

for the urdf.xacro files for one of our sensors.

However, if I then spawn our robot, I get the following message from gazebo:

fxm@sony-fxm:/opt/ros/groovy/stacks/simulator_gazebo/gazebo_worlds/worlds$ roslaunch gazebo_worlds empty_world.launch 
... logging to /home/fxm/.ros/log/320cbf70-bca0-11e2-9ff7-00271039ca78/roslaunch-sony-fxm-20823.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.

started roslaunch server http://sony-fxm:55478/


 * /rosdistro
 * /rosversion
 * /use_sim_time

    gazebo (gazebo/gazebo)
    gazebo_gui (gazebo/gui)

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

setting /run_id to 320cbf70-bca0-11e2-9ff7-00271039ca78
process[rosout-1]: started with pid [20850]
started core service [/rosout]
process[gazebo-2]: started with pid [20864]
process[gazebo_gui-3]: started with pid [20876]
Gazebo multi-robot simulator, version 1.5.0
Copyright (C) 2013 Open Source Robotics Foundation.
Released under the Apache 2 License.

Gazebo multi-robot simulator, version 1.5.0
Copyright (C) 2013 Open Source Robotics Foundation.
Released under the Apache 2 License.

Warning [] Converting a deprecated SDF source[/opt/ros/groovy/stacks/simulator_gazebo/gazebo_worlds/worlds/].
Set SDF value
  Version[1.2] to Version[1.3]
  Please use the gzsdf tool to update your SDF files.
    $ gzsdf convert [sdf_file]
Msg Waiting for master[ INFO] [1368540701.989137839]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...

Msg Connected to gazebo master @
Msg Publicized address:
Msg Waiting for master
Msg Connected to gazebo master @
Msg Publicized address:
Error [Events.hh:141] Events::ConnectWorldUpdateStart is ...