Populating Gazebo Worlds
For the education challenge project to take shape, several components were needed to create a simulated world to play in:
- Gazebo Model Packages
- Gazebo Plugin Packages
- Gazebo World Files
- ROS Launch Files
- Additional Scripts
These files are organized into a Catkin workspace under the src directory. The main package contains the Gazebo world and ROS launch files with each model and plugin created as individual packages in the workspace. Additionally, for Gazebo to find the models created for the project, a setup.sh file needs to be sourced so that the project’s gazebo models are included in the GAZEBO_MODEL_PATH environment variable.
The Gazebo Model Package
This consists of the following files:
- model.sdf – describes all the elements needed to create a model or world from the visual aspect to physics.
- model.config – contains information about the model and the SDF version and sdf file associated to the model.
- CMakeLists.txt – CMake input file used to describe how to build and where to install the package files.
- package.xml – describes the package itself. It also contains the a list of other packages needed to build the current one.
The Gazebo Plugin Package
A Gazebo plugin is associated with a Gazebo Model or World and are used to manipulate or interact with components of the model or world. More than one plugin can be associated with a model but is not a requirement when creating a model. Similar to the Model Package, a Plugin Package has four main ingredients.
- src/plugin_code_file.cc – contains code, typically c++ code.
- include/plugin_header_file.hh – contains the header for the plugin_code_file.cc
- CmakeLists.txt – required for building and installing the package
- package.xml – describes what the package is and what additional packages are needed for it to work
Additionally, if the plugin publishes messages a msg/message_topic.msg file is needed. The *.msg file contains the datatype and names of the messages to be published.
Plugins are categorized as a World, Model, Sensor, System, and Visual Plugin. Each type of plugin should be declared between the corresponding tags in a Model/World’s SDF file.
# Example of a Visual Plugin declaration in a model.sdf file <sdf version = '1.4'> <model name = "example_model"> # additional code here <link name = "example_link"> # additional code here <visual name = "box_visual"> #additional code here # Declaring an example visual plugin. # The *.so file is generated when the plugin is properly built <plugin name="example_visual_plugin" filename="libExampleVisualPlugin.so" /> </visual> </link> </model> </sdf>
Gazebo World and ROS Launch Files
A Gazebo World file and ROS Launch Files are components of the main package. A World file is describes the contents of the simulation world and the location of each component (using the SDF format) while a Launch file opens/calls on Gazebo to open the world files. Since they are contained in a Catkin package, the CMakeLists.txt and package.xml files are a must.
A setup.sh file contains the list of Gazebo models that the project needs.
# Add to the setup.sh file to find new models export GAZEBO_MODEL_PATH=`rospack find <place_model_name_here>`:$GAZEBO_MODEL_PATH
For the project to work with CloudSim and gzweb, models need to be webified and bash environments sourced. In the webification step, the deploy script must be run from the gzweb 1.0.0 folder.
# to perform model webification . /gzweb-1.0.0/deploy.sh -m local
- This setup has been tested on Ubuntu 12.04, ROS Hydro (and Groovy), Gazebo 1.9 and CloudSim 2.0.0
- My first roadblock here was creating a world with invisible objects because my paths were not set correctly. First solution was to hard code the paths which results to a non-deployable project. The file organization setup (described above) by the OSRF team was the best way to go.
- Take good care in reading (and following) the right tutorials. I had gotten lost exploring that I couldn’t tell that the version I was following was not the same one I needed.