Exposing ROS1 to Zenoh

[yellowhatter]

There is a task to support ROS1 in zenoh.

I have a plan to implement zenoh plugin working with ROS1 in the same manner as it was made in zenoh-dds plugin. Of course the details of realization are different, but from the outside the plugins would be similar. The plugin is in Rust, working as client from ROS1 side. I'm also aware of the details (ros1-ros2 message compatibility, some optimizations etc) and targeting to build a complete solution which will be able to provide ROS1<->ROS1 and ROS1<->ROS2 communication.

Why not replacing Master?
Because ROS1 Master is not involved in data exchange process, ROS1 peers do establish direct data connections (rostcp or rosudp protocol) between each other while Master works as some kind of Nameservice (xml-based protocol) providing peers with information on topics and info needed to establish direct data connection with peer ( == subscribe for the topic). For Zenoh there is no use of reimplementing Master (as it won't give us optimizations on data transfer) - it is enough to create a special client based on ROS1 Client Library.
ROS1 Client Library has enough functionality (it implements rostcp/rosudp for data exchange and also xml-based protocol for Master) and there is no need to reimplement and support ROS1 protocol stack on our side - we could just use this library to do the trick.

Some optimizations could be made
There are currently some ideas on optimizations:

1. Convert ROSx to ROSy data on receipt side as the default behavior. When publishing data, the ROSx Publisher doesn't know whether it's data will be consumed by somebody expecting ROSy or not, thus there is no need to waste CPU cycles on converting it on publisher's side. ROSx publisher will simply publish the data marking it has "ROSx" format, and the subscriber could perform conversion to ROSy if needed.
2. Select publishing format by config. For the previous case, if there are some special needs, the publisher could be forced to convert the data to ROSy format by configuration. That could be useful in many cases (if many subscribers expect ROSy format or there is no CPU on subscriber's side to perform the convertion, etc).
3. Subscribe on ROS1-Zenoh layer only on needed topics. The topic list to subscribe to could be determined automatically.

[yellowhatter]

Regarding the ROS1 bindings in the plugin.

After investigation, I see two worthy ways how to do that:

roscpp - ROS1 official C++ client library.
Strong sides:

• Official and supported
• Stable and widely-used
• Performant

Weak sides:

• Requires wrapping in C to use with Rust in plugin + problems with integration in buildsystem

rosrust - unofficial Rust implementation
Strong sides:

• written in Rust, so no bindings or wrapping needed, no additional work with buildsystem etc

Weak sides:

• Unofficial 0.9.1 release, but seems to be supported and API is claimed to be almost stable

[Mallets]

I would go for rosrust library. It seems to be widely used already and it is nicer for us to have a Rust library.

[yellowhatter]

While writing an automatic mapping for ROS publishers and subscribers, I found the problem of "loop".

The main idea of automatic mapping is the following: the Bridge listens to ROS1 Master and gets lists of ROS1 publishers and subscribers. Than, based on this list, Bridge creates complementary Zenoh publishers and subscribers. On this stage, if on the ROS side contains both pub and sub for the same topic, there would be both pub and sub created on Zenoh side - and that causes a loop, because any message published on ROS side will go to Zenoh pub and than enter Zenoh sub, go back to ROS, etc....

[JEnoch]

In zenoh-plugin-dds this issue is solved declaring Zenoh subscribers with .allowed_origin(Locality::Remote). Thus, they receive only publications from remote publishers, and not from co-localized ones.