2

For ROS 2, access to the most recent functionality and bug fixes is easy: just compile ROS 2 Rolling according to these instructions and your're set with the "latest and greatest".

What is the equivalent for Gazebo sim? I.e. what is the best practice procedure to build gazebo from source with the latest changes?

A practical example:

I would like to have the functionality of gz-transport#379 and gz-msgs#322. These are merged in gz-transport13 and gz-msgs10 respectively.

Gazebo Garden uses previous versions gz-transport12 and gz-msgs9 (i.e. without these PR's).

So I tried to build Gazebo Harmonic instead (per these instructions, but replaced collection-garden.yaml by collection-harmonic.yaml). This yields a source build that does include gz-transport13 and gz-msgs10. But whereas Garden has gz-sim7, Harmonic has gz-sim 'main' which is 116 commits behind of gz-sim7.

So I end up with a source build that has gz-transport#379 and gz-msgs#322, but lacks a lot of other features.

I could start trying to mix and match branches of the different libraries, but I assume there must be a better way?

JRTG
  • 1,654
  • 2
  • 2
  • 11

2 Answers2

2

First to understand the question, ROS rolling is close to be a bleeding edge (stability is not its goal), but the release of it is yet to be manually triggered AFAIK (ref. e.g. discourse.ros.org#24400), and such a trigger has taken place routinely but not on daily nor weekly basis, it cannot be like the "latest" or "nightly" that includes all changes that are merged a day prior.

That said, I took the question as "I want ideally nightly built installer, but if not, the one latest as possible.

  • On official site where the types of releases are explained (gazebosim.org), there's nightly. However, in the referenced link (e.g. Ubuntu) from there, I do see many generated .deb files but haven't found an installer file that sounds like "all-in-one" of the entire Gazebo suite. I might have missed it, or is it not placed on this website?
  • If you're okay with Docker, official docker images https://hub.docker.com/_/gazebo/tags includes latest. IIRC, this is manually updated, but at the time of writing the last update was 10 days ago so, so seems maintained.
IsaacS
  • 4,502
  • 1
  • 13
  • 13
  • Just noticed I had copy-pasted an incorrect link to the ROS 2 rolling install instructions; corrected now. – JRTG Jun 09 '23 at 13:38
  • I am not looking for binaries, I want to build from source. For ROS 2, this is easy: each separate repository has a 'Rolling' branch into which PR's are merged. For changes that span accross multiple repositories, the PR's are batched and merged at the same time, so you can always checkout the rolling branches and it will build. For Gazebo, I don't know an easy way to compile a working version with the latest changes. – JRTG Jun 09 '23 at 13:50
  • The way both ROS 2 and Gazebo are installed from source, is through a file listing all necessary repositories (ros2.repos and collection_garden.yaml respectively). For each repo the file lists the needed branch. A script then clones all those repositories. For ROS, the branch is always 'rolling'. For Gazebo however the branch varies per repository. E.g. Gazebo Garden requires gz-transport12 but recent PR's are in branch gz-transport13. – JRTG Jun 09 '23 at 14:02
  • Ohkay, I didn't know you were seeking source build. In that case, you should better update your post rather than commenting to an answer I posted, to have others better understand what you're looking for. – IsaacS Jun 09 '23 at 15:33
  • Well, the question does literally state "I.e. what is the best practice procedure to build gazebo from source with the latest changes?"... :-) – JRTG Jun 10 '23 at 17:45
  • @JRTG You're right, I'm sorry :/ – IsaacS Jun 12 '23 at 13:23
2

Building Gazebo Harmonic based on the collection-harmonic.yaml is the right thing to do, but I'm afraid some of the changes in Garden have not been forward ported to Harmonic yet. There are instructions here in the "Porting changes across branches:" section that you can follow to bring in changes from the branches you mentioned. Some forward ports are trivial, but others might require complicated conflict resolution. If you end up doing the forward port, I'm sure a PR would be appreciated.

azeey
  • 411
  • 1
  • 4
  • 8
  • Is this correct?
    For ROS, PR's merge into Rolling, and are possibly backported. Benefits:
    • Rolling is feature-complete,
    • The PR submitter typically has an incentive to do the backport,
    • And is -being author- often also best placed to fix merge conflicts,

    But at cost of extra work to submit, if the author needs the backport.
    For Gazebo: PR's target the lowest possible (compatible) version, and at some point a maintainer must forward-port. This:

    • Places the burden with the maintainers,
    • Complicates new development, as there is no feature-complete branch.
     – JRTG Jun 12 '23 at 09:55
  • Let's say I do a forward-port according to the instructions, how do I functionally test it before submitting a PR? By running colcon test --merge-install and assume it is okay if there are no failed tests? – JRTG Jun 12 '23 at 10:00