ROS1 shim library development proposal

[gbiggs]

@Ingo_Lutkebohle

1. The ROS1 middleware has no security, and is therefore problematic in products. Many other issues I can address on a per-node basis, but security is reallu pervasive.

I definitely agree that this is a limitation with an outsized influence. However, I’m interested to hear what you think about why SROS is not sufficient. (I have my own opinions, but I’m not a security expert and want to hear yours.)

@Ingo_Lutkebohle

2. the ROS2 ecosystem lacks some features, particularly in libraries, that ROS1 has.

I also agree that many libraries are lacking. It would be nice to see things like MoveIt come to ROS2 rapidly, and as a major library it might do, but there are lots of small libraries that are also useful and are less likely to be ported soon.

@Ingo_Lutkebohle

The bridge is problematic in this respect, mostly because of tooling.

What sort of tooling is the bridge a problem for?

@Ingo_Lutkebohle

So, I would describe the goal as being able to use a ROS1-API-based node implementation in a ROS2 system as seamlessly as possible, including launching it using launch, etc.

“Launching it using launch” could imply many things, from ros2 launch mimicking the simple process starting of roslaunch to having a ROS1 node appear to be and behave as a native ROS2 node. I don’t see a problem with the former, but I feel that the latter is going beyond what is necessary. I feel that if a node needs to behave indistinguishably from a ROS 2 node, it should be ported.

@Ingo_Lutkebohle

One general comment here: When discussing porting, please do not forget QA. QA for a product is quite different from what many in academia are used to. Porting a full product in one big effort is essentially a no-go, particularly, but not only, for the many applications where only a small number of units are ever sold.

Thus, a shim that starts from the existing ROS1 libs and their semantics stands a much better chance than reimplementing these APIs based on ROS2. Changing the middleware is enough of an issue as a first step. We can then gradually replace more over time, once we have a better idea of the QA issues.

I understand the QA concerns of industry. However I disagree that a shim that “starts from the existing ROS1 libs and their semantics stands a much better chance than reimplementing these APIs based on ROS2”. By replacing the underlying framework with ROS 2 you are making major changes in the behaviour of the node. It’s not just a matter of swapping out the communications middleware, you are also suggesting things like changing the behaviour of a node to meet the ROS 2 semantics via the shim. Interoperation via having the same middleware is one thing, but behaving like a ROS 2 node, which is what is implied by “being able to use a ROS1-API-based node implementation in a ROS2 system as seamlessly as possible” involves major changes in the behaviour of the node even though the node’s source itself has not changed. Changes range from how parameters are delivered to how execution of the node is managed. I think the QA effort involved would be less, but not significantly so.

Nevertheless, I do agree that even if QA is not reduced then re-implementation time is reduced by having a simple shim that provides some level of interoperability between a ROS 1 system and a ROS 2 system without using a bridge, which is a benefit. I just disagree on how far the shim needs to go.