Good questions. Short term, I have two issues I’d like to solve: 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. 2) the ROS2 ecosystem lacks some features, particularly in libraries, that ROS1 has.
I don’t know what is the best and most realistic path to achieve them, but I personally think the long term goals are twofold:
-
Remember that this thread was started from a call-to-help for maintaining the core ROS1 libraries. In order for the shim to have any impact on that front, it must eventually be able to replace the ROS1 core library implementation with an implementation based on ROS2. This implementation must be able to mimic the behaviour of ROS1 to a very large degree in order to be an acceptable replacement. The users of the shim are those that want to or need to keep using ROS1, for whatever reason. Their node implementations don’t need to change, since the API is unchanged. Only then can maintenance of the current ROS1 implementation be dropped. Until it is complete, there is little benefit for “reduced maintenance effort”. I have no idea how realistic this is, but it is a big task that can probably not be called a short-term goal. However, if reducing ROS1 maintenance efforts is a goal, this has to be kept in mind.
-
Different from the first point is minimizing the migration effort to use ROS1 libraries in a ROS2 context. The bridge fulfills this need to some degree, but it seems people feel like it is not enough (I can’t comment on that). With ROS2 being largely incompatible, the fear of some people has been that the community is splitting between ROS1 and ROS2 with little synergies between them, and while OSRF is focusing most efforts on ROS2, ROS1 is left behind. Think of all the small libraries and nodes that are available in ROS1, but are very unlikely to be ported to native ROS2, since the effort of porting and maintaining two implementations is just too much. In ROS1 there was even talk of adopting a rolling-release model and there is a team of maintainers just for re-releasing working/useful packages, that are not even being re-released into the latest distro by themselves, so you cannot expect that anyone will re-write the majority of these packages for ROS2. Here the shim would allow these nodes to be compiled and used in a ROS2 context, without any or with very little code changes, while at the same time the same code-base continues to work with ROS1 (no matter if with the current ROS1 middleware, or with a ROS2-backed version). This way you would hope to channel maintenance efforts for both ROS1 and ROS2 to benefit each other, since they work on the same code base. Again, the semantics are tricky, since from the node’s perspective they has to be largely the same to ensure that it can work as it was written. At the same time you would like good interoperability with native ROS2 nodes, therefore some semantics will probably have to change in some respects when compiling for ROS2. This need will probably be hard to balance.
I don’t know how realistic either of the two goals really are, but if either or both are not even considered potential mid-/long-term goals, this should be stated from the beginning so expectations of where this is headed don’t get mixed up. If they are considered potential mid-/long-term goals, any short-term effort should ideally aligned with working towards them.