Support for ROS2 humble?

[kulkarni-raunak]

Hello Field-Robotics-Lab community,

Is there a support for this simulation to run with ROS2 humble , Ubuntu Jammy 22.04 and Gazebo garden?

[mabelzhang]

Not currently, but we'd love to see community efforts to port it.

I'm going to make a motion at the next ROS Maritime Working Group (next Tue, Nov 7, announced here) for the community to pick up some work in this repo, and porting will be one of them.

I've been given some good ideas for how to start that, beginning from simple things like SDF models. Plugins will be the hardest. I'll create some issue tickets and add them to the WG kanban board to make them visible to the WG community.

[woensug-choi]

@mabelzhang I want to give it a try.... not sure I can finish it. Which version pair of ROS and Ignition should I aim for?
Ubuntu Jammy 22.04, ROS2 humble and Gazebo Fortress?

[mabelzhang]

Sigh... that's a good question. The latest is Gazebo Ionic, which is targeting ROS 2 Jazzy Harmonic.

The official recommendation is in the table here https://gazebosim.org/docs/harmonic/ros_installation

Ionic and Jazzy pairing is not on there yet, but that's the plan. However, Ionic is not LTS. So maybe Gazebo Harmonic and ROS Iron.
Edit: Sorry I misremembered. The pairing should be Harmonic and Jazzy.

Fortress is way too old. I do not recommend it, even if that is the recommended green check. We were able to get ROS 2 Humble and Gazebo Garden to work just fine for MBARI WEC, so I would do at least that, or newer. All the newer underwater features we added from WEC, like added mass etc., are in Garden.

[mabelzhang]

I can open a more formal ticket for it. @evan-palmer was looking to port to ROS 2 too. I need to gather a checklist. @caguero suggested that some things are low hanging like models. Others like ROS plugins are going to be more work. A checklist will allow people to pick off the easy ones fairly easily and do things comfortable to them.

@evan-palmer what Gazebo/ROS 2 pairing were you thinking of?

[mabelzhang]

We will have to merge #246 before/when we port the models.

[woensug-choi]

So...

1. ROS Jazzy (LTS ~ 2029) and Gazebo Harmonic (LTS ~ 2028)
2. ROS Humble (LTS ~2027) and Gazebo Garden (~2024)
3. ROS Iron (~2024) and Gazebo Harmonic (LTS ~2028)

so many choices... After listing the options, I see Jazzy Harmonic is a best choice to put efforts..

[mabelzhang]

That sounds reasonable for both to be LTS.

For installation, one would want to follow the instructions on this page, under "Gazebo Harmonic can be used with ROS 2 Rolling but ros_gz will need to be compiled from source." There's also a step to install rosdep rules for Harmonic.

[woensug-choi]

I got my hands on this. I will base from Ubuntu 22.04. Meanwhile, added installation methods edits on document for those who are using Ubuntu 22.04 (probably most of the users nowadays). Field-Robotics-Lab/dave.doc#4

[woensug-choi]

@mabelzhang I am bit confused. Jazzy is not distributed yet. I guess ROS2 Rolling will become Jazzy when the time comes right? I found a list of repos for Rolling (https://github.com/ros2/ros2/blob/rolling/ros2.repos). Is these package list the right place start porting the dave for preparation of Jazzy?

[mabelzhang]

Yeah, Jazzy is to be released May 2024. Right now Rolling is what will become Jazzy.

So, if we want to do Jazzy+Harmonic pairing, that will work once Jazzy is released. Before Jazzy is released, it unfortunately will need to be Rolling built from source.

Iron + Harmonic would be the next-best pairing. Both are currently the latest released versions, so they can be installed from binaries. When Jazzy is released, then the code can be updated. Hopefully from Iron to Jazzy will not be a lot of work... I am not familiar with what's on the ROS 2 roadmap to say for sure. I've asked internally and will update here.

Is these package list the right place

Oh no that file is all the packages for ROS 2. It's massive. You wouldn't want to look at that.

You only need to port packages within DAVE, so packages in this repo.
Note that we're talking about 2 different migrations. ROS 1 to ROS 2. Gazebo-classic to new Gazebo. I would do them one at a time. (As in, you can use ROS 1 with new Gazebo, and ROS 2 with Gazebo-classic. So I wouldn't change the code for both ROS 2 and new Gazebo at the same time, it could become very hairy because you'll also need to think about gazebo_ros_pkgs to gz_ros_pkgs.)

For ROS migration, I suspect it's mainly the ROS plugins. https://github.com/Field-Robotics-Lab/dave/tree/master/gazebo/dave_gazebo_ros_plugins
package.xml should be straight forward.
Launch files should keep using the XML format in ROS 2. Do not convert to Python launch files - that's more of a pain.
We have tutorials for migrating ROS 1 to ROS 2 https://docs.ros.org/en/iron/How-To-Guides/Migrating-from-ROS1.html

For Gazebo migration, that's models and Gazebo plugins. Those tutorials are here https://gazebosim.org/api/sim/8/tutorials.html

Lastly, for combining the two, there's tutorials for ROS 2 + new Gazebo integration here https://gazebosim.org/docs/harmonic/tutorials#ros-integration

There's also URDFs.
This section explains some latest updates to URDF/SDF: "The main pain point of using existing simulation assets with ROS 2 tools was updating URDF files into a Gazebo-readable format. This is no longer required. If you are maintaining a URDF and an SDF file in a project, you can now drop the URDF and just use the SDF for both ROS and Gazebo."
https://gazebosim.org/docs/harmonic/ros2_interop#maintaining-a-single-robot-description-format

Unfortunately, we don't have a tutorial for migrating from gazebo_ros_pkgs to ros_gz, which is the bridge to talk between ROS and Gazebo.
VRX is a good example to look at, which has been ported from ROS 1 + Gazebo 11 to ROS 2 + new Gazebo https://github.com/osrf/vrx/tree/main/vrx_gz
It uses the ROS 2 <-> gz bridge.
Note that they use Python launch files. I think you should be able to keep XML.
MBZIRC does similar in ROS 2 + new Gazebo https://github.com/osrf/mbzirc

Some things in this repo have already been upstreamed to new Gazebo, like
Hydrodynamics https://github.com/gazebosim/gz-sim/tree/gz-sim8/src/systems/hydrodynamics
Buoyancy https://github.com/gazebosim/gz-sim/tree/gz-sim8/src/systems/buoyancy
Bottom-tracking DVL https://github.com/gazebosim/gz-sim/tree/gz-sim8/src/systems/dvl
You don't need to port those. There might be others. Check the Feature Comparison page to see if we have things in new Gazebo already https://gazebosim.org/docs/harmonic/comparison

The order of doing things -

1. The simplest things to start with would be the Gazebo SDF models - upstreaming the SDF models to Fuel https://app.gazebosim.org/dashboard , updating the files to the new URL on Fuel. As you upstream, you'd delete them from the repo (in a new branch of course). Make sure that still works.
2. Then maybe the URDF models, to make sure robots still load.
3. Then try the hydrodynamics and buoyancy plugins in new Gazebo, see if things still behave correctly.
4. I would save the plugins for the very last, because they're likely the most complicated to migrate. Maybe Gazebo plugins are more isolated (I haven't looked at them). ROS plugins probably have more dependency as it would require the ros_gz bridge.

I really need to convert this comment into a meta-ticket... This is a pretty big effort and really needs to be broken down into separate bullet lists.

One really important thing to keep in mind, is that we should upstream as many things as possible to Gazebo itself (such as what Arjo did with the bottom-tracking DVL), to ensure future maintenance. If things are upstreamed, the Gazebo development team will maintain them in the future, so that things don't become orphaned in DAVE in the case that DAVE is no longer maintained.
Upstreaming things is a bit more overhead, because code needs to be formatted following Gazebo styling, code takes longer to review upstream and get merged. Even if we do not start with that initially, that does mean any new Gazebo code being written in the migration should start by following Gazebo plugin styles - you can see all the plugins here and how they're formatted https://github.com/gazebosim/gz-sim/tree/gz-sim8/src/systems
There's probably CI checks that can be updated.

[woensug-choi]

Wow... where should I put my hands?? haha.. I might need sometime to understand and get to a starting point!

[mabelzhang]

Yeah. Let me try to put an initial meta-checklist ticket together by end of the week. It might not have everything, but it'll be a starting point that I can edit later. I probably won't get to it today. Hopefully by Friday.

I would say start in the order of the numbered list above. Maybe familiarize with the SDF in new Gazebo. This PR does some SDF migration to Fuel and can give you examples: #242

To generally familiarize yourself with what things look like before and after, you can look at VRX in Gazebo-classic and new Gazebo
Gazebo-classic: https://github.com/osrf/vrx/tree/gazebo_classic
New Gazebo: https://github.com/osrf/vrx/tree/main
The migration is done by Carlos and NPS folks earlier this year. So you know who to ask if you have questions.

Hopefully you pick up some ideas from comparing the two branches and seeing what's different.

[evan-palmer]

@mabelzhang do you know if Harmonic will be the recommended GZ version for Jazzy? Regardless, Jazzy and Harmonic would be a nice target since that would provide two LTS options to users with some pretty long-term stability while things go through migration.

The simplest things to start with would be the Gazebo SDF models - upstreaming the SDF models to Fuel https://app.gazebosim.org/dashboard , updating the files to the new URL on Fuel. As you upstream, you'd delete them from the repo (in a new branch of course). Make sure that still works.

Instead of deleting the models altogether, it might be nice to have a separate repo (or even continue using this one) for new users to contribute models toward. I was thinking that it could be helpful to add a CD pipeline using GZ Fuel Tools to auto-deploy new models or changes to existing models to Fuel to help reduce some of the overhead associated with maintaining models. What do you all think?

[mabelzhang]

Jazzy Harmonic will be paired with Ionic (as mentioned in #276 (comment)).

Right now, since Jazzy isn't released yet, if DAVE targets that, DAVE developers will need to build some things from source, which can be an overhead. See https://gazebosim.org/docs/harmonic/ros_installation#using-a-specific-and-unsupported-gazebo-version-with-ros-2 They at least have to build ros_gz from source, which isn't too bad. But "Both approaches may also require that you modify your ROS or Gazebo source code to support this compilation." That would be a bigger overhead. That would be needed if there's a dependency on gazebo_ros (the bridge for Gazebo-classic), which I think DAVE has, for example this package.xml lists it as a build dependency. Someone would have to see if more than ros_gz (the bridge for new Gazebo) needs to be compiled from source.

On the flip side, given that migration will take significant time, maybe by the time migration is done, Jazzy will have been released, then everything will work then.

Whichever pairing we do, we will need to provide a Dockerfile on dockwater, which hopefully lightens the burden of compiling ROS.

Instead of deleting the models altogether, it might be nice to have a separate repo (or even continue using this one) for new users to contribute models toward.

I would recommend new users to contribute models directly to Fuel, as opposed to this repo, because this repo will have the same problem of not being maintained. The community has been contributing models to Fuel for other projects, like SubT and our other client projects. In fact, we already started doing that for new models we created for DAVE - you can see the collection here https://app.gazebosim.org/OpenRobotics/fuel/collections/DAVE We just didn't have time to upload the rest. Now would be a good time to migrate the rest to Fuel.

Fuel has the advantage of more visibility, as people from other projects will be able to see them and use them. There's also online preview and thumbnail of the models. Models are searchable by name or tag or org, etc. People can click a button to download and use them directly.