I’ve written the response below to answer questions posed over the past few weeks about who I am and why we are trying to help port packages from ROS1 to ROS2.
Persistent Systems (BSE & NSE: PERSISTENT) is a global leader in Technology Services. We build software that drives the business of our customers’ business; enterprises and software product companies with software at the core of their digital transformation. We have a global presence in 15+ countries, 9000+ Employees, 25+ years building software-driven business. Our FY2017-18 revenue was USD 470.55 Million. For more information, please visit www.persistent.com.
Persistent Systems has been funded internally and externally to build out our Robotics expertise and we have formed an initial engineering team focused on ROS development. We will be developing software for our internal projects and for our customers around the globe that will leverage ROS as a foundation, so we have a sincere interest in improving ROS and contributing to the advancement of ROS2. At this time, we have on-boarded an initial team of software engineers to work on this project, initially porting packages from ROS1 to ROS2, and we are committed to investing time and effort to contribute to ROS2.
Regarding package selection and maintenance, we selected the top 40 most commonly used packages. Our initial thought was that we would help people migrate packages that they were maintaining on ROS1 and wanted to have available on ROS2 but didn’t have the bandwidth to port themselves. We assumed the owners would accept the help if we submitted the pull request. I was reaching out to the community at large only because we didn’t want to duplicate any other ongoing porting efforts – if anyone has a suggestion to improve this, please let me know. We are available to help answer questions in the community after these packages have been ported, as the original maintainer sees fit.
Our team is learning here and we welcome your feedback as we engage with the community. Please let me know if you have any questions.
Regards,
Prasenjit Dan
Call : (+1)-714-902-3074
Program Manager
I applaud your willingness to put such a large quantity of resources into helping push ROS2 along.
I think there are a couple of things you should consider in your plan:
Porting a package from ROS1 to ROS2 is an ideal opportunity to revise the implementation in major ways. You should coordinate with the package’s developers to make sure you are not rushing ahead with just making it work in ROS2 and removing that chance from them in case they have plans.
Just plain making a package work in ROS2 is useful, but you should do more than just port. You should take advantage of as much of the new capabilities allowed by ROS2 as possible. This means things like restructuring the design of nodes to be composable, taking advantage of QoS and deciding the best default QoS for each topic, using local parameters, and using read only parameters where it makes sense (when they become available). Once code is available working in ROS2 I think it is less likely that such restructuring will be done, so doing it as part of the porting process is valuable.
Make sure the maintainer of the package is willing to also maintain and make ROS2 releases. If the maintainer is only interested in releasing for ROS1, then a ROS2 branch may get neglected.
If you port an unmaintained package, you should be willing to take on maintainer responsibilities and do the releases for that package. (This would be a great thing to help with, by the way.)
As you do your work, also keep an eye out for things to improve in the core libraries. Then post issues for them. Or, even better, make those improvements and post pull requests. It sounds like you have a lot of resources and devoting some of them to helping with ROS2 feature development would be much loved, I think.
Consider giving some resources to porting tools to ROS2. As valuable as nodes are, tools are far more so.
This is so important, it cannot be stated often enough.
As nice as plain ports are, they will never be what the pkgs could be if they were only conceptually ported instead of s|#include <ros/ros.h>|#include <ros2/ros2.h>|g (I know that doesn’t work that way … if only), and when there is a plain port, there will be much less of an incentive to do anything about the ported pkg as it’s there and it works … well enough.
All the GUI tools, especially the ros QT tools, are very useful. Each one is small but they all combine to provide a powerful toolchain. Even the robot monitor GUI tool is massively useful.
Just plain making a package work in ROS2 is useful, but you should do more than just port. You should take advantage of as much of the new capabilities allowed by ROS2 as possible. This means things like restructuring the design of nodes to be composable, taking advantage of QoS and deciding the best default QoS for each topic, using local parameters, and using read only parameters where it makes sense (when they become available). Once code is available working in ROS2 I think it is less likely that such restructuring will be done, so doing it as part of the porting process is valuable.
On the one hand, I agree. This is a great opportunity to do a lot of refactoring and optimization that is now possible thanks to the features of ROS2. On the other hand, I am strongly in favor of incremental development. You’re almost suggesting to go for a re-implementation, meaning big steps, premature optimization, the introduction of new bugs and changes in behavior. This makes the step towards ROS2 bigger instead of smaller. Also, I think we should trust the community to contribute to the restructuring of nodes, especially after many people moved to ROS2. JMHO
Completely agreed, This is absolutely our way of thinking as well. ROS1 to ROS2 is a significant step and I appreciate everyone’s way of thinking. We are also looking back on capacity. We arefocusing on what we can contribute that will be extremely valuable to the community, and incremental development or rather incremental steps are our key focus at this time.