Discussion on ROS to ROS2 transition plan

[Dejan_Pangercic]

@Martin_Guenther

My hunch is that the ROS1 -> ROS2 conversion is more than just a few renames, so it’s hard to write a script that gets it right (but I could be wrong here). More importantly, when starting to switch over to ROS2, I would be willing to invest some effort into learning ROS2, and after that doing the conversion manually probably wouldn’t be more effort than running an imperfect script and fixing it up afterwards; especially since doing the renames is only 10% of the effort, the other 90% is debugging the subtle changes in behavior that @moritz mentioned. In contrast, any effort put into learning the pluginlib conversions is lost, because you only need that knowledge once. But if it’s easy to do, why not write a conversion script and see how well it works.

If you have been cleanly separating your ROS 1 code per 5Cs and want to end up with the same workarounds in your application code as Moritz mentions above, I think that scripting can actually take you really far.

If you want to make your product really right, then your hunch is correct. At the very end ROS 1 has some fundamental and software engineering issues that logistics and home robotics companies have been able to work around but developers in automotive, medical and aero space were not, because the requirements in the latter 3 domains are too stringent. ROS 2 however is suitable for the use in these domains.

I will try to explain in couple of points why I think so:

1. ROS 1 lacks quality of service (QoS) settings which ROS 2 now has. This is such a fundamental feature for especially multirobot setups on corporate WiFis that we had to do tons of work on top of ROS 1 sub/pub to mimic them. When porting to ROS 2, developers will actually have to sit down and think about how they want their communication between nodes, robots to look like. After they will think about it, the implementation will be super straight forward but still not search-replace like.
2. ROS 1 lacks managed nodes, lifecycle manager and heartbeat functionality. Again, we spent tons of work in the past to mimic this behaviour but at the best ended up with the hack. And you can not build a production system without these features. ROS 2 has rclcpp_lifecyle (managed node API), launch system that understands and can command managed nodes and will also have heartbeat. Here again, the design of a ROS 2 system will have to change a bit, e.g. you will have to think what to do in the init, configure and run state and when to go to and what to do in the failure state. However after you will figure this out you will be able to develop systems that are repeatable in behaviour and much more robust.
3. Security. I see that developers do not take this serious at all. But we will see robots be hacked in the future and there will be bad press for those robots where you can just simply do the following in your root shell “rostopic pub /control TwistCmd 5m/s”. ROS 2 offers security but again you have to consider which parts of your ROS system you wanna run as trusted and how much of overhead the security brings.
4. Large data support. I hear from many parties that TCPROS is not fast enough for them. And so many went ahead and implemented their own SHM transport in ROS 1 or used a different framework because ROS 1 does not provide SHM.
   At least 2 DDS providers (DDS is a middleware of choice in ROS 2) offer their own SHM transport.
5. Real-time and determinism. Below 3 talks go into details why making your system be real-time with ROS 1 is a hack. ROS 2 offers constructs such as separation of Nodes and Executors, Waitsets (in works), std::timed_mutex - cppreference.com, … which will allow for a synchronous flow of data but which also means that as well in this case you need to sit down and re-think your architecture.
   1. Ingo last year
   2. Brian
   3. Chris this year
6. …

In general I absolutely see the concern of a large code base being built on top of ROS 1 and I think that we should start carefully and openly planning which ROS packages are the most needed and get them ported to ROS 2 and give the community enough time to make a switch. For starters I think that these 2 lists offer a pretty good overview and I would suggest adding to them:

1. https://docs.google.com/spreadsheets/d/14GY9shcwa2QKnw5u5T7F_2-4XuuwLkS3W20-tVp8EOY/edit#gid=0

If this is not an acceptable solution, then the very next thing that comes to my mind is that we go and try to find money for additional OSRF people that will let them do continuous ROS 1 releases without impacting any ROS 2 work. Just my personal opinion but I think that it would also make sense that this money comes from parties that largely depend on ROS 1.

D.