Discussion on ROS to ROS2 transition plan

[Hugo]

@Dejan_Pangercic

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), https://en.cppreference.com/w/cpp/thread/timed_mutex , … 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.

Regarding your points:

1. I think most people using ROS1 don’t really care, they just want it to work, which for the most part it does. I mean just look how everyone is polling for input at arbitrary intervals, as long as it works somehow people are happy.
2. Same concern as above, I think most people don’t care and forcing them to think about lifecycles is not going to help the transition. Maybe this is optional, haven’t looked into it too much, if it is then disregard the comment.
3. Fair point, as long as it’s optional, no complaints here.
4. Based on my experience with RTI DDS it is quite a bit slower than TCPROS, unless you are sending binary blobs, which is what the official RTI performance benchmark is doing to show good numbers. In any case if you want to send/receive messages larger than 64K you need to adjust a lot of QoS settings behind the scenes and prepare for high memory consumption (I’ve seen it use ~10GB before with complex and nested data structures).
5. What do you do if a node sends a request to another node which happens to run in the same Executor and thus on the same thread? Allowing the grouping of multiple nodes inside a single thread will open up the possibility of dead-locks. And again forcing people to sit down will make them re-think twice about moving to ROS2.