Ask Your Question
5

Best Practice: URDF descriptions, real robots, gazebo plugins and dependencies

asked 2012-02-08 00:39:44 -0600

updated 2012-02-08 02:31:30 -0600

joq gravatar image

Most complex URDF models use quite a few gazebo plugins. This often means that a dependency to "gazebo_plugins" (or other plugins) exists in the manifest.xml, which in turn means the inclusion of gazebo itself as a dependency. On a real robot or any setup that never simulates the robot model, this is a quite needless and heavyweight dependency. Are there any best practices for working around this in a systematic fashion, so one has a basic URDF model without gazebo dependencies, as well as a simulation version with all gazebo controllers?

I have a few ideas involving two packages, using ENV tags in xacro files and so on, but that seems rather cumbersome to me.

/edit: So here's the scenario that motivated my question: I have a vehicle model in the hector_ugv_description package. This contains the basic urdf file. For this model, I want to pull the low poly hokuyo UTM-30LX urdf model from the hector_sensors_description package. I also want to use a sonar sensor from another package on the vehicle, which uses a custom plugin (that has to be built for the sensor to work in gazebo). So from what I gather, I have to make 6 packages:

Not depending on anything gazebo, for use on real robot (only urdf/xacro and containing gazebo tags):

  • hector_ugv_description
  • hector_sensors_description
  • hector_sonar_description

Depending on gazebo for use in simulation (so plugins are properly built when building with rosmake)

  • hector_ugv_gazebo (depends on needed plugins, hector_ugv_description, hector_sensors_gazebo and hector sonar_gazebo)

  • hector_sensors_gazebo (depends on needed plugins and hector_sensors_description)

  • hector_sonar_gazebo (depends on needed plugins and hector_sonar_description)

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted
4

answered 2012-02-08 00:55:52 -0600

DimitriProsser gravatar image

updated 2012-02-08 02:59:13 -0600

Perhaps I'm not interpreting your question correctly, but if you wanted to be able to load your urdf in a real-robot situation, you could use the line:

<param name="robot_description" command="$(find xacro)/xacro.py '$(find my_robot_description)/urdf/my_robot.urdf.xacro'" />

or something similar. What I've always seen done is that there are two main files: one urdf that describes only the solid bodies of the robot (named with the .urdf.xacro extension), and one with only the controller descriptions (named with the .gazebo.xacro extension). You then provide two separate wrapper urdf files to be included in your launch files.

<param name="robot_description" command="$(find xacro)/xacro.py '$(find my_robot_description)/urdf/robot_real_world.urdf.xacro'" />

or

<param name="robot_description" command="$(find xacro)/xacro.py '$(find my_robot_description)/urdf/robot_simulator.urdf.xacro'" />

The file "robot_real_world.urdf.xacro would look like this:

<robot name="robot"
       xmlns:xacro="http://www.ros.org/wiki/xacro"
       xmlns:xi="http://www.w3.org/2001/XInclude">
  <include filename="$(find my_robot_description)/urdf/body.urdf.xacro" />
</robot>

And the file "robot_simulator.urdf.xacro" would look like this:

<robot name="robot"
       xmlns:xacro="http://www.ros.org/wiki/xacro"
       xmlns:xi="http://www.w3.org/2001/XInclude">
  <include filename="$(find my_robot_description)/urdf/body.urdf.xacro" />
  <include filename="$(find my_robot_description)/urdf/body_controllers.gazebo.xacro" />
</robot>

If you have all of these urdf files in a separate package, your real world robot doesn't need to depend on gazebo at all. You can just reference these files by name, regardless of whether that package is built or not.

EDIT:

If you want to avoid large dependencies, you don't have to depend on "{}_description" packages. They don't get built, so there's no point in having them as a dependency. It will throw a run-time error if the package doesn't exist though. That's your only problem.

edit flag offensive delete link more

Comments

Hi, I did an edit with a example scenario. Thanks for the answer so far :) Stefan Kohlbrecher ( 2012-02-08 02:05:49 -0600 )edit
Ok makes sense, after looking at how it's done for pr2 and turtlebot I adapted our stuff to look similar. Thanks! Stefan Kohlbrecher ( 2012-02-08 23:02:57 -0600 )edit
2

answered 2012-02-09 04:14:59 -0600

hsu gravatar image

As an example of another possible way to setup, note that pr2_description by default exports the robot URDF as well as XML extensions for simulation plugins and mechanism controls. But pr2_description does not depend on any of the robot/simulation/mechanism packages.

In effect, we are not interpreting package/stack dependencies based on XML dependencies (i.e. pr2_description export <gazebo> extensions but do not depend on gazebo. Similarly, pr2_description exports <transmission> extensions used by pr2_mechanism stack, but do not depend on it).

Therefore, for the PR2 there two main stacks, one for real-robot and the other for simulation:


Alternatively, if you want to keep the real-robot and simulation XML's separate, I imagine the following package structure/dependency might work too,:

  • mybot_description - contains XML for the robot only, without any simulation XML tags. Depends on XML parser/manipulation tools like xacro, ivcon, tinyxml, etc.
  • mybot_robot - depends on robot_description and anything else needed to bring up the robot in real world.
  • mybot_gazebo_description - depends on robot_description, and in addition includes gazebo XML tags (e.g. using <includes> and xacro as Dimitri suggested).
  • mybot_gazebo - depends on simulator, plugins and mybot_gazebo_description.
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

Follow
1 follower

Stats

Asked: 2012-02-08 00:39:44 -0600

Seen: 1,139 times

Last updated: Feb 09 '12