@prasenjitdan I see that you are starting to port a lot of packages. I think it would be good if, when you do so and when you have the extra resources, you consider how to improve those packages using new features and concepts of ROS 2, rather than just doing straight ports.
@prasenjitdan I also came here to comment about all the packages you’re going to convert to ROS2. First off: Thanks for doing that, it seems that ROS2 is really taking off now!
Are you planning on forking the existing ROS1 packages into separate repos for ROS2? If yes, I believe that would be a very bad idea. IMO, ROS2 versions of packages should remain in the same repo as the ROS1 version under a new branch called
ros2 or similar. For example, this is how it was done for
The reason why I believe this is important is that when you do a fork, the ROS1 and ROS2 versions will diverge over time. When they remain in the same repo, there is a higher chance of changes being backported between the versions. This is especially important for msg packages; we don’t want inconsistent definitions of msgs between ROS1 and ROS2!
As @prasenjitdan has mentioned our interest in porting perception_pcl to ROS2, we would like to go ahead with this contribution. Please let us know if there is any update/status on this library.
@gbiggs, Thanks for your feedback. While our immediate goal is to get all the critical packages into ROS2, we will continue to look into the possibility to improve them using new features and concepts in near term.
@Martin_Guenther, thanks for your kind words. We are very excited to be part of ROS2 initiative. Regarding, Forking new repo vs branching under existing repo, I completely agree that branching under ROS1 repo will be a better idea. I’ll work my team and provide them similar guidelines to follow. I really appreciate your feedback and guidelines here.
@bponsler and @Rohita83, Thanks for your communication around Diagnostic-aggregator and diagnostic-updater porting to ROS2. It is correct that we, at Persistent system are extending our help in porting these two packages to ROS2. Please let us know how can we collaborate our effort together to make it more effective without duplicating the effort.
@bponsler, We have cloned diagnostic_updater from ROS1 master (Indigo-devel) branch and merged your changes from bponsler:ros2-devel branch. Additionally we have updated some CPP code as per ROS2 guidelines to support ROS2 build and also execute gtest on ROS2 Bouncy.
@bponsler, @Austin Hendrix, @Brice Rebsamen, As diagnostics git repo is not available for ROS2, Would you please suggest us to whom we should raise PR for the same.
@Rohita83 - great, thanks for taking that over.
I think the correct thing to do is to have a ros2 devel branch created in ros/diagnostics (https://github.com/ros/diagnostics) and then merge your changes there. I had created an initial PR just for visibility (https://github.com/ros/diagnostics/pull/71) but didn’t get a branch created. It will be easiest for others to find the port if it’s part of ros/diagnostics.
@bponsler - Thanks for your response. definitely this information will help us to move ahead.
Hey, all, our team will plan to port below laser related packages for ros2 perception, if anyone started on these packages porting, please let us know.
We have successfully ported Diagnostic package ( Diagnostic aggregator, Updatar,common diagnostic, analysis and self test ) to ros2 and its working. Test cases pass !!!.
please find new pull request https://github.com/ros/diagnostics/pull/94 for updated code.
Diagnostic package is ready to use and any improvements are always welcome .
We have ported Bond-core (bondcpp) package to ROS2. It has been tested.
This package is ready to use. Please find pull request, https://github.com/ros/bond_core/pull/43 for code.
Suggestions and feedback are always welcome.
We have taken up laser_assembler and filters package for porting.
laser_filters package is dependent on filters package on which we are working currently.
Here is discourse link for laser_assembler and filters:
@vandanamandik, yes I see you have already started porting laster_assembler and laser_filters. We just planned and start to port others like laser_proc, laser_pipeline, image_pipeline from 2019 Jan.
@sandiprakhasiya Created request as below
@k-okada, Is there anyone working on porting opencv_apps to ROS2? If not, I would like to put the effort in porting it to ROS2. I have forked the project from https://github.com/ros-perception/opencv_apps. Let me know if you have any suggestion. Thanks.
So, having not undertaken any ROS2 porting myself, I have to ask - what’s the common (dare I say standard?) practice for repos/branches? Keep the same repo, and create a
ros2 branch? I know that upstream ROS2 repositories tend to follow the
master + distro branches approach.
Github being what it is, having two essentially ‘main’ branches (one for ROS1, one for ROS2) is suboptimal in terms of visibility and code search, however creating
ros2_* repos feels unpleasant as well.
For “core” ROS 2 repositories (rclcpp, rclpy, etc), we have a separate repository using the master branch for the most part. This makes sense since these repositories share no code with their ROS 1 counterparts.
Early on in the porting of some of the non-core repositories (pcl_conversions, depthimage_to_laserscan), we forked the repositories into the
ros2 organization and did the ports there. But creating separate repositories means it is harder to port changes across, so our recommendation for new ports has been to make a
ros2 branch on the upstream repository and do the port there.
We’d like to get to a place where you can host both the ROS 1 and ROS 2 ports of the code on the same branch, but I don’t think we have the documentation and/or pieces in place to do this quite yet. If someone is willing to work on this, though, it would be a great thing for the community to have.