ROS1 shim library development proposal

[gbiggs]

I’d like to be clear on the goal here. Is it:

• to allow a ROS 1 node to run on top of the ROS 2 code base so that node can be used as-is for ever more?
• to allow a ROS 1 node and a ROS 2 node to interact?
• to allow a node to work seamlessly with pure ROS 1 or on top of the ROS 2 code base depending on how you compile it?
• to provide an easy path to gradually migrate a code base from ROS 1 to ROS 2?
• to make it easier to use legacy, unmaintained ROS 1 nodes without porting them?
• something else?
• all of the above?

To be honest I’m not entirely convinced that a shim would increase the speed or ease of adoption of ROS 2. Interoperation is already achieved using the bridge, and maintaining a ROS2-based implementation of ROS1 seems like adding a third thing to maintain without sufficient benefit. The only place I think the shim is a long-term benefit is using legacy ROS 1 code without needing to maintain the complete ROS 1 code base - and I’d still prefer that such code is ported instead.

Still, if it’s going to happen then I’d like to see it done right.

In general, I think it would be easier to take one API at a time and, using just the headers, provide alternative implementations that use ROS 2 facilities instead of the old ROS 1 facilities. In many places suitable defaults for ROS 2 parameters, such as QoS, need to be decided; they need to mimic as close as possible the ROS 1 behaviour.

@Ingo_Lutkebohle

For hacking the old codebase, we need a rosgraph replacement as well, to get the info about the system. It might be a good start to have a rosmaster node, maybe based on the ROS2 info server (not sure what that’s called right now). In a later step, we could replace the roscpp graph calls with queries of the rmw info directly. Or maybe it would be easier to do that right away, that would be something look at.

I think that providing a master implementation using a ROS 2 node works well. The graph info daemon in ROS 2 should provide the information that rosgraph needs.

@Ingo_Lutkebohle

rostime and rosconsole I would have to look at in l more detail.

Logging works a little differently in ROS 2 but the API is I think wrappable in rosconsole’s API. The functionality is close enough.

@Ingo_Lutkebohle

Parameters live in the node in ROS2, which is not a big issue in itself, but we would also need to provide the parameter node interface. Or we could support the old parameter server in the master, which would again be more backwards compatible but is a break from how ROS2, particularly its launch system does it

The ROS1 parameters API would need to be reimplemented to use the ROS2 parameter API but I don’t think that would be too difficult. The more difficult part is deciding how to provide the ROS1-style behaviour. I think it would be relatively trivial to recreate the parameter server using a ROS2 node and have the shimmed roscore launch that node instead of the old parameter server.

@Ingo_Lutkebohle

ROS2 node interfaces are required for full integration with ROS2. We have a port of the ROS2 lifecycle to ROS1 already, which could be used to build the lifecycle interface. Not sure about the rest.

A ROS 1 node doesn’t require a life cycle. This is starting to get into “turn ROS 1 nodes into ROS 2 nodes” territory, which means adding new APIs to ROS 1. I don’t think that is a useful goal. If someone wants their ROS 1 code to operate on top of the ROS 2 code base and benefit from all the useful features of ROS 2, they should port it to ROS 2. Otherwise the shim will contribute to keeping the community split across two separate APIs rather than on a path to eventually converging on ROS 2. The shim should be limited only to mimicing existing ROS 1 behaviour using ROS 2 as the underlying middleware.