Home | Tutorials | Wiki | Issues
Ask Your Question
0

Best practice for exposing an existing URDF model as a Gazebo 1.4 model

asked 2013-03-06 08:35:39 -0600

Adolfo Rodríguez T gravatar image

I can successfully load an existing URDF robot model into Gazebo 1.4. What I want to achieve now is a file/folder setup that plays as nicely as possible with Gazebo and my existing robot description ROS package. My current solution is to

  1. Leave existing robot description ROS package as-is, ie. Gazebo-agnostic (actual package).
  2. Create a model database in a simulation-specific folder added to the GAZEBO_MODEL_PATH.

The model database in 2. needs of course access to an up-to-date URDF model, and its mesh/image resources which do not live here, but in 1. I'm currently using cmake custom commands/targets to run xacro and expose resources through a symlink (code snippet at the end of the post). This works well.

My question is whether someone has come up with a simpler/more elegant solution to this problem.

Just for the record, I'm not adding the Gazebo model database directly in the existing robot description ROS package not only to prevent unwanted dependency couplings, but also because this ROS package does not fully comply with the Gazebo database folder structure, so Gazebo rightfully complains of unexpected contents when loading it.

TIA,

CMake code snippet:

rosbuild_find_ros_package(xacro)
rosbuild_find_ros_package(reem_description)

# Generate an up-to-date URDF robot description using xacro
set(INPUT_XACRO_FILE ${reem_description_PACKAGE_PATH}/robots/reem.urdf.xacro)
set(OUTPUT_URDF_FILE ${CMAKE_CURRENT_SOURCE_DIR}/models/reem_description/model.urdf)

add_custom_command(OUTPUT ${OUTPUT_URDF_FILE}
                   COMMAND ${xacro_PACKAGE_PATH}/xacro.py ${INPUT_XACRO_FILE} -o ${OUTPUT_URDF_FILE})

add_custom_target(generate_urdf ALL DEPENDS ${OUTPUT_URDF_FILE})

# Create symlink to robot model resources (meshes, images)
set(INPUT_MESHES_DIR ${reem_description_PACKAGE_PATH}/meshes)
set(OUTPUT_MESHES_SYMLINK ${CMAKE_CURRENT_SOURCE_DIR}/models/reem_description/meshes)

add_custom_command(OUTPUT ${OUTPUT_MESHES_SYMLINK}
                   COMMAND ${CMAKE_COMMAND} -E create_symlink ${INPUT_MESHES_DIR} ${OUTPUT_MESHES_SYMLINK})

add_custom_target(generate_meshes_link ALL DEPENDS ${OUTPUT_MESHES_SYMLINK})
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2013-03-06 14:37:44 -0600

nkoenig gravatar image

I believe the core problem is that ROS expects to run inside the source of a package. This conflicts with other applications, such as Gazebo, that expect to be installed.

The solution that we use is to install a ROS package, where the installation puts ROS specific stuff in one location, and Gazebo specific stuff in another. Here's an example for the Atlas robot:

~/local/share/drcsim-2.0/ros/atlas_description : Contains URDF

~/local/share/drcsim-2.0/gazebo_models: Contains the Gazebo model database

We then set GAZEBO_MODEL_PATH to include ~/local/share/drcsim-2.0/gazebo_models/, and ROS_PACKAGE_PATH to include ~/local/share/drcsim-2.0/ros/atlas_description.

So basically, we install and use environment variables.

edit flag offensive delete link more

Comments

What I'm doing is very similar, thanks for confirming. As opposed to the Atlas model, my mesh/image resources live in the ROS model package and not in the Gazebo model database, so I need to expose them in the latter, hence the CMake-created symlink.

Adolfo Rodríguez T gravatar imageAdolfo Rodríguez T ( 2013-03-08 03:39:31 -0600 )edit
Login/Signup to Answer

Question Tools

Stats

Asked: 2013-03-06 08:35:39 -0600

Seen: 944 times

Last updated: Mar 06 '13