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!
Thanks to everyone for filling out the Gazebo survey, and helping direct our development plans. We have received 260 responses from simulation users around the world. The following is a summary of the survey results.
The core content of the survey listed a set of potential features for simulation. Survey participants ranked each feature from one to six, where one is low desire and six high desire. The following graph shows each feature on the x-axis, and the sum of the votes the feature received.
Physics validation has achieved a clear first place position. Throughout its history, Gazebo has aimed to mimic reality as closely as possible in order to offer simulation as a useful development and testing tool. The addition of physics validation will quantitatively ground the accuracy of Gazebo, and help guide the use of simulation. While difficult to accomplish, we also view Physics Validation as a high priority. Stay tuned for more updates on this effort.
Following in second through fourth place are Real-world sensor visualization, CAD import utility, and a graphical model editor. We will lump in the highly rated plotting and improved logging features to form a category about usability. Gazebo has not been known as a tool with a great user experience, and ability to easily import models and retrieve data. Fortunately, this is all about to change. Under active development is a graphical model editor that will simplify the process of creating new robots and objects, a plotting utility, and improved state logging and replay capabilities. Over this summer we will also kick-off a project to facilitate importing CAD models. Most of these features will likely land in Gazebo 4.0, scheduled for a release in fall of 2014.
For those of you keen on features that have not been discussed yet, fear not, they will be developed and integrated into Gazebo. The timeline for these features is a bit more fuzzy, but I can say that most everything on this list will be done or started in less than 1.5 years from now. If you would like to see something accomplished sooner rather than later, please speak up and ideally come prepared to offer some of your time. Send a message to our mailing list, and describe what project you would like to be part of.
We received a lot of great comments, feedback, and perspectives from everyone. The following is a brief list, broken into categories, of the feedback, in black, and our responses to the feedback, in blue.
Thanks again to everyone for their help and support. We look forward to a productive year, and keep the ideas and feedback coming!
Open Source Robotics Foundation (OSRF) is a participant in Google's Summer of Code and Gnome Foundation's Outreach Program for Women. Accepted students will work with OSRF mentors to develop code for Gazebo, ROS, and CloudSim.
Take a look at OSRF's GSoC project list and OPW project list. These projects are only suggestions, and we highly encourage applicants to propose different projects. Make sure to contact OSRF to discuss project ideas and any questions you may have. OSRF maintains two mailing lists: firstname.lastname@example.org and email@example.com.