For message_filters, I have completed functional porting from ROS to ROS2, and pass the unit test. Currently, I am working on drop boost dependency, which can expect done in 2 weeks. Then I’ll open source code ASAP.
@jwang11 I just started to take a look at message_filters for ROS2 yesterday, and it sounds like you may have made more progress. If you could open your code sooner, I have some time available to help collaborate and get this effort done sooner.
Hi, has anyone started porting gazebo_ros_pkgs?
@mjcarroll @sagniknitr Now we’ve already open the code of ros2 message filters and we now host it here: ros2_message_filters , please check there and help submit/fix issues, and we may move it to host underneath ros2 officially later when everything is ready, thanks !
The ROS team didnt start work in that direction so far. Porting it would be very beneficial to the community We encourage potential contributors to open an issue on the upstream repository to start the porting discussion with the current maintainers. The ROS team can pitch in to give additional context or direction if needed.
I will start to work on QtQuick support for RViz soon: https://github.com/ros2/rviz/issues/268
Please take a look at QtQuick support for RViz to build fancy HMIs for an explanation why that is a good idea.
I have successfully ported and tested following packages into ROS 2 version (ardent):
slam_karto: (it actually merges with open_karto pkg)
sparse_bundle_adjustment: (needed for slam_karto)
ydlidar: (a low cost 2D lidar provided by EAI)
For someone who wants to test these pkgs on turtlebot 2, I also provide a simple ros2 launch file:
About slam_karto ros2 pkg, I am working on removing it’s Boost dependencies.
Please let me know if you find any problems, thanks!
Hey all! Just to let people know, I’ve started porting turtlebot (the 2010 model – turtlebot2 is already ported, of course) to ROS 2.
For the record, things are very incomplete at the moment, but figured I’d post a link here (so I don’t forget to finish the port).
If no one started porting image_pipeline, I would try to port it on ROS2 from this week.
We are interested to contribute on dignostic_aggregator, So just we want to know about your status on this package . I haven’t seen any recent update on this git, so please let us know weather you are planning to complete migration ?
Hi @vaibhavbhadade - unfortunately I no longer have time to work on that any longer and would love for someone to take it up and complete it either by merging PRs to my branch or forking. Ideally, this would get pushed back to the main diagnostics repo so it can be more easily located by others. Let me know if you have any questions.
I just ported (for the most part) the
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.
@email@example.com 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
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!