[cmake] support packages that provide optional ros2 integration but do not require it by default

[ahundt]

Many packages try to provide ros integration without making ros a requirement for other potential package users that do not or cannot support ros/ros2 for legacy, contractual, or application specific reasons. Ideally the new build system will make it as simple a process as possible to enable a package to support ROS2 messages/nodes while not requiring them. This means if a recommended layout is provided it is not required, and if ament isn't installed on the system CMake builds can still succeed, perhaps depending on a simple parameter or check for the presence of amant.

Thanks for considering this request!

[dirk-thomas]

Please describe the desired use case in more detail. Especially what are the goals and which parts can currently not yet be achieved.

[ahundt]

Example libraries are:

https://github.com/ahundt/grl https://github.com/jhu-cisst/cisst

One specific example from above is that I shouldn't need to write a hanky findros.cmake, ROS should provide standard cmake 3.x config.cmake script support where libraries install their own configuration tools. See cmake 3.x documentation for details, though note I believe 3.2 or higher is more ideal due to fixes of string handling and actual cmake code bugs in earlier 3.0 and 3.1.

I just chose them because I've done development for them. I'm specifically talking about the "ROS wrapper" case. http://wiki.ros.org/navigation/ROS_Wrappers

Essentially, I would like if there was a well thought through approach making it easy to put a ROS wrapper into libraries that don't use ROS now, without breaking existing use cases (in particular the build of libraries) when ROS is not available.

Also making the reverse easy is another specific case. I've encountered a number of libraries that really only use the catkin build system and no heavy ROS dependencies but untangling the cmake to build when ROS isn't present could be made much easier. Here are two specific libraries where that is the case:

https://gitlab.mech.kuleuven.be/rob-dsl/geometric-relations-semantics.git https://gitlab.mech.kuleuven.be/rob-dsl/pose_twist_graph.git

[wjwwood]

https://github.com/ahundt/grl

One specific example from above is that I shouldn't need to write a hanky findros.cmake

I assume you're talking about: https://github.com/ahundt/grl/blob/master/config/FindROS.cmake? (please link directly to files when you reference them so others don't have to go searching) If so, I'd say that file doesn't exactly make sense because ROS is not a single entity you can find_package and that is by design. Each ROS 1 package, that is a catkin package, exposes itself as a CMake project and provides a pkg-config file. The file you referenced isn't necessary as far as I can tell and would only work on Ubuntu and only if ROS was installed to /opt/ros. That is admittedly the most common case, but it is by far not the only way people use ROS.

If you were to source a the setup.bash file present in any of the /opt/ros/* folders then you would just be able to do things like find_package(roscpp REQUIRED) and target_link_libraries(roscpp_LIBRARIES). The setup file is required because we install to /opt to allow multiple versions to be installed at the same time more easily.

In the latest versions of Ubuntu and Debian, you don't even need to source the setup file for many things because there are ROS packages upstream which are installed to /usr. However, I'll caution you that those packages will conflict with the ones installed from our server (http://packages.ros.org/ros/ubuntu/) because of the version of some common dependencies which are out of our control, see: http://wiki.ros.org/UpstreamPackages Also the packages available in upstream will be older and there will be less of them, but it might meet your needs without having to worry about adding our repositories or sourcing our setup files.

You might want to have a look at https://github.com/gerkey/ros1_external_use and http://lists.ros.org/pipermail/ros-users/2016-February/069867.html for a simple example of how to use ROS as if it were a small collection of CMake projects, either using CMake or Make.

For ROS 2, this story doesn't change, because any ament package that uses CMake will provide a standard CMake <package>Config.cmake and <package>Config-version.cmake file (just like catkin and ROS 1).

Essentially, I would like if there was a well thought through approach making it easy to put a ROS wrapper into libraries that don't use ROS now, without breaking existing use cases (in particular the build of libraries) when ROS is not available.

I think it is a fair point that this is an under-advertised and under-documented use case, but it is completely possible as-is. Again, I think you'll find https://github.com/gerkey/ros1_external_use very insightful in that case. We're working on addressing this by improving documentation and polishing off rough edges.

Also making the reverse easy is another specific case. I've encountered a number of libraries that really only use the catkin build system and no heavy ROS dependencies but untangling the cmake to build when ROS isn't present could be made much easier. Here are two specific libraries where that is the case:

We encourage this, as you linked to http://wiki.ros.org/navigation/ROS_Wrappers. We have done this for many of the built-in robot capabilities for ROS. I think it's a hard case to make to grad students that aren't using their stuff outside of ROS and don't have time to worry about it otherwise. This is unfortunate, but it is relatively easy to convert from catkin to plain CMake if the package doesn't use ROS stuff. For example, my serial library is built with catkin: https://github.com/wjwwood/serial but it is totally trivial to convert it to CMake or embed it directly into another CMake project: https://github.com/wjwwood/serial/issues/52#issuecomment-28848337

Other examples where people have done "the right thing" and written a ROS agnostic library and wrapped it in ROS (or taken a ROS agnostic library and written a separate ROS wrapper rather than extend the library itself to optionally support ROS):

• (non-ROS and ROS packages)
• stage and stage_ros
• gazebo and gazebo_ros
• pcl and pcl_ros
• opencv and vision_opencv
• libsegwayrmp and segway_rmp (my packages)
• gmapping and slam_gmapping
• many others...

Also, we mention this as the preferred strategy in the wiki.

From http://wiki.ros.org/ROS/Introduction#Goals:

ROS-agnostic libraries: the preferred development model is to write ROS-agnostic libraries with clean functional interfaces.

Obviously not all of ROS hits the mark, but people are trying to do this when they can.

https://gitlab.mech.kuleuven.be/rob-dsl/geometric-relations-semantics.git https://gitlab.mech.kuleuven.be/rob-dsl/pose_twist_graph.git

Both of those libraries (at least on the default branch) are rosbuild packages, which has all but been replaced at this point. It was replaced in part because of the issues you're talking about, so you're preaching to the choir. So while I agree with you that those packages would be hard to integrate with, I don't think that using them as examples helps to support your case in this issue.

I appreciate your interest and feedback. However, I think this issue has been opened against the wrong repository as none of the things you linked to as examples are ROS 2 or ament packages. So without looking at ament you can't possibly know if the criticisms apply.

I'm going to close this since I do not believe there is anything that we need to do to satisfy the request in a technical sense. We're aware of the need for documentation of this kind of use of ROS, but we're not to that point with ROS 2 yet (we'll keep it in mind though). Feel free to continue to discuss here and we can reopen the issue if appropriate.

[ahundt]

Thanks for your consideration and listening to my feedback! What would be the right place to open issues with ROS 1 which should be considered in ROS 2?

[ahundt]

I will also definitely take a look at some of those examples you recommend. Is there a centralized location with "best of" (i.e. very good nontrivial full implementations of functionality that are recommended as a reference) and "best practice" information I can use as a reference and send to others?

[dirk-thomas]

For general ROS 2 related tickets which are not specific for a package please use https://github.com/ros2/ros2

The ros2 org unit contains two repositories with demos and examples. They will be a good starting point beside the tutorials in the wiki.