Syncronized callbacks in ROS2

REP 149 addresses the blocker of package manifests being able to declare separate ROS 1 and ROS 2 dependencies.

From a technical point of view it is then possible to have a ROS package using a single branch. The CMake logic can be made conditional based on the ROS version (the ROS 1 part using catkin, the ROS 2 part using ament). And the source code needs to distinguish between the ROS versions using whatever approach preferred (based on preprocessor definitions and/or conditional includes in C++, conditional imports in Python).

Of course anything which reduces differences between the ROS versions makes this more convenient and requires less conditional logic, e.g. typedefs, API shims, etc. On the other hand if a ROS package would like to use features from ROS 2 which aren’t available in ROS 1 (e.g. multiple nodes in a single executable) than the code will need to be different for that.

1 Like

I like to see ament support in ROS 1.

In code I have seen, that could significantly reduce the diffs. For example, consider the diffs between the master and ros2 branches of the simple unique_identifier packages.

I agree with you that this would be great to have. But supporting ament in ROS 1 implies a tremendous effort which we are not sure atm we can and want to spend. There is no technical reason not to do it - only a problem of available resource. This “feature” could also be contributed by the community which makes it less “necessary” that OSRF is spending its sparse resources on.

As mentioned above with REP 149 implemented you should be able to avoid that part of the diff and maintain the CMake code on a single branch. The CMake would have two sections - one using catkin and one using ament. You can use common programming language feature to try to deduplicate e.g the list of source files, targets, etc.

This is off-topic, but: I haven’t been paying attention to ament too much. Could you briefly describe what would be needed to get it to work with ROS1 (ie: what would the “tremendous effort” entail exactly)?

Beside releasing the packages into ROS 1 the build tools will likely need to be updated to support the way ament_cmake generates the package specific setup files. That should be not too much effort though.

I am mostly referring to writing documentation, updating tutorials, writing a migration guide for ROS 1, etc. That effort will in my opinion exceed any “programming” part by a lot.

I am mostly referring to writing documentation, updating tutorials, writing a migration guide for ROS 1, etc. That effort will in my opinion exceed any “programming” part by a lot.

If we had a working ROS 1 version to try out, I believe the community would probably help with those kinds of documentation.

I’m actually a big proponent of the idea to backport ament to ROS 1 (and maybe even some ament features to catkin), because I think it lets people take a step toward ROS 2 without jumping in with both feet while simultaneously gaining some benefits (assumption is ament is better than catkin, which I do believe). Also, it lets developers more easily support ROS 1 and ROS 2 at the same time (same branch). This is especially attractive for packages which are mostly ROS agnostic, e.g. class_loader or the new rviz_rendering package.

I don’t want to hijack the thread, but just to expand on what @dirk-thomas said, I collected a list of things that would need to be addressed a while back:

  • support building packages with the build_type of ament_cmake (catkin_make_isolated and catkin_tools)
    • make the setup.*sh files (which are installed to the install folder’s root) source both catkin and ament setup files and environment hooks (currently only handles catkin stuff)
    • address conflicts which may occur when ament_cmake uses Python3, but the ROS 1 packages and the build tool in ROS 1 (catkin_make_isolated or catkin_tools) uses Python2
  • release all packages in the ament/ament_cmake, ament/ament_lint, and possibly ament/ament_index repositories
  • deal with ROS_PACKAGE_PATH versus ament_index
  • consolidate ros-infrastructure/catkin_pkg and ament/ament_package
    • not strictly needed, but would prevent us from having two implementations of package.xml parsing
  • deal with any issue that arise and update documentation so people are aware of the changes
1 Like

Dirk, I am not sure I understand your point. So, if I’d like port message_filter which is originally in https://github.com/ros/ros_comm, you mean create a ros2 branch in ros_comm or create a directory under an existing ROS2 repo such as rclutils?

Actually, ros_comm ROS package include some other stuffs, e.g client libraries and introspect tools which were already into ROS2, under different repos. However , message_filter which is under ros_comm/message_filter have not ported yet. Can you point the direction more clearly how to port message_filter from ros_comm/message_filter to ros2, which repo should it stay? thanks.

@jwang11 message_filters is certainly not a simple case for migration. The location in ros_comm with the various other packages makes it more challenging to maintain a ros2 branch. A separation of that repository into smaller repo is certainly desired but would require a significant amount of effort.

Currently a separate branch or fork is required since we can’t support both ROS versions from a single code base yet. In the (near) future the goal is to make that possible though. As soon as that is the case I would prefer to merge any ROS 2 specific patches directly into the default branch and aim to minimize conditional code as much as possible.

1 Like

@dirk-thomas yes, location of message_filter make it a challenging case for migration. As you said, split it out from ros_comm and into a small repo require significant effort, so you prefer to separate a branch/fork on ros_comm, right? In new branch, I try make message_filter support both ros version with some conditional code? how I handle other packages, keep them intact?

I don’t think this is a good path forward. Simply because significant parts of the repo would be irrelevant for ROS 2 which would make synchronizing the diverging branches more and more effort.

I don’t have a good general recommendation for you at the moment.

@dirk-thomas Ok, I’ll split message_filter from ros_comm, and into a local ROS2 repo. Although it may need quite a lot effort, it is worthwhile.

It seems someone has started to port this at some point in the past.

It is still catkin version, not completed

Hi,

I found this link while searching for porting message_filters package in ros 2 environment. Can anyone update on the status of the porting work ? I would be happy to take up this job.

Hi, for my ros2 message_filters progress, it is workable and pass all unittest now, but there are still some follow-up work ongoing, e.g. de-boost and more testing. I plan open source it in 2-3 weeks.

1 Like

The code is ready at https://github.com/intel/ros2_message_filters.

Thank you very much @testkit. I will have a look at your code and get back to you.

Hi, is there any update on this porting?
It would be really useful!

Please see GitHub - ros2/message_filters for the current state as well as ongoing work.