ros2/ros_network_viz

Documentation is at https://docs.ros.org

ros_network_viz's Issues

Warn the user when we cannot fetch the parameters

In order to display parameters, ros_network_viz uses the list_parameters/get_parameters services for the initial values. However, it is possible to construct ROS 2 nodes that don't have those services available. When we notice a node like that, we should show "Cannot get parameters" in the tooltip, vs. the "No parameters" that we show now. They are different cases.

Animate connections as the graph is updated

As the user drags around boxes that represent nodes, topics, services, and actions, the connections move with them.

As nodes, topics, services, and actions come into the network, they are automatically rendered into the scene with connections. However, those connections are only drawn at the end, after all of the nodes have been animated into place. It would be much nicer if the connections were animated along with the items they are connecting.

Figure out some way to get composed node updates efficiently

Composable node containers offer a list_nodes service that allow us to get the list of nodes that are managed by the container. Unfortunately, there is currently no topic that produces updates to the list of nodes, so if they change dynamically, the only way we can find out is through polling that service.

We should probably make some changes to the ROS 2 core so that there is a nodes_changed topic that gets published to when the list of nodes in a container changes.

Add a legend to explain what all of the colors, lines, etc mean

The current view of the network uses different colors and lines drawn to different places to denote nodes, topics, services, actions, and connections. In order for a user to understand this, we should have a legend somewhere on the screen to show the user what all of this means so they can more easily interpret the data.

Don't show the parameter related services in the tree view by default

In the right-hand tree view in the current UI, we are currently showing all nodes, topics, services, and actions. But a lot of them are ROS 2 builtin things, that are probably not relevant to most users. We should have a way for a user to hide these from the tree view so that it is much less cluttered.

Install instructions?

git clone https://github.com/ros2/ros_network_viz.git
colcon build --symlink-install
. install/setup.bash
ros2 run ros_network_vis ???

I couldn't spot an executable?

Add a side panel to show warnings or errors in the network

It would be great to have a side panel that shows any kinds of warnings or errors that are present in the network. For instance:

• If the network has multiple nodes with the exact same name
• If there are topics with the same name, but incompatible Quality-of-Service settings

Release the package into Rolling, Galactic, and Foxy

This should make it available to more users. I know for a fact this will work in Rolling. I'm fairly confident it will work in Galactic as well, though I haven't tested it. I don't know whether it will work in Foxy; it depends on whether the code as currently written is using any "newer" rclpy APIs that don't exist in Foxy. It needs testing.

Have a way to hide all topics/services/actions without a connection on the other side

That is, topics that have a publisher but not a subscriber, services that have a server but not a client, or actions that have a server but not a client could be hidden by default. The user would have some way to show them if they wanted.

Show the number of publishers and subscribers in the topic mouse-over tooltip

Have a side box to persistently display information about nodes, connections, or groups

Right now when you hover over a node, a topic, a service, an action, or a connection, some additional information about that particular item will be shown. However, it would be nice if there were a more "persistent" way to show this data, and to show this data for groups of items.

That is, if the user clicks on a node, it would show in some kind of side-panel the current Parameters, Lifecycle State, Composed Node state as appropriate. This would continue to be shown, even after the hover-over over the node has disappeared. This data would also update in real-time as data on the node updates. That is, if a parameter on a node changed, the new value would be immediately shown in this panel (due to technical limitations in Qt tooltips, this can't be done in the hover-over case).

Finally, it would be great if this persistent side panel could show information about groups of items. That is, if the user selected 2 nodes, a topic, and the connections between them, all of that information would simultaneously be shown in the side panel.

Support lifecycle state updates on nodes that don't have /transition_events

When constructing a ROS 2 lifecycle node, it is possible to disable the /transition_events topic. Right now, ros_network_viz depends on /transition_events to get lifecycle state updates in the network. For nodes that do not have /transition_events, we should instead poll the get_state service periodically to check for lifecycle state updates. Note that it is also possible for a ROS 2 node to be constructed without that service, so there is no way we can always guarantee that we can show the lifecycle state.

Gracefully handle topics, services, actions with unknown topic types

We need to test to make sure that if we see a topic, service, or action that we don't know the type for, we don't crash or otherwise throw an error.

Have a way to search in the tree view

This is helpful in very large networks.

Performance issue when enabling/disabling large numbers of items

When enabling or disabling large groups of items (like all services in a scene), it can take a long time for the GUI to render and return. This requires investigation, as it can be quite a bad user experience in large networks.

Have the ability to have a white background for printing

Maybe we can make all of the colors configurable? Not sure if that is worth it.

Allow the user to click on certain subset of items and only show them

That is, let the user select a subset of the items and then hide everything else in the scene and the tree view.

Allow the user to click to only show things connected to a particular node

That is, they would right-click (or similar) on a node, and then they could say "Show me only things connected here". The scene would update so onl this node and all topics, services, and actions, and nodes connected to those would be shown.

This could be somewhat expensive to compute, particularly on a large graph.

Distinguish between publisher and subscriber connections

Right now, publisher connections are subscriber connections can be hard to distinguish. They are both the same yellow color, and the only difference between them is whether they are on the right side of the node (publisher), or the left side of the node (subscriber). We should consider how to draw these lines so the user can distinguish them more easily. Possible ideas:

• Draw an arrow indicating the direction that data is flowing
• Use a slightly different color for publishers and subscribers

Allow the user to "group" items to reduce clutter in a busy scene

In a large network, it can be hard to see all of the individual nodes, topics, services, and actions since there can be so many of them. Besides the ability to hide certain parts of the graph (which already exists), it might be nice to allow the user to "group" nodes, topics, services, and actions together into a single box. The connections would come out of the group, but they would all appear to be coming from the same place. This could significantly reduce the clutter on the screen.

Support parameter updates on nodes that don't have /parameter_events

When constructing a ROS 2 node, it is possible to disable the /parameter_events topic. Right now, ros_network_viz depends on /parameter_events to get parameter updates in the network. For nodes that do not have /parameter_events, we should instead poll the get_parameters service periodically to check for parameter updates. Note that it is also possible for a ROS 2 node to be constructed without those services, so there is no way we can always guarantee that we can show parameters.