|
||
The stretch goals for Beta 1 (due in mid-December) include rostopic. rostopic is a faily vital tool when developing with ROS, and is probably one of the most-used tools in the ROS-based robot developer's toolkit. However, there are some challenges in developing rostopic for ROS 2, particularly the In ROS 1, rostopic can easily go off and get the list of known topics from the master, because the master Knows All. This approach is not so straight forward in ROS 2. The use of distributed discovery in DDS means that, by default, no one knows for certain the entire state of the DDS network. Furthermore, when a new participant starts up, it has absolutely no knowledge of the state of the network (beyond what may be hard-coded in) and has to wait for the discovery process to being producing results. This process may be very quick for things on the local machine, but for remote computers it is likely to take a significant time. If we implement The purpose of this topic is to decide how to implement rostopic such that it provides the same rapid response as ROS 1, while dealing with the distributed nature of the graph in ROS2, and with as complete information as possible given the limitations of distributed discovery. To get right into it, my proposal is:
The daemon mentioned above could be easily extended to also provide information for rosnode, rosservice, and similar commands. If we use the above approach, I would like to fix the ROS topics provided by the deamon as well as any other protocol interfaces/ports, and data formats (e.g. YAML) so that they are useful by other tools and tool implementors, such as rviz and rqt_graph. There has also been work done on rostopic and friends by the fine folks at Erle Robotics: Issue: ros_comm dev. support
opened by vmayoral
on 2016-02-23
Hello, We recently have been using ROS2 actively and look forward to its adoption. Our results are promising however we've reached a...
ready
Their implementation I think uses a listener waiting for information to pour in on a specific topic. However rather than trying to summarise their work myself, it would be great if @vmayoral could drop by and give us a description himself. |
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
|
||
Hey @gbiggs, Totally agree with your reasoning above. Good hearing that there's someone else interested on this :). The issue you pointed out above summarizes our work pretty nicely I believe. We had an initial (more complex) implementation for OpenSplice and then switched to FastRTPS. As for now, we've got simple Motivated by your comments I just went ahead and submitted a set of pull requests to integrate the changes needed upstream. Here they are: @marguedas, i think you'll be interested in this. |
|
||
A dedicated information service seems to be a good approach, and I'm not overly worried about introducing a point of failure there. However, when googling for this, some patents pooped up! Checkout https://www.google.ch/patents/US20150055509 and https://www.google.ch/patents/US20110258313 They are not exact matches, but particularly "network assisted peer discovery" is pretty close. btw, from the first patent, you can find a number of other patents related to DDS. I know this is tangential to your question, but it has me a bit worried here. |
|
||
![]() |
|
@gbiggs, the current proposal from our side (shared in the PRs above) uses the FastRTPS primitives to inspect the existing DDS participants/topics and report those using the ROS tooling. This simple approach did the job for us but we understand that a more generic and DDS-vendor agnostic layer might be put in place at some point. Hope that helped clarifying our approach. |
|
||
I am very interested in this discussion, as we at ASI have been playing around with ROS2 a lot. We had implemented our own version of We haven't had the time to really dig into the rcl and rmw layers to understand fully what's going on, but using this call has worked out fairly well. I will attest to @gbiggs statement that using this call comes at the cost of time. We have to let the tool spin for many seconds (currently around 15 seconds) just to be sure we've collected info from everyone in the system. Pretty inconvenient from a timing perspective, but still better than nothing! Also, I've noticed a new flaw in this approach which I think may be related to my previous discussion here. When we set the Participant Index for OpenSplice to 'none' I think it's causing the get_topic_names_and_types() to come up empty-handed. Or at least, it's coming up empty in a sporadic way. I still have to investigate that some more. |
|
||
As an aside, we've also got a rostopic echo working on most basic messages. It's a simple python hack-fest where we have a python script that does:
This has helped tremendously, even as hacky as it is. I could post the code if anyone thinks it'll be useful. |
|
||
I think the idea of a daemon process to optionally provide the requested information faster is a good approach I would like to comment on several aspects mentioned in the thread:
|
|
||
Non-Roboticist outsider looking in. Service Discovery in a distributed environment while not necessarily a solved problem has many implementations currently in use in production in a variety of companies and deployments. Of the top of my head I'm thinking about EtcD and Consul. Has anything like that been considered? |
|
||
Glad to see that many people manifested interest in this discussion. Thanks @gbiggs for this great summary. A couple notes / open questions on top of what has been stated:
|
|
||
![]() |
|
Thanks for enumerating those. I agree whole-heartedly with all of them. (Especially the last! I implement my tools like that and it's been very useful.) ![]() |
|
I strongly support having a non-ROS based interface. You've listed the advantages already. However perhaps it could be useful to have a ROS-based interface in case someone wants to use the functionality from a node? Perhaps this should be a lower-priority feature unless we find an actual use case for it. ![]() |
|
Yes, there are several ways that this could go. I think that if we use an environment variable that we can build an automatic mechanism without too much trouble. For example, the rostopic tool/library could look for an environment variable defining the graph information daemon's address, and if it isn't defined attempt to contact one on the local machine. If that doesn't work then it could request the daemon be launched on the local machine. ![]() |
|
Absolutely agree. This is another benefit of hiding it behind a well-known service description, I think: It becomes easier to abstract away the implementation. Then we can look into using existing technologies such as those @Barrett_Strausser mentioned and see if they do what we need already. ![]() |
|
I'm in favour of a REST service as the initial goal. I've also been told by someone locally who does a lot of tool implementations, using the browser as an interface, that he wants "everything" to be available over REST. I'm assuming he's talking about introspection facilities, not absolutely everything. However, I think the information should be available on other protocols from the same daemon if someone wants it that way. If we specify the data structure and the protocol used to access it separately then it should be relatively easy to add additional access methods. ![]() |
|
Being able to configure which domains the daemon aggregates data for, and run different daemons for different domains, sounds like a sensible use case. Especially with the potential for using domains for security zone partitioning. |