ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Recommended ROS+Gazebo Project Structure

asked 2015-04-25 10:08:22 -0500

Cerin gravatar image

What's the recommended project structure for a basic ROS project that uses Gazebo for simulation? I'm reading through the ROS and Gazebo tutorials, as well as looking at some projects like Turtlebot, and I'm having trouble figuring out what the best practice is. In some ways, Turtlebot's project layout seems very complicated, even when compared to physically more complicated robots like the Nao, whose project layout is relatively more simple.

I'm trying create an initial project layout for a small quadruped robot that I plan to simulate in Gazebo. This tutorial recommends creating just two packages, MYROBOT_description and MYROBOT_gazebo in a single git repo. Is that all I need? Looking at Turtlebot, they've done something similar, but they've split MYROBOT_gazebo off into a turtlebot_simulator meta-package in a separate git repo. I understand the abstraction because it lets them plug in different simulator backends other than Gazebo, but I don't understand why they manage the source in a separate repo. What's the benefit of keeping the *_description and *_gazebo projects in separate repos?

Turtlebot also defines a few other packages, which I've seen replicated elsewhere, such as *_bringup, *_capabilities, and *_apps. Are these typically best practice to create for your robot?

edit retag flag offensive close merge delete


Hello cerin, I am trying to simulate a quadruped robot in gazebo but don't what to know is there any package available for performing the inverse kinematics and motion planning. Writing these on my own seems to take a lot of time

Hari Prasanth gravatar image Hari Prasanth  ( 2018-05-30 05:47:19 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2015-06-21 02:23:46 -0500

tfoote gravatar image

Keeping the _descriptoin and _gazebo repositories together can be easy for getting started. As packages get more mature and development cycles for the packages diverge it can be easier to host them in separate repositories.

_bringup and _apps is a very common pattern for convenience. _capabilities is specific to work with the capabilities library, and shouldn't be used without that integration.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2015-04-25 10:08:22 -0500

Seen: 1,150 times

Last updated: Jun 21 '15