The fifth and final part in our series of posts about new features in Gazebo 3.0 covers the new Gazebo command-line tool.

Taking a cue from many popular command line interfaces, such as mercurial and git, we have unified the Gazebo command-line interface into one tool called gz. Previously, multiple independent tools (gztopic, gzlog, gzsdf, etc) provided system introspection and control for Gazebo. These tools, while powerful, had slightly different syntax, lacked proper testing, and were difficult to remember. The new gz tool addresses all these issues, and even adds a few new features such as joint control.

To see a list of the available commands, simply type gz help. Similarly, get help for a specific command using gz help <command>.

The new command line tool also incorporates tab-completion. This improvement will simplify the process of topic introspection.

We hope you enjoy this new tool as much as we do!

The fourth part in our series of posts about new features in Gazebo 3.0 covers multiple physics engines.

Gazebo 3.0 will supports the use of four different physics engines:

  • Open Dynamics Engine (ODE): Default, and available via the Gazebo debian
  • Bullet: Available via the Gazebo debian
  • Dynamic Animation and Robotics Toolkit (DART): Available via a source install
  • Simbody: Available via a source install

We are especially excited about the addition of DART and Simbody, which are Featherstone-based engines optimized for joint chains.By comparison, Bullet and ODE are maximal coordinate solvers which are optimized for performance over many independent models. Each physics engine was developed by its own community, motivated by a particular application domain, from gaming (Bullet) to simplified robot dynamics (ODE) to biomechanics (Simbody) to computer graphics and robot control (DART). We have been working with teams from Georgia Tech (DART) and Stanford (Simbody) to integrate these two physics engines, and we hope you find them both very useful.

To our knowledge, this is the first time that such a diverse set of physics engines has been supported in one simulator.

By supporting multiple engines, Gazebo allows the user to choose the approach that performs best for his or her needs. For example, maximal coordinate solvers like ODE and Bullet perform well when simulating cluttered environments, while Featherstone-based solvers like DART and Simbody are potentially more accurate in simulating articulated systems such as humanoid robots.

All four physics engines can be accessed through Gazebo’s generic physics API. Users can simulate dynamic models created using Simulation Description Format (SDF) or Unified Robot Description Format (URDF) with any of the four supported physics engines.

Below is a video demonstration of the Atlas robot performing a dynamic walking task with Boston Dynamics's proprietary walking controller. The results from all four physics engines are superimposed.

The third part in our series of posts about new features in Gazebo 3.0 covers breakable joints.

Gazebo now supports breakable joints through the use of the BreakableJointPlugin attached to a force-torque sensor on the desired joint. A breaking force can be specified in the xml parameters for the plugin, and the plugin will detach the joint when the force-torque sensor detects a force magnitude that exceeds the threshold.

An example model named breakable_test has been added to the gazebo_models database. The example consists of an array of small blocks connected to the world with breakable joints. The blocks can be dislodged from the wall through collisions with heavy objects or by increasing gravity.

The second part in our series of posts about new features in Gazebo 3.0 covers Digital Elevation Models and terrain paging.

A Digital Elevation Model (DEM) is a 3D representation of a terrain's surface that does not include any objects like buildings or vegetation.

The main motivation to support DEMs in Gazebo is to be able to simulate realistic terrain. For example, rescue or agriculture applications might be interested in testing their robot behaviors using a simulated terrain that matches the real world.

Organizations such as Global Land Cover Facility maintains a high-resolution digital topographic database of Earth. It's possible to search and download a specific region in any available DEM database and load it into Gazebo.

Gazebo 3.0 is able to load a DEM terrain in any of the near 100 different formats supported by GDAL, the underlying library that we are using to manage the terrains. Currently, Gazebo supports the option of loading the DEM keeping its original dimensions, or re-scaling it using a specific width, height, and elevation.

As an example, you can see screenshots of the Canary Islands in Spain and the Mount St. Helens in United States.

Mt. St. Helens
Canary Islands

A new terrain paging strategy has been implemented in Gazebo. This feature has been partially adapted from the Ogre graphics engine. The terrain is internally split in multiple pieces. Each piece is loaded/unloaded by the rendering engine depending on its distance to the cameras in the scene.

The terrain paging for the rendering engine is an optional feature. A new element has been integrated in the gazebo SDF language. The user can choose whether enable or disable this feature on demand.

The screenshot shows four snapshots of the same scene with the camera user at different distances from the terrain. As you can see, the subterrains are unloaded from the scene while the camera moves away. The distances from the camera at which terrain pages are loaded/unloaded can be parametrized.

terrain_paging1
terrain_paging2
terrain_paging3
terrain_paging4

This is the first part in a series of posts about new features in the soon to be released Gazebo 3.0.

Gazebo will gain the capability of using lightmaps, which can be used to improve the rendering performance of complex scenes. Lightmaps can be thought of as texture maps with lighting information pre-baked into the texture. The resulting models appear as if they are shaded by lights in the environment but in fact they are just textures. Lightmaps are typically used for models that do not move with respect to the pose of the lights in the scene. For example, static buildings in an environment with a directional light.

In Gazebo, a lightmap is associated to a model as opposed to the whole scene because there is almost always the chance that something moves in a robot simulation! Lightmaps can be created using popular 3D modeling tools, such as Blender, with the lighting model you see fit. Once the lightmap is generated, export it along with the mesh files and textures as usual and place them in your Gazebo model path. In the model SDF file, apply the lightmap to the model in the same way as if it’s a texture map then simply disable the lighting on the visual.

An example model with lightmap is added to the Gazebo model database. Look for the table_marble model in the Insert Model tab in Gazebo.