Gazebo Migration Guide & Office Hours

Gazebo Migration Guide & Office Hours



TurtleBot3 Simulation in Gazebo Classic, and after migration in Gazebo Fortress


:two_hearts: Happy Valentine’s Day! For the holiday we’ve put together a gift for the community. As many of you are well aware Gazebo Classic is going end-of-life in a little less than a year. A little over a month ago we put together a community survey to see how we can help the community transition to modern Gazebo. One of the things we determined is that a lot of users are a little bit unclear about the steps involved for migrating their projects from Gazebo Classic to modern Gazebo.

To help the community make the transition we’ve put together a migration guide that shows how to migrate a complex ROS and Gazebo project from soup to nuts. In our case we took the TurtleBot 3 simulation and migrated it from Gazebo 11 Classic to Gazebo Fortress step by step. In the migration guide you can check out each and every file before and after migration and see exactly what we did and why. The guide includes instructions on how to migrate dependencies, launch files, SDF files, package.xml files, and yaml configuration files. We hope this guide will become the go-to reference for everyone moving from Gazebo Classic to modern Gazebo. If you need help picking the correct version of Gazebo for your host operating system or ROS installation make sure to check our compatibility table.

:heartpulse: You can find the migration guide here :heartpulse:

To further assist the community with the migration away from Gazebo Classic we’re also planning to start conducting regular Gazebo Migration office hours! If you find yourself getting stuck while migrating a Gazebo project feel free to swing by our office hours to ask a question or solicit some advice. We’ll have a few members of the Gazebo development team on hand to answer questions. We’ve planned two office hour meetings over the next month; depending on participation we will announce additional office hours in the future.

Gazebo Office Hours

Tuesday 2024-02-20T17:00:00Z
Video call link: https://meet.google.com/fes-rgpj-fpv
Or dial: ‪(US) +1 952-243-1467‬ PIN: ‪561 935 002‬#

Tuesday 2024-03-12T16:00:00Z
Video call link: https://meet.google.com/fes-rgpj-fpv
Or dial: ‪(US) +1 952-243-1467‬ PIN: ‪561 935 002‬#

6 Likes

Are there any recommendations on how to migrate large projects and support multiple versions of gazebo? The migration guide looks great, but seems to assume you can do the migration all in a single pull request and only want to support one version of gazebo.

In ArduPilot, we currently support either harmonic or garden. These have different dependencies on varios gz libraries in each version, so rosdep entries are conditional depending on the value of GZ_VERSION.

I proposed similar changes in NAV2, but it doesn’t seem like the right approach: See NAV2 PR#4095 (I can’t link it here for some reason).

Two aspects of the migration are a bit confusing to me:

  1. At what date will ROS 2 packages on rolling retarget ubuntu Noble which supposedly doesn’t have gazebo classic installed?
  2. Is the use of the environment GZ_VERSION standard practice for handling multiple different versions? On humble, it doesn’t make sense to use fortress in new packages because of the name changes, so I would have thought GZ_VERSION is a good way to express the differences. For example, the linked tutorial for harmonic adds a rosdep dependency on ros_gz_bridge which resolves to on humble to ros-humble-ros-gz-bridge which depends on libignition-msgs8-dev, while harmonic uses version 10: gz-harmonic/gazebodistro/collection-harmonic.yaml at 6bdc990f2b6008128a9d3e5a0594f77677b103de · gazebosim/gz-harmonic · GitHub
  1. At what date will ROS 2 packages on rolling retarget ubuntu Noble which supposedly doesn’t have gazebo classic installed?

Because Harmonic is not in Ubuntu upstream, we are looking at a different way of providing Gazebo for ROS users. We are currently evaluating if using vendor packages is feasible. Stay tuned…

Is the use of the environment GZ_VERSION standard practice for handling multiple different versions?

We don’t have a good story for supporting multiple versions of Gazebo with ROS. This is a difficult problem and for most users, we recommend sticking to the version of Gazebo officially paired with the version of ROS you’re using (e.g Humble/Fortress, Jazzy/Harmonic, etc.). If you do want to support multiple versions, then yes, the GZ_VERSION environment variable is the best way so far, but for rosdep to work properly, you’ll have to build ros_gz from source, which will also do the right thing based on GZ_VERSION.

Also, the vendor package solution might help with this issue going forward.

Hmm, here’s a hard block for the migration on Focal: The DART version from Ubuntu repos doesn’t support tracked vehicle simulation. packages.osrfoundation.org doesn’t distribute the forked dart. Only dart version with support for tracked vehicles is in DART 6.10 from dart : “Open Robotics” team , but that version is incompatible with libgazebo11-dev (Depends: ... libdart6-utils-urdf-dev (<< 6.10.0) | libdart-utils-urdf-dev (<< 6.10.0) ...).

This is a reeeeeaaalllyy pity story given that it worked on Bionic/Gazebo 9/Dome!

There is an ugly workaround with partial from-source install described in `Conveyor` & `TrackedVehicle` example worlds are not working · Issue #1662 · gazebosim/gz-sim · GitHub .

Bumping this thread to remind everyone that we have Gazebo Migration Office Hours next Tuesday.