Skip to content

Creating robot models in Gazebo (beyond URDF files)

Jump to bottom
Catharine McGhan edited this page Feb 21, 2019 · 8 revisions

Table of Contents

Before you start...

Note that having URDF model files that work in rviz isn't enough to have a controllable model that "just works" in Gazebo -- you need to convert your base URDF files to add inertia, collision, and controllable property elements to the models, as well as gazebo tags; you may also need to create a specific .gazebo file, as well. (Sometimes .xacro files will make life easier.) See the tutorials below.

Most files used in Gazebo are automatically converted from URDF to SDF format. It's useful to write the files in URDF XML format rather than SDF XML format, though, because with URDF you can use ROS's xacro code macros to automatically stitch files together, add or pass parameters, etc.

From https://github.com/wilselby/ROS_quadrotor_simulator/blob/master/README.md ...note that this is the entire set of models from the Gazebo database (around 450MB) and that this is not a ROS package (these are "just" the sdf files, not the deprecated http://wiki.ros.org/gazebo_worlds)

Tutorials

  • URDF model tutorial for Gazebo: link
  • Contact sensor tutorial for Gazebo: link
  • Adding Physical and Collision Properties to a URDF Model tutorial: link
  • Friction tutorial for Gazebo: link

Cool things to know about Gazebo 7

  • As per this article, Gazebo 7+ has:
    • a graphical model editor that you can take advantage of (tutorial is here: link)
      • it also has a building editor, see: link)
    • simulation environment(s) for FIRST Robotics and Robocup 2016
    • an aerodynamics plugin (for an example with a Cessna C-172 model, see: link)

Model Starting Configuration

The starting position and joint states of a model can be specified in the scenario roslaunch file. Under the 'urdf_spawner' node, the position of the robot and the can be specified using a set of arguments.

Example: 

 <node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" respawn="false" output="screen"
   args="-urdf -model YOURMODELNAME -param MODELDESCRIPTIONPARAM
    -x XPOSITION
    -y YPOSITION
    -z ZPOSITION
    -R ROLLANGLE
    -P PITCHANGLE
    -Y YAWANGLE
    -J JOINTNAME JOINTANGLE
    -unpause
     />

When doing this it is important to start the simulation paused, through the "paused" argument earlier in the launch file. The '-unpause' argument in the model spawner will then unpause the simulation once it is launched.

An example of this method can be found here

ROS+gazebo model, normal issues

Gazebo 'Bumper' plugin not working

When Gazebo uses a URDF model, it will merge all links that are connected by 'fixed' type joints, combining their properties, such as collision geometry. This merged joint will have a new collision property name, which the bumper sensor is not set to find. To fix this, you will first need to find this new name, which is normally long and contains the phrase "fixed_joint_lump", and put it into the <collision></collision> tag inside of the bumper definition inside your URDF. See this ROS answer thread.

Issues with "exploding robots":

These are usually/generally caused by one or more of the following:

  • a too-large JointVelocityController derivative gain in the PID controller (fix by making it smaller)
  • PID values in general are too big (fix by making them smaller)
  • inertia values of the robot too small (fix by making them bigger)
It could also be problems with the setup of the &lt;collision&gt; tag (overlaps in collision objects between two or more joints, etc.), or the joint limits (e.g., you start a joint at a default joint angle that's outside the limits).

If fixing the above doesn't solve the issue...

  • it may be "typical numerical instability of the current constraint solver. The redundant contacts of the cylinder/box with the ground has made the system stiff enough that your solution [j]itters/fails to converge."
  • recommended solutions are:
    • "switch to single contact (e.g. use spheres, trimeshes, etc) or shorten the moment arm between the two contacts on the same [geometric] with the ground, [e.g.]... shorten your [geometric] so the length is say 0.05m instead of 0.145m, your simulation will be stable"
    • "reduce mass ratio between the base and the [e.g.] wheels... heavy objects sitting on top of light objects produces an ill conditioned system for ode formulation"
    • "lower &lt;stepTime&gt;, increase &lt;quickStepIters&gt; or decrease &lt;quickStepW&gt; ... [for] slower simulation" (see: link, link, and link)
    • "increase the [object's] inertia"
      • "A[n] inertia matrix [with] diagonal terms that [are] lower than mass / 1000.0 makes the item unstable (w/ ground at least). Using standard inertia matrix for cubes, cylinders or spheres works good enough." (see: link)
      • Steps to fix:
        • If there are any diagonal inertia values (ixx iyy izz) in the object that are less than 0.001, change them to 0.001 (or higher)
        • Back-calculate from the new/revised inertia matrix what the mass should be for the object
        • Update the mass for the object (but keep the center of mass the same)
      • See also: explanation of inertia matrix, and tutorial for computing the mass & center of mass & inertia matrix for a part from mesh files
References: link, link

Be careful with how you set up the inertias!

Note that the location of the link's coordinate system in the world vs. rest of the robot vs. single-link can potentially be clear as mud. See this link, and it is recommended that you bring up the model in Gazebo and turn on 'show coordinate systems'/links to get a better sense of what corresponds to what, has what "offsets", etc., when figuring this out. You'll need to know where each link's coordinate system is relative to that link/part in order to calculate out the inertias (Ixx, Iyy, Izz, etc.) properly from the mass/density of the link.

Clone this wiki locally