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:
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.
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
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.
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.
The Gazebo development team has been hard at work creating, refining, and testing the next version of Gazebo. We realized that a significant amount of knowledge surrounding the development and release process is held solely by the core developers. With a update to the Gazebo website, this information is now available to everyone.
The new Project Status section displays a plethora of useful information for people keen on understanding what has happened and what will be released in the near future. A progress bar on top of left column indicates the current release phase (development = orange, feature freeze = blue, code freeze = green). Below the progress bar is the Gazebo road map that includes key features from previous releases. The badges on the road map boxes indicate what version of Gazebo will be in ROS, and the recommended version for use with Ubuntu.
The right column contains a table with statistics about the code itself. This information can be used to evaluate the quality of the code. Below the table is a list of the tools that we use to check, test, and evaluate the code that is written.
Hope you enjoy and find the information useful!