Software reuse in ROS1 and ROS2

Next Generation ROS
2

First I want to mention that the following answers only describe the current state. While we have gained some experience with migrating code we have not yet settled on one (or multiple) specific strategies which we feel comfortable to “officially recommend”. Therefore this can still change in the future.

  • Currently the ROS 1 and ROS 2 packages are released into separate ROS distros. Since both distros have their own namespace (e.g. both have packages with the same name) it is not straight forward to have dependencies between a ROS 2 package and a ROS 1 package as you have notices for the ros1_bridge. E.g. on the CMake level it is necessary to identify each package uniquely by its name which is not the case across both ROS versions. Therefore the bridge uses CMake config files only for ROS 2 packages and falls back to pkg-config for ROS 1 packages.

  • Currently the ROS 1 buildfarm and ROS 2 buildfarm are separate instances. But that is more due to keeping things easy to manage. E.g. the ROS 2 Jenkins uses ARM hardware rather than relying on QEMU. Both build.ros.org as well as build.ros2.org are using the same underlying logic provided by ros_buildfarm. Currently the ROS 2 buildfarm doesn’t have doc / devel / PR jobs but those will be added in the future. But more needs to be done i order for the ros_buildfarm to be able to use ament as well as support Mac OS and Windows nodes.

  • Regarding the question if “it be possible to build one set of sources in both ROS1 and ROS2 distros” that is rather difficult to answer. It highly depends on what the sources are doing / using. If you rely on roscpp in ROS 1 and therefore need to use rclcpp in ROS 2 there are significant changes in the API. Maybe you even want to switch from using nodelets in ROS 1 to using components in ROS 2. Using the same source for both will likely require a lot of conditional code. I am not sure if that is manageable / desired. Two separate branches which are different in these regards might be easier to manage as well as easier to read. That being said this should be possible after all - it only depends how much of the differences between the two system you are willing to “abstract” in your code base.

    catment was only a brief prototype which hasn’t been continued since then and has many cases where it currently doesn’t work. While it would be convenient to have such an API abstraction a package can easily update its CMake code and use either build system conditionally. Not pretty but doable for now. The decision if we spend more effort into a CMake API shim (which I describe as a ROS 2 package named catkin which provides the same API as the ROS 1 package but uses ament_cmake internally) depends on the path for migration. As mentioned above we haven’t settled on that yet which path(s) to recommend.

  • We have considered providing an API shim to mimic “some” ROS 1 API and implementing it under the hood with ROS 2. But significant effort has been put into it so far since there seem to be several difficulties with that approach. But maybe something like that can make it easier in the future to reuse existing ROS 1 code with ROS 2.

I am likely not answering your questions well. There is still a lot of work necessary to figure out the coexistence between ROS 1 and ROS 2 and potential migration paths. Neither hasn’t received the necessary attention in the past. Hopefully that will change in the future since I think these are all questions which are crucial before considering a first (non-beta) release of ROS 2.

1 Like