ROS graph information tools implementation discussion

iluetkeb · 2016-10-20T08:45:26.373Z

I would check whether requiring a non-ROS (which, in this case I take to mean a non-DDS) interface is strictly necessary. Maybe we can avoid the discovery phase by other means, e.g. by pre-supplying the necessary information, assuming that the daemon runs locally (which other means would also have to assume).

My reason for that is to avoid duplicating communication code and functionality. While at first it might appear simple to open a TCP connection and exchange some data, you have to handle edge cases, like when the port is blocked by something else, or supporting in-process communication, and so on. I think the reliance on XML-RPC in ROS1 was a cause of complexity, and one of the advantages of using DDS is that we can avoid that.

It would still be possible, of course, to offer a non-ROS interface in addition, e.g. for use by web-based services. This would not necessarily have to run on every machine, however, but only when necessary.

iluetkeb · 2016-10-20T08:52:31.564Z

@dirk-thomas

Demand starting is a tricky business. I would prefer that, in the first instance, the launch procedure starts the daemon, the client implementations falls back to DDS discovery when the daemon is not present. Also, I would prefer that when demand-starting is implemented, we do this through a minimal daemon process which loads the “real” process upon first connection. This again keeps demand starting functionality out of the core libraries.

Regarding independence of the specific rmw implementation: The interface should be independent, but the internal implementation could be vendor-specific. Several DDS vendors offer this functionality already (including FastRTPS, as far as I can tell), and this would be very good to re-use. I would be worried that we’re inefficient otherwise, when we bypass the vendor.

gbiggs · 2016-10-20T23:50:17.647Z

iluetkeb:

I would check whether requiring a non-ROS (which, in this case I take to mean a non-DDS) interface is strictly necessary. Maybe we can avoid the discovery phase by other means, e.g. by pre-supplying the necessary information, assuming that the daemon runs locally (which other means would also have to assume).

So we’ve got a vote here for the ROS interface being the only interface.

I think it is reasonable to have the same information available over different interfaces. Certain tools (e.g. web-based tools) would benefit from not needing to use the DDS stack.

Which interfaces are required, and which interface is considered the “default” interface by tools, are the questions that we need to settle.

How fast a tool using a ROS topic can start up and get the information it wants is something I hope to test today.

iluetkeb:

My reason for that is to avoid duplicating communication code and functionality. While at first it might appear simple to open a TCP connection and exchange some data, you have to handle edge cases, like when the port is blocked by something else, or supporting in-process communication, and so on. I think the reliance on XML-RPC in ROS1 was a cause of complexity, and one of the advantages of using DDS is that we can avoid that.

I think this overstates the difficulty. If we implement using Python, as an example, there are good libraries available for providing web services, such as Django, CherryPy and several lower-level-but-still-abstracted libraries included in Python 3.

The counter-point there is that, like XML-RPC in ROS1, we would be increasing the number of dependencies if we use something like Django or CherryPi.

iluetkeb · 2016-10-21T07:30:41.196Z

@gbiggs

I think this overstates the difficulty.

I meant not just implementation difficulty, but also use-time complexity. While not entirely comparable, consider in ROS1, the use of XML-RPC was the root cause of all the mess with ROS_NAME/ROS_IP, and the various DNS resolution issues that led to. At least in my experience, lots of people struggled with that.

You’re taking in an entirely new communications stack, with all the side effects that has.

Sure, you can try and avoid that, for this special case, but that’s just why I’m suggesting that we investigate whether it’s really necessary first, instead of barging headlong into an implementation.

gbiggs · 2016-10-21T07:53:19.395Z

You are right about use-time difficulty; I hadn’t thought of that. The less that can go wrong, the better, from that perspective.

I agree that investigation is necessary. I originally envisioned the ROS tools like rostopic using the DDS stack to get the information, with the REST interface being a convenience thing for makers of tools that benefit from not using the whole ROS stack. @dirk-thomas would prefer it be the other way around, I think.

Anyway, I spent some time today hacking a wholely-unscientific benchmark into the add_two_ints_client example. Here are my results, based on 100 runs on a 2015 macbook pro (because for some reason alpha8 just point blank doesn’t run on my Ubuntu desktop and I haven’t had time to figure out why yet). Times are in seconds.

                         minimum   first quartile median    mean      third quartile  maximum
rclcpp::init             0.000041  0.000049       0.000051  0.000052  0.000053        0.000071
rclcpp:node::make_shared 0.005342  0.005714       0.005867  0.005948  0.006078        0.007536
node->create_client      0.005635  0.005979       0.006139  0.006234  0.006385        0.008588
make_shared request      0.005643  0.005987       0.006147  0.006243  0.006394        0.008600
wait_for_service         0.008758  0.009588       0.010619  0.030617  0.011594        1.011910
async_send_request       0.008900  0.009737       0.010776  0.030780  0.011735        1.012290
receive result           0.224500  0.232855       0.235795  0.251124  0.238558        1.015980
rcpcpp::shutdown         0.224662  0.233006       0.235900  0.251237  0.238677        1.016050

jfabry · 2016-10-21T14:36:13.214Z

I would like to second the argument of @iluetkeb about use-time complexity of multiple communication mechanisms, from a different point of view: I have a student working on developer understanding of ROS and the current variety of communication mechanisms, and the consensus about the persons being interviewed is that there are too many of them.

I am all in favor of keeping it simple, and implementation-wise, the original proposal using a daemon and the existing ROS communication mechanism looks very attractive to me. The daemon always runs and has the information available as a ROS service call, plus uses a topic to broadcast changes to the graph such that long-running tools are informed of this.

If later on it turns out that more is needed (e.g. REST API), this can simply be implemented as extra functionality on top of this layer.

dirk-thomas · 2016-10-21T14:51:05.535Z

I just want to reiterate: the reason why the current command line tools are slow is because they have to wait for the discovery phase to finish before they can query the desired information. The idea of the daemon is that it is already running before and it has already accumulated the information.

If the command line tool wants to use the ROS interface to request information from the daemon it again needs to wait for the discovery phase to finish before it can do so. It might only need to wait for the availability of that daemon but still this implies a significant overhead in waiting time for the user. I don’t think a command line tool (which e.g. is often also used for completion) can have that time penalty. While I am certainly not a big fan of having a different transport mechanism I don’t see how the requirement of the lowest latency possible can be fulfilled with using a distributed peer-to-peer system like DDS.

NikolausDemmel · 2016-10-21T15:05:15.334Z

I guess @iluetkeb point was to use DDS communication, but find a way to avoid the discovery phase in the specific case of connecting to the daemon. It seems to me that letting a tool like rostopic know how to directly connect to the daemon with DDS is not a much different problem from letting the tool know how to connect to the daemon through some other protocol.

iluetkeb · 2016-10-21T15:12:08.720Z

Thanks to @NikolausDemmel for making my point better than I did Yes, that is exactly what I was tryint to suggest.

if the command line tool wants to use the ROS interface to request
information from the daemon it again needs to wait for the discovery
phase to finish before it can do so.

Not necessarily. See http://eprosima-fast-rtps.readthedocs.io/en/latest/advanced.html#matching-endpoints-the-manual-way, for example.

dirk-thomas · 2016-10-21T15:20:52.163Z

This functionality would need to be exposed through the rmw interface in an abstract way. And it needs to be implementable with all current vendors. I am not sure that Connext / OpenSplice provide a similar API and if yes how their configuration option differ.

NikolausDemmel · 2016-10-22T10:21:28.989Z

FWIW, http://design.ros2.org/articles/discovery_and_negotiation.html talks about static vs dynamic discovery. The way I understood it static discovery is exactly what we are talking about here (just in this case specifically only for one connection, from tool --> daemon). Is static discovery not within the scope of ROS2? (I believe static discovery is relevant not only for this use case).

An additional advantage of relying on ROS2 communication is that other consumers of the same API that don’t necessarily worry about short start-up time will just as well work using dynamic discovery.

iluetkeb · 2016-10-22T15:05:11.879Z

As for the general question, maybe @Jaime_Martin_Losa could shed some light on this.

For RTI Conext, you can pre-supply discovery peers, at least.

See “add_peer” in https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/ConfigPeersListUsed_inDiscov.htm#discovery_507287096_336417 This seems to be a Conext-specific API.

CoreDX (which you don’t use, but just as another datapoint) goes even further and implements the whole daemon-based central discovery solution for you.

Therefore, it might actually make sense to provide the topic list (or something from which it can directly be derived) in the rmw API, and let the vendor-specific solution use the best vendor-specific approach for supplying it. We would then need to fall back to our own daemon only when necessary.

btw, in general this is not such an outlandish feature, and such an obvious optimization, that I would be very surprised if a vendor did not support some means of realizing it.

gbiggs · 2016-10-24T07:51:15.414Z

It isn’t necessarily an optimisation from the point of view of a lot of DDS use cases. The lack of need for a central discovery daemon was a major design goal in the way DDS works.

However, there are use cases where it is an optimisation, as you say. Perhaps using that optimisation, when it’s available, via rmw, and providing our own daemon as part of the rmw implementation when it’s not, is a valid implementation.

Thoughts on this approach?

Does anyone (@iluetkeb) have any data on which DDS implementations provide a list of available topics in near-instant time, and which do not? Remember that providing access to the list of topics seen by the participant since it started is not the same thing as what we need. We need something that accumulates the list of topics currently available, including those that the rostopic tool may not have seen itself, and can provide that list on demand. So far the CoreDX implementation that @iluetkeb mentioned sounds like it provides this functionality already, but I’m not aware of any others that do.

One of the reasons for choosing a well-known topic was so that discovery can be short-circuited in DDS implementations that support it.

Jaime_Martin_Losa · 2016-11-04T09:37:57.951Z

Hi guys,

On Fast RTPS you can listen to discovery data:

http://eprosima-fast-rtps.readthedocs.io/en/latest/advanced.html#subscribing-to-discovery-topics

Also, you can set the endpoints for discovery:

http://eprosima-fast-rtps.readthedocs.io/en/latest/pubsub.html#defining-input-and-output-channels

gbiggs · 2017-02-02T02:01:17.758Z

I started writing a prototype of the approach discussed in this thread. But then Work^tm had other ideas, as it so often seems to.

The code is up on Github. It’s nowhere near complete, but perhaps there is enough to see where I was going. It’s not just rostopic, it’s intended to be a complete set of command line tools for working with the ROS graph.

I still want to keep working on it myself, but I think progress would be faster as a group effort.

GitHub

gbiggs/ros2graphtools

Libraries and tools for introspecting the ROS 2 graph - gbiggs/ros2graphtools

Having said that, there has been activity recently on the ros2 github to implement a rosnode tool directly, so perhaps this work is moot.

karsten · 2017-02-03T01:07:00.309Z

@gbiggs: Are you referring to this [0] repo? If so, it’s true that we have two scripts, rosnode_list and rostopic_list, which however are not meant to be in any releasable or complete state. These are mainly the result of debugging tools needed during the current development on our side (they are neither built on the buildfarm nor listed in the repos file) . We are currently not actively working on implementing these tools, given the discussion of this thread and the remaining open questions.
We may add more scripts in that repository, which then can be helpful to others as well, we would though recommend not just yet open PRs against it.

[0] https://github.com/ros2/cli_tools

gbiggs · 2017-02-03T01:15:57.908Z

Yes, that’s the stuff I was talking about, @karsten. Thanks for explaining their purpose.

ross_2 · 2018-10-29T17:49:52.045Z

Hi all, I’d like to kick this thread back up.

Problem:

We are only able to access all nodes and all topics/types.
No equivalent rosnode info exists for ROS2 and these daemon’s are still not available.

Goal

Expose the node graph for gui and cli tools to show the user.
Expose the following per node via rcl API:

services
subscriptions
publications
actions

Solution

Regardless of the daemon or on-demand approach to accessing node graph details, exposing the node graph through the rcl layer for tools to use would be advantageous to developers.

These interfaces will be fulfilled via the Simple Discovery Protocol, which uses well-defined unicast and multicast ports for each participant to listen to meta-traffic.

Are there any objections to using SDP to discover the node graph?

dirk-thomas · 2018-10-29T18:19:31.589Z

ross_2:

… and these daemon’s are still not available.

What do you mean by “daemon” here?

ross_2:

Are there any objections to using SDP to discover the node graph?

I don’t see a need to introduce a secondary communication protocol. You should be able to retrieve the necessary from the underlying middleware. It will likely require to extend the rmw interface but each existing implementation should be able to provide the necessary information.

gbiggs · 2018-10-29T22:35:37.976Z

I agree with @dirk-thomas. The underlying middleware knows all that stuff already, and DDS has well-defined ports and a discovery protocol. I don’t see any advantage to using SDP, except as an alternative when DDS is not being used as the underlying middleware.