[ROS] Add Official Docker image for ROS2

[ruffsl]

In preparation for the release of for adding ROS2 to images to the Official Docker Library: docker-library/official-images#5183

This README is derived from that of ROS1, but has been adapted to reflect ROS2. Changes include:

• Added Dockerfile examples for both installing and building ROS packages
• Removed more elementy/repetitive Docker CLI walkthroughs-
• Inplace with concise docker-compose examples
• Added example using ROS2 with security enabled

Let me know if you have any thoughts or suggestions.
ping @tfoote @nuclearsandwich @sloretz

[tianon]

I'm totally lost as to why this is being proposed as a new image instead of being tags of the existing "ros" image?

[ruffsl]

I'm totally lost as to why this is being proposed as a new image instead of being tags of the existing "ros" image?

Very understandable; the confusion perhaps stems from that the projects are so similarly named but in many ways separate parallel efforts. Among the differences between ROS (hereon referred to as ROS1) and ROS2: separate package ecosystem, non-interchangeable APIs, different wire-transport implementation, new build system, modified message types, different CLI syntax, etc... Although ROS1 and ROS2 share similar concepts of topics/services/actions/parameters/nodes/namespaces, they are not compatible.

I suppose one may argue that such different projects sharting the same naming could collocate under the same repo using only tags, like with python and version 2 and 3. Yet this comparison falls short in few ways:

• In Python it is possible write a package that support both a v2 and v3 runtime
  • Not possible with ROS1 and ROS2 as api/apt/build/install/launching of packages are different
• Python is a programming language and is released by versions
  • ROS1 and ROS2 are more like frameworks or ecosystems, each with distro generations

Another difference is that both ROS1 and ROS2 are ongoing projects. Though the distro names of the two do not collide, I would suspect it confusing to folks reading tags and attempting to determine which are ROS1 compient and which are ROS2, or what is the latest LTS version of either?:

• ros:indigo
• ros:kinetic
• ros:bouncy
• ros:lunar
• ros:crystal
• ros:melodic

But suppose we could add another sub-super prefix to the tags to denote ROS1 vs ROS2, but at that point I think the repo name would be nice to do that with.

Another is that currently the latest tag currently points to the most recent LTS distro. How should that be reconciled when each has its own latest latest distro? If someone reads a historic FROM ros in a dockerfile, a run script, or a docker compose project, how are they to know if it refers to a ROS1 distro or a ROS2 distro?

Lastly, the projects necessitate different instructions in how they are containerized, again due to the build/install and run CLIs, but also as the transport implementation, e.g. XMLRPC vs DDS, centralized master broker vs disitrolized discovery, requires different user documentation, thus the differences between the ROS1 and ROS2 README docs I've written.

For more background on branding, see the communities 'Why ROS 2.0' design artificial for further motivation:
https://design.ros2.org/articles/why_ros2.html

Perhaps @nuclearsandwich @tfoote or @sloretz could speak to this effect or suggest alternatives.

[tfoote]

We talked about this internally and I think that although we've been hosting many ROS2 resources in separate locations this is just another version of ROS so it does make sense to just use new tags under the existing repository. There will be overlapping alphabetic listings and latest will give you the latest LTS which for now will stay ROS1 until we have an official LTS for ROS2 then we can switch it over. In other places they are only differentiated by the distro name such as the debian packages so people can/should be able to differentiate things.

At some point the ros:latest always does make a switch between rosdistros and if you want a specific version you should use a specific tag. I also wouldn't add another layer to the tags. The distros are unique between ROS1 and ROS2 and we now have indicators in the environment that can differentiate them.

[ruffsl]

We talked about this internally and I think that although we've been hosting many ROS2 resources in separate locations this is just another version of ROS so it does make sense to just use new tags under the existing repository.

@tfoote , I'd fine with merging the repos. I'll have to rework the CI, but doable.
Still, I have some follow up questions:

Tagging

What should be tagged as latest? Use the latests supported ROS1 LTS, or the most recent release of ROS2?

There will be overlapping alphabetic listings and latest will give you the latest LTS which for now will stay ROS1 until we have an official LTS for ROS2 then we can switch it over.

I'm leaning towards the most release of ROS2 support migration (or perhaps the latest stable release of ROS2, depending on if we follow through with rolling releases), but is sounds like you'd recommend leaving it to ROS1 for now until a ROS2 LTS is released.

Documentation

Should we still overhaul the documentation to include ROS2 though? I think mediating the nuances between ROS1 and ROS2 deployment would be out of scope in the simple introductory readme. As mentioned above, the details one has to consider when containizing ROS is rather different between versions.

[mikaelarguedas]

looks great. couple typos and nitpicks remaining

[ruffsl]

Ping @tianon @yosifkit @mikaelarguedas , with the release of ROS2 Foxy, this is ready to be merged, as we'd like the docs to be update to reflect the move to ROS2 and provide relevant examples.

• [ros] Release ROS foxy images and make them latest official-images#8138
• Foxy images osrf/docker_images#395
• https://discourse.ros.org/t/ros-foxy-fitzroy-released/14495

[tianon]

Overall this seems fine -- just one comment about the one-sentence-per-line change that you probably want to look into.

It does seem like this is getting kind of lengthy, and might end up being a bit annoying to read on https://hub.docker.com/_/ros, so it might make sense to move a lot of this content to somewhere on https://www.ros.org/ and link to it from here instead, but that's ultimately your call.

[ruffsl]

so it might make sense to move a lot of this content to somewhere

I think we could trim down the discussion bit that's not as essential as the use examples, but I'll do that in a separate PR, as we'll need to update the tag listing once we've added support for the ros1-bridge tag later on anyway.