JEnoch (Julien Enoch):
The ROS2 daemon is only queried by the ROS2 cli tools. Regular ROS2 applications directly use their own ROS2 graph cache managed by rcl+rmw
This is not necessarily true. The daemon was mainly made for the CLI tools to keep them responsive and accurate, but other applications can use it if they want to. I think that rviz uses the daemon, actually.
What we are now considering is to allow the user to configure a zenoh bridge with a set of topics for which he wants the discovered entities to be propagated to a remote bridge. Receiving those discovery information, the remote bridge will create the corresponding DDS entities, allowing DDS advertisement and completion of the ROS2 graph by all ROS2 nodes.
Of course a user will be able to set "*" for this set of "propagated" topics, meaning that all DDS entities will be proactively created, but with consequences on discovery time and scalability.
I think this gives the best of both worlds. It allows us to fence of different sections of a widely-distributed application, while also allowing the dynamic nature of ROS to be maintained where it is needed. And for unknown system introspection,
* can be used.
Hi! We have been testing rmw_zenoh in the past week, and we were able to run a basic distributed application in the following setup:
ROS1 node -> ros1_bridge (with the ROS2 side running rmw_zenoh) -> Zenoh Router -> Android emulator -> ROS2 node (running with rmw_zenoh)
We are also looking at adding support for shared memory transport in rmw_zenoh (we got delayed this week by other projects). From what I have seen so far, I think that rmw_zenoh for ROS2 apps could provide a superior solution compared to using DDS on the ROS2 side and then bridging it over Zenoh. It just brings in unnecessary complexity, if the whole system could just run Zenoh as the ROS2 backend. Obviously, rmw_zenoh is not yet production ready, and as we discussed it here before, it might make sense to reimplement it in Rust instead of using the Zenoh-C binding, but in the long run this might become a better solution.
Hi zenohers and especially the ROS2 users!
I just merged a bunch of updates in the master branch of zenoh-plugin-dds. It now includes:
zenohdbinary). And you can deploy those routers wherever you want, as soon as they are interconnected.
@kydos Thanks for your reply. This feature is important for device discovery and identification. I'm looking forward for this feature release.
Absolutely, this is one of the reasons why we wanted all messages in our protocol to support user attachments. We are about to finalise the features list for June and July — we’ll try to squeeze this in June. BTW, once the API will expose this feature you’ll be able to attach properties to scout/hello, open as well as to data messages. We keep the working-feature-list on the [github wiki] (https://github.com/eclipse-zenoh/zenoh/wiki/2021). I’ll let you know once that is updated.
GetRequest::reply()as many time as you want.
Hi @gardenest ,
Yes, in your Eval function, you can call
GetRequest::reply()as many time as you want.
Just notice that if you send several replies with a same Path, the consolidation mode configured by default in the zenoh API will make that your requester will only receive 1 value per Path (the one with the mre recent timestamp). But I guess you probably want to send replies with different Paths, right ?
@JEnoch Actually I need one Path with multiple replies and client need to receive all replies, is that possible?
Yes, it is possible: currently the way for the requester to specify that he wants several replies for a same Path is to set the
starttime and/or the
stoptime as properties in the Selector.
That’s for instance used to query the InfluxDB backend. See example of use here:
Just know that the values of
stoptime properties are not interpreted by the zenoh infrastructure itself, but by the receiver of the GetRequest. I.e. the InfluxDB backend, or your Eval function in your case.
The InfluxDB backend, for instance, uses the values of
stoptime in the DB query it does to retrieve the time-serie to reply.
Your Eval function could interpret those
stoptime values in the way you want (or just ignore them). The only missing part we currently have is that in zenoh API, there is no way yet to specify a timestamp with the Value you replies. The timestamp is automatically generated by zenoh when replying, and it could therefore not match the time interval specified in the Selector.
But that might not be an issue for your use case if you don’t care about timestamps.