[ROS] Introducing a custom TUI tool for navigating node and topic information

This article is for Day 20 of the ROS Advent Calendar 2021.

As the title suggests, I have created a self-made TUI tool that allows you to navigate between ROS node and topic information, and I'm here to introduce it.

https://github.com/eduidl/rtui

Demo Video

This is a demonstration of running rtui while operating a TurtleBot4 simulator.
Being a TUI (and given my lack of design sense), it has a very simple appearance. However, you can jump from the topic list to individual topic details, echo those topics, and navigate to information about the nodes subscribing to those topics.

Note: All images, including this video, were taken while running on ROS 2 Galactic.

Environment

The following environments are supported:

• ROS 1
  • Melodic
    • However, since Poetry does not seem to support Python 3.6, I have set the requirement to 3.8 or higher.
    • This aligns with Ubuntu 20.04, which has Python 3.8 installed by default.
  • Noetic
• ROS 2
  • Foxy and later

Installation

To promote pipx itself, I will describe the installation method using pipx.
Many of you likely already know it, but for those who have used Node.js, it might be easiest to describe it as something like npx (though the underlying mechanism is quite different).
It is a tool that allows you to install CLI tools without polluting your environment by using venv while maintaining the same ease of use.

https://github.com/pypa/pipx

$ pipx install git+https://github.com/eduidl/rtui.git

However, for Melodic alone, you cannot use the host's Python, so please specify the Python version as follows:

$ pipx install --python python3.8 git+https://github.com/eduidl/rtui.git

Of course, it can also be installed via pip.

Commands

Currently, there are four subcommands. However, since you can navigate between them directly or indirectly, it's practically just one.

rtui nodes

No arguments are required. Initially, only the left column is displayed, but clicking on any node name will show that node's information on the right screen.
For ROS 1, action information is not displayed because there doesn't seem to be an API to retrieve it, but the display is similar.
You can jump to information by clicking on topic names, service names, and action names (ROS 2 only). When you jump to topic information, the left column is also updated to the topic list (the same applies to other information types).

rtui topics

It displays the message type and the nodes that are publishing/subscribing to it.

Also, only on this topic screen, you can subscribe to the topic by pressing the e key and display it in the lower half of the right screen. Pressing e again will stop it.

In ROS 2, unlike ROS 1^[1], it seems possible to output the same topic with different types simultaneously ^[2].
Honestly, this specification gave me a headache, but I decided to display both types without overthinking it. The subscription when the e key is pressed is hardcoded...

rtui services

In ROS 1, I was disappointed that only server node names could be retrieved, but I became even more disappointed when I realized that in ROS 2, neither could be retrieved.
In ROS 2, although you can navigate to a service from a node name, you can't go anywhere else from there and would end up having to restart the tool. To address this, I've implemented a history feature so you can return with the b key.
Parameter servers in ROS 2 are hidden from the list because there are too many of them.

rtui actions

For actions, both servers and clients can be retrieved. Is this a sign that we should use actions over services?

Closing

That's all for the current features. If you think it looks useful, please give it a try.
I'm also looking forward to your feedback.

Future Work

• Displaying information such as message types (equivalent to rosmsg or ros2 interface)
• I feel like something like rqt_console would also be suitable for TUI
• I'd like to switch if there is a better TUI library than Textual

脚注

1. In ROS 1, is it "last one wins"? It seems reasonable since it would be a hassle if you couldn't change it once it's set during development... I guess

2. I don't understand the reason for doing so