Starting in 2015, Gazebo has been included in the kit-of-parts delivered to FIRST teams. FIRST is a robotics competition held annually where high school teams build a robot to solve a unique challenge. This year's challenge is called Stronghold. A team's robot must breach an opponent's defenses, and weaken and scale their tower.

Gazebo is used by teams to experiment with robot architectures, test designs, and practice competing. Teams have access to a simulation environment that matches the 2016 game field specifications. Additionally, WPI provides numerous tutorials, interfaces, and support through FRCSim, a FIRST specific simulation environment that builds on top of Gazebo.

Of course you don't have to be a FIRST participant to use Gazebo or the competition environment. Try out Gazebo's new Model Editor to build your own custom robot. Use a joystick to control your robot, or write your own plugin to add extra functionality. Can't find what you're looking for, or need help? Check out out the questions and answers forum at answers.gazebosim.org.

Good luck to all the teams!

Download (7.0.0)

Changelog | Migration Guide | Roadmap

End-of-life Notice

Gazebo 2.x and 4.x have reached the end of their lives. We will continue to answer questions about these versions, but we will stop fixing bugs.

Highlights for 7.0.0

• Improved graphical model editor
• Torsional friction
• Wide angle camera sensor
• Simulation models composed of other models
• Improved log playback speed and graphical interface
• New GUI tools including alignment functionality and undo.

We are proud to announce the release of Gazebo 7. This version of Gazebo will have long term support (LTS), and marks a transition in our release process. A new version of Gazebo will occur yearly instead of every six months. Odd versions will have LTS, lasting five years. Even versions will have support for two years. This change will slow the rate of change in Gazebo, and give the developers a bit more time to polish features.

A large change in this release consists of a move to a consistent API, integration of Ignition Math, and a switch from boost to standard library features. You may notice numerous deprecation warnings as a result. While these changes may induce some burden on developers, it is important for Gazebo to advance toward a stable interface. Please pay attention to the deprecation warnings as the indicated functions will be removed in Gazebo 8.

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

  OSRF Development Team

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.