ROS 2 Crystal Clemmys call for testing and package releases

Hi everyone,

The ROS 2 team is preparing for the Crystal Clemmys release and we’d like to invite you to help us by testing out the pre-release or releasing your own packages to Crystal.

Testing the pre-release

ROS 2 is available with multiple RMW implementations on multiple platforms and architectures. Depending on your system configuration, you can help us out by doing any of the following:

After testing, reply back here to let us know what worked and what didn’t work, along with what platform you’re on and how you installed ROS 2.

If you run into problems, all the usual recommendations apply. You can ask questions on https://answers.ros.org with the crystal tag or report issues on https://github.com/ros2/ros2 or the relevant package repository. Be sure to follow the contributing guidelines and issue templates.

Releasing your packages

If you maintain a package you would like to release in ROS 2 Crystal we encourage you to do so by following the guide to releasing a ROS 2 package with bloom.

:peace_symbol:, :heart:, and :robot:,
The ROS 2 team

7 Likes

I just installed ROS 2 Crystal from sources on Ubuntu 18.04.

Everything went fine, but I would like to make a couple comments on the instructions:

  • In the setup_sources section link you should add the dependency on lsb-release.
    The first command would become:
    sudo apt update && sudo apt install curl gnupg2 lsb-release

  • In the Install development tools and Ros tools section link it looks like the pytest dependencies are needed only on Ubuntu 16.04. I’m on Ubuntu 18.04 and without them the build process prompted a lot of warnings about pytest missing and then failed while building the demos package.

ROS 2 Crystal from source working on Ubuntu 18.04. :ok_hand: Using master branch from Dec 7, 2018.
No issues in my tests with gazebo ros2 branch and MARA simulation.

2 Likes

And then add the repository to your sources list:

sudo sh -c 'echo "deb [arch=amd64,arm64] http://repo.ros2.org/ubuntu/main `lsb_release -cs` main" > /etc/apt/sources.list.d/ros2

I’m curious why you suggest setting up multi-arch sources right out of the gate? I can’t imagine that will often work well unless the rest of the sources are also setup to be multi-arch, which isn’t discussed there. Even then, why suggest it by default?

Updated in Add `lsb-release` to Setup Sources by sloretz · Pull Request #45 · ros2/ros2_documentation · GitHub. Thanks!

Would you mind opening an issue on the source repository for that documentation. I’ve tested the instructions and most of the pytest related packages are pulled in as dependencies of colcon on 18.04. Thanks

I can’t find the commit history but I think this was done as a quick way to detail what architectures are available. I’d review a PR to change the default repository link.

I do not see an issue with that as long as all packages are built for both architectures. You can easily extend this to deb [arch=amd64] and deb [arch=arm64] later if package sets diverge. But as long as this does not happen, it’s easier to just maintain a single repo line in the documentation.

Is there a wiki page for Crystal Migration Notes (as we have in ROS1)? In particular, I would like to help document the tf2_ros::Buffer API change to use ROS2 Time.

I think package-specific migration notes could go into the package’s README (which will also be rendered by index.ros.org) or another place where the package’s documentation lives.

If it will affect a lot of people, maybe it can go into https://index.ros.org/doc/ros2/Release-Crystal-Clemmys/#changes-since-the-bouncy-release ?

Thank you for the link. Anyone using tf2_ros::TransformListeners or tf2_ros::Buffers programmatically will need to update their code to add in a ROS2 Clock (it won’t compile without a change in Crystal). As this is a core piece of ROS, I think it warrants an entry to the changes list.

Huh. Am I weird for expecting colcon to be available after installing ros-crystal-ros-base? I had to install python3-colcon-ros manually. I don’t see that documented anywhere, but perhaps I glossed over it. Just apt-cache search'd and installed the thing that seemed to make sense.

Update: there’s also no --packages-select option supported in the colcon that I installed. This option is suggested in the “tips” section of the colcon tutorial as well as readthedocs for colcon. Am I missing something obvious?

Update 2: Oh wow, I needed to install python3-colcon-common-extensions, which I found after reading the build-from-source doc. Definitely feel like that should have been handled for me by installing ros-base, or some sort of colcon metapackage at least (perhaps simply called python3-colcon?).

Yes you are right.
From what I have seen, if you start from the official ROS2 docker images you get ROS, but no colcon or other developmet/build tools

None of the packages in ROS 2 have a dependency on the colcon build tool. This is sort of nice since production systems don’t necessarily need build tools so ROS 2 is one step closer to minimal production environments if the functionality to split out development info from runtime libraries is contributed.

The Linux development instructions cover the colcon package installation with python3-colcon-common-extensions. The package name isn’t my favorite. (My preferred color of the bikeshed is colcon-sensible :wink:) but because colcon is primarily implemented via plugins to the core colcon package and usable beyond the ROS ecoystem, the colcon-ros package includes only the packages needed to build ROS packages and not any of the creature comfort plugins that you might also want. Hence colcon-common-extensions to wrap them both.

I don’t agree that colcon or any tools needed only at build time ought to be in ros-base. But I also see where the suggestion is coming from and I think a base-devel- or build-essential-like metapackage which could include everything necessary to build ros-base from source is a reasonable metapackage to propose. As well as the inclusion of said package in ros-desktop. The metapackage contents are specified in REP-2001 and you can open pull pull requests against the ros-infrastructure/rep project to propose modifications.

I happen to completely agree with you there, but that leads toward having runtime and development completely split, and we’re not there. We’re at an awkward in-between, where installing ros-base pulls in all sorts of headers, which are only useful at build time, but no tool to utilize them.

Anyway though, not a big deal, just awkward enough I thought it may have been an oversight. If not, cool.