ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS 2 Collaboration Bulletin Board

Hey, all!

I just ported (for the most part) the rplidar_ros node.

Tested and working!

Note: I have only ported the node, but the launch files shouldn’t be hard once I get around to it.

PS: I have also updated GMapping, and encourage you to rebuild if you’re using it.


Hi @bponsler Thanks for reply. we will be happy to contribute. We will start migration by forking and merging your work to new branch .

Hi @bponsler, We would like to contribute on dignostic_updater. We have tried build the diagnostic_updater exist code functionality and executed gtest (with some modification code for the same) for using colcon build tool for ROS2.
Here we have observed that code is depend on ros2_time pkg, so should we use ros2_time pkg and proceed or should we modified time/duration stuff based on master ros2 rclcpp time?

@Rohita83 - the use of ros2_time was done over a year ago when there wasn’t a solid solution for time. You should update the package to not require ros2_time and use some other method (I’m not sure what the best way is currently) which may be the rclcpp time. Also, it may be best to move questions like this to a different channel (github issues perhaps?) so we don’t spam this thread.

You may want to coordinate your work with Persistent Systems (see the post here: Diagnostic-aggregator and diagnostic-updater porting to ROS2) a they are also working on porting this package.

Thank you @Roser for porting cv_bridge to ROS2. This is helpful. Our team at Persistent System will contribute towards testing ROS2 ported cv_bridge package very soon and keep you posted on the outcome. Please let us know if anyone has any concern or any vital information that we will help us in this testing effort.

Thank you @HyphaROS for porting ydlidar to ROS2. This is helpful. Our team at Persistent System will contribute towards testing ROS2 ported ydlidar package very soon and keep you posted on the outcome. Please let us know if anyone has any concern or any vital information that we will help us in this testing effort. I see that you are the maintainer of this package in ROS, hence I’m tagging you here in this

@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 vision_msgs:

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.

1 Like

@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 ( and then merge your changes there. I had created an initial PR just for visibility ( but didn’t get a branch created. It will be easiest for others to find the port if it’s part of ros/diagnostics.

1 Like

@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.

  • laser_filters (by vandanamandlik
  • laser_proc
  • imu_pipeline
  • laser_pipeline

Hi all,
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 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, 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.