Visualisation tools for capabilities and capability server

[bit-pirate]

TODO

• [x] Agree on the features we want to visualise
• [x] Create an rQt-based visualisation tool

[bit-pirate]

I envision a combined app manager/capability introspection tool with the following features:

• Master chooser: Specify the URL of the master running the app manager & capability server to retrospect
• The app manager view contains information about:
  • The list of all available apps with three statuses: not runnable (due to missing capabilitie; greyed out), runnable (but not running, black), running (green). We may want to extend it with installable, installed etc.
  • Details about each app, including name, description, required/preferred/optional capabilities
  • A start/stop button to trigger the launch/kill of apps, including a status field showing for example, that the app manager successfully checked for required capabilities
• The capability server view contains information about:
  • Details on all available capabilities (name, interface (topics, services, actions), config (parameters))
  • A run-time graph showing the running capabilities, capability providers and the dependencies among them
  • similar to the graph in the capabilities design doc: [1]
  • Buttons to start/stop capabilities manually

If we decided to include an app manager interface, we should sync with the ROCON rqt plugins devs in order to design reusable components, e.g. they also plan to implement tools for starting/stopping rapps.

[bit-pirate]

https://github.com/robotics-in-concert/rocon_rqt_plugins/issues/7

[wjwwood]

There is only one thing I see as being an issue here, and that has to do with the availability of the spec files. If you call the ROS service /get_interfaces on the capability_server, it will return a list of strings which are the names of the capabilities registered there. This does not give the service caller any other information about this Capability Interface, like what it defines, or what its description is. It doesn't even given the package it is located in. So the tool which gets this information (the capability name), has two options for getting more information about the capability:

• Have the same packages locally and use the python API to find the capability interface of the same name
• Have the capability_server provide a ROS interface by which the tool can query for all of the required information

The former is more like what we have with topics, we declare a type by name and each side has to have a copy of the message. If the two copies don't match then there is an error. The latter is more sophisticated, but maybe it makes it easier for a user to introspect a system without having the required packages locally, at the cost of increased complexity.

[bit-pirate]

Hmm, I already envisioned the capabilities being defined in a way similar to ROS messages, but I'm curious about other ways, too. What is that extra information a user could get, if we implement this special query tool? Could you give me an example?

[wjwwood]

Nothing you can't already get if you have a local copy of the spec file. Honestly I would first approach this problem by sending the whole spec file text over a topic/service and parsing it with the existing API on the other side. So it would be exactly the same except you lose which package each spec came from.

[bit-pirate]

except you lose which package each spec came from.

What is not a problem, since it's the capability servers tasks to start/stop the capability.

I'm fine with your suggestion. Is there anything else we need to discuss at this point before you can start implementing this visualisation tool?

[wjwwood]

I don't think so, I am going to write a standalone capabilities tool, and strive to make the components in that reusable so that they can be used in the app manager gui too.

[bit-pirate]

+1

I just added add the request for a stand-alone app manager widget to the rocon_rqt_plugins issues: https://github.com/robotics-in-concert/rocon_rqt_plugins/issues/10

[wjwwood]

I am developing it here:

https://github.com/osrf/rqt_capabilities

[wjwwood]

I have the basic visualization implemented, but I still need to add starting and stopping the capabilities remotely.

[wjwwood]

[bit-pirate]

Nice! Looking forward to test-drive this.

[bit-pirate]

Tested. Looking good.

[wjwwood]

Yeah, I have a prototype with remote starting/stopping and which shows the default parameter. I need to clean it up and make a pull request for it. I have been distracted by rostests for the main capabilities package today.

[wjwwood]

I have been thinking about different ways of visualizing this information, I mocked up some things real quick, does anyone have any preferences:

There are three different examples, left to right, and two different ways of visualizing the same data, above and below the solid black line.

EDIT: I fixed the direction of the default arrows

[mikeferguson]

While the bottom style might be easier to read initially (not sure that a circle inside a box really says "circle is implementation of box spec"), I think it will get VERY crowded in any real system, with lots and lots of implements lines running back to common specs. Therefore, I think the top design is probably more scalable, and probably a better choice.

[wjwwood]

I would also consider dropping the "default" arrow and using a "(default)" notation on the node, depending on what I can easily do with pydot. If I leave the arrow, I would reverse the direction so that the "default" arrow pointed from the Interface to the Provider, rather than the other way around.

[wjwwood]

@bit-pirate @stonier

[wjwwood]

@mikeferguson I tend to agree.

[stonier]

I prefer the first implementation of diagrams - shapes quickly convey meanings much faster than repeated text and arrows everywhere. For these shapes too it's very easy to quickly infer what they mean as it's very closely related to regular programming relationships.

[wjwwood]

Sorry, I had hoped to have something by now, but I am stuck on this crazy dot rendering issue:

Where dot draws the label at the bottom of the subgraph, but our Qt rendering assumes it goes on the top always, but gets the node position from the dot output, causing them to be on top of each other. As far as I can tell there is no way to extract this information from the dot code... I am going to keep digging on it, but if I can't resolve this then I'll have to fall back on the directed graph only solution, which also gives suboptimal results from a layout standpoint.

[bit-pirate]

I agree with @stonier and @mikeferguson.

PS: Sorry for the late reply - was enjoying my holidays at the east sea ... :smile:

[wjwwood]

I have made a basic compromise in the layout:

Basically I have an subgraph for each capability interface which does not have a label, then I have another node for the interface which has a label and peer nodes for providers which are elliptical and have the provider labels.

[stonier]

Compromise looks fine - how is the status of each component going to show up? i.e. running or not running.

[wjwwood]

Green will be running, black is not running, red on hover (mostly because I am still reusing parts of rqt_graph).

There is a lot of room for improvement on the UX side of things, but for now I am still getting the basics working correctly.

[wjwwood]

Now with osrf/rqt_capabilities@3f4e8b44787f3723803a9ca469bbb33fe3518e74 I'd like to close this ticket and start tracking issues and enhancements on the https://github.com/osrf/rqt_capabilities/issues tracker.

[bit-pirate]

Looks good. Could start, stop, list capabilities be added?

[bit-pirate]

Sorry, skipped the comment about the new issue tracker. Posted the request there: https://github.com/osrf/rqt_capabilities/issues/3