On January 25th we will be releasing Gazebo 7. This release will have a lifespan of five years, and also marks a change in our release process. Releases will occur yearly, instead of every 6 months. Odd releases will have a 5 year life span and even releases 2 years.

We are actively testing Gazebo 7, and could use your help. The following link contains a spreadsheet of tutorials with testing instructions. If you have time over the next two days, please a look and try out a few tutorials using the Gazebo 7 prerelease debians.

Tutorial spreadsheet

Or, install gazebo7, play around, and let us know if anything is broken or looks odd.

Thanks for any help and support.

During his internship with OSRF, Mike Kasper developed a new ignition-robotics rendering library. The key feature of this library is that it provides an abstract render-engine interface for building and rendering scenes. This allows the library to employ multiple underlying render engines. The motivation for this work was to extend Gazebo's rendering capabilities to provide near photo-realistic imagery for simulated camera sensors. This could then be utilized for the development and testing of perceptions algorithms.

As Gazebo currently employs the Object-Oriented Graphics Rendering Engine (OGRE), an OGRE-based implementation has been added to the ignition-rendering library. Additionally, a render-engine using NVIDIA's OptiX ray-tracing engine has also been implemented. The current OptiX-based render-engine employs simple ray-tracing techniques, but will employ physically based path-tracing techniques in the future to generate photo-realistic imagery.

The following videos give an overview of the libraries' current capabilities:


Source code for the ignition-rendering library is available here:

https://bitbucket.org/ignitionrobotics/ign-rendering

The Advanced Robotic Systems Engineering Lab at the Naval Postgraduate School in Monterey, CA recently flew fifty small autonomous planes together using ROS.

Each plane - a styrofoam wing with a 56” wingspan - was equipped with a Pixhawk autopilot running a modified version of the open-source Ardupilot firmware and an ODroid u3 “ payload” computer running ROS Indigo. The payload used autopilot_bridge (similar to mavros) to bridge between serial communications with the autopilot and ROS messages and services. A network node bridged ROS communications with a lightweight UDP-based protocol that allowed aircraft to share their pose and status with one another and to receive commands from the ground.

Also residing on the payload was a set of controller nodes that could “drive” the plane by sending updated target latitude-longitude-altitude commands to the autopilot. Controllers were individually activated by a state machine, based on commands from the ground. The controller used during the fifty-plane flight was a follower controller. A single ground operator commanded two sets of 25 planes each to configure themselves into leader-follower formations; planes would determine a leader based on highest altitude (which was deconflicted at the start of the flight). The leader would then proceed along a predefined racetrack, and all followers, listening to the broadcast position of the leader, would track its path while remaining at their designated altitudes.

A detailed writeup of the flight test is posted at DIY Drones and more information on the research project can be found at the ARSENL website.

Download (6.0.0)

Changelog | Migration Guide | Roadmap

End-of-life Notice

Gazebo 1.9 and 3.x have had a nice long lives, and it's time to put these version to rest. We will continue to address questions about Gazebo 1.9 and 3.x, but we will stop fixing bugs.

Highlights for 6.0.0

Another six months has elapsed, and nicely polished Gazeob6 is ready for use. We spent a considerable amount of time delving into Windows in an effort make Gazebo cross-platform. The process of compiling Gazebo on Windows was both a learning experience, and an uphill battle. The good news is that you can now compile Gazebo natively on Windows. Over the coming months we will refine this process, and offer a proper Windows installer.

A few of Gazebo's internal libraries are slowing transitioning into separate packages. We noticed that Gazebo has many great capabilites that are hidden or difficult to use. Access to these features will improve with this separation, and Gazebo's core footprint will shrink. The first library to to start this transition is Gazebo's math library, which is now Ignition Math. Gazebo7 will see a complete transition to Ignition Math, and the start of Ignition Transport which replaces Gazebo's internal transport library.

Enjoy the new release, and thanks for all the contributions,

  OSRF Development Team

Thanks to everyone for filling out the Gazebo survey, and helping direct our development plans. We have received 128 responses from simulation users around the world. The following is a summary of the survey results

Feature votes

The survey consisted of thirteen high-level features and a text entry for comments. The features were on a scale from 1 to 5, where 1 is low importance and 5 high. The following figure shows the sum of the votes for each feature. vote-chart A nice dividing line exists around the 420 vote count. Six features are above this line:
  • Physics validation,
  • Diagnostic tools,
  • Physics helpers,
  • Rapid design tools,
  • Documentation, and
  • Performance improvements.

Comments

The following is a condensed list of feedback we received in the comments section of the survey. There is no particular order to this list.
  • Tutorials and documentation: Comments included improved tutorials for plugins, developing new sensors, debugging, and robot control.
  • Multiple distributions: This includes support for Windows, Mac, and other distributions of Linux besides Ubuntu.
  • Performance: Using Gazebo in courses where students have low power computers would be helpful, and better support for laptops.
  • Visualization and tools: Display of real and simulated sensor data. Support rewinding simulation, mobile obstacles (which I'm interpreting to be models that can be scripted), and improved human models.
  • Physics: Support for springs, omniwheels and tracked robots, better grasping, air and water flows, grass and uneven terrain, fixed joints, stable and accurate physics, and better default physics values for different environments (eg: indoor vs outdoor).
  • Formats: Allow import of Industry Foundation Classes (IFC) files, commonly used in the AEC industry. Merge SDF and URDF. Support for FMI and co-simulation. Get ROS to use Ignition Transport.
  • Design: Graphical editor to build and edit robots and models. Not more editing text files.
Thanks to everyone for participating in the survey. We received a lot of thanks and appreciation for developing and maintaining simulation, and our own Jackie Kay received a special shout out for helping on the brr-users group. We are actively integrating this feedback into our roadmap, which will be updated over the next few days.