On our testing machine (AMD Ryzen 7 5800X with 32 GB of RAM), the newly introduced experimental features for ultra low latency support reduce latency of ~30% as shown in the table below.
| Protocol | 5th Percentile | Median | 95th Percentile |
|---|---|---|---|
| P2P, Y LowLat, Pipe | 6.0 | 7.0 | 9.0 |
| P2P, N LowLat, TCP | 10.0 | 10.0 | 11.0 |
Clearly, this is a first step for Zenoh and more is to be expected in the future!
We are happy to announce that the ROS1 bridge, introduced in Zenoh Charmander, has been released! To better understand how the ROS1 bridge works, let’s recall that any ROS1 system is centralized and contains one ROS1 Master service and a set of services called ROS1 Nodes. Each Node is capable of publishing, subscribing or querying some topics. ROS Master aggregates information about Nodes and their topics and provides a nameservice for Nodes to help them discover each other and establish direct connections when necessary. Those direct connections are used by Nodes to transport the actual topic data.
Compared to the alpha version, we significantly improved algorithms that utilize ROS1 standard ROSXMLRPC APIs of ROS1 Master and Nodes to collect information on the local ROS1 system. This gives the bridge the capability to also preserve topic data types and md5 signatures. Now ROS1 Bridge carefully probes all entities of the local ROS1 system to keep the information up-to-date, trying to apply caching when possible to reduce the costs of its operation.
Another significant change is the new fine-grained bridging mode config. Now users can specify bridging policy (Auto\Lazy\Disabled) both globally and for specific ROS1 topics.
As a result, the bridge is capable to expose ROS1 topics for publishers, subscribers, services and clients into Zenoh network as a set of Zenoh publishers, subscribers, queryables and queries, providing ROS1 system all set of Zenoh features, like highly-efficient and flexible network operation, storage-based data caching, etc. Moreover, multiple ROS1 systems bridged into one Zenoh network are capable of seeing each other and interact seamlessly.
ROS1 to Zenog Bridge aims to be completely transparent, making interaction with remote ROS1 topics as if they were local. The integration to any existing ROS1 system does not require its tuning, recompilation etc (of course, if its application logic won’t get mad of seeing remote ROS1 topics in its environment :) ).
To test a new bridge, please try the following:
# To run this example, you should have ROS1 locally installed….
+On our testing machine (AMD Ryzen 7 5800X with 32 GB of RAM), the newly introduced experimental features for ultra low latency support reduce latency of ~30% as shown in the table below.
| Protocol | 5th Percentile | Median | 95th Percentile |
|---|---|---|---|
| P2P, Y LowLat, Pipe | 6.0 | 7.0 | 9.0 |
| P2P, N LowLat, TCP | 10.0 | 10.0 | 11.0 |
Clearly, this is a first step for Zenoh and more is to be expected in the future!
We are happy to announce that the ROS1 bridge, introduced in Zenoh Charmander, has been released! To better understand how the ROS1 bridge works, let’s recall that any ROS1 system is centralized and contains one ROS1 Master service and a set of services called ROS1 Nodes. Each Node is capable of publishing, subscribing or querying some topics. ROS Master aggregates information about Nodes and their topics and provides a nameservice for Nodes to help them discover each other and establish direct connections when necessary. Those direct connections are used by Nodes to transport the actual topic data.
Compared to the alpha version, we significantly improved algorithms that utilize ROS1 standard ROSXMLRPC APIs of ROS1 Master and Nodes to collect information on the local ROS1 system. This gives the bridge the capability to also preserve topic data types and md5 signatures. Now ROS1 Bridge carefully probes all entities of the local ROS1 system to keep the information up-to-date, trying to apply caching when possible to reduce the costs of its operation.
Another significant change is the new fine-grained bridging mode config. Now users can specify bridging policy (Auto\Lazy\Disabled) both globally and for specific ROS1 topics.
As a result, the bridge is capable to expose ROS1 topics for publishers, subscribers, services and clients into Zenoh network as a set of Zenoh publishers, subscribers, queryables and queries, providing ROS1 system all set of Zenoh features, like highly-efficient and flexible network operation, storage-based data caching, etc. Moreover, multiple ROS1 systems bridged into one Zenoh network are capable of seeing each other and interact seamlessly.
ROS1 to Zenoh Bridge aims to be completely transparent, making interaction with remote ROS1 topics as if they were local. The integration to any existing ROS1 system does not require its tuning, recompilation etc (of course, if its application logic won’t get mad of seeing remote ROS1 topics in its environment :) ).
To test a new bridge, please try the following:
# To run this example, you should have ROS1 locally installed….
# build the bridge from source
cargo build
cd target/debug/