Development of a user-friendly ROS2 GTK4 GUI with Adwaita theme

ROS Projects
, ,
1

Greetings, ROS community,

I am developing a new graphical interface application for ROS2 Jazzy, designed as an alternative to rqt. This project started as a personal endeavor over the last Christmas holidays, but I believe it could also benefit the community.

While rqt has served the community well as a versatile tool for interacting with ROS systems, for me it was always a bit tedious to work with. This motivated me to explore a different approach.

Introducing Insight

I am excited to introduce the application as Insight - a modern, user-friendly GUI for ROS2.

The source code is hosted on GitHub, where you can explore the project, contribute, or report issues:

Please feel free to explore the codebase and share your feedback.

Why Develop an Alternative to rqt?

  1. Improved Integration with Ubuntu and GNOME
    ROS is predominantly used on Ubuntu, which employs the GNOME desktop environment and its Adwaita theme. rqt’s interface often feels outdated and out of place in this environment, lacking the polish and cohesion users expect from modern applications. My application, built with GTK4 and Adwaita, is designed to integrate seamlessly into the GNOME ecosystem, providing a consistent and visually appealing user experience.
  2. Enhanced Usability
    rqt’s interface, while functional, can be unintuitive and challenging to navigate, particularly for newer users. My goal is to create a streamlined, user-friendly application that looks and feels like known GNOME applications. Even though I’m an engineer myself and dont need fancy stuff, I also like, when things are easy to work with.
  3. Modern Technology Stack
    By leveraging GTK4 and Python, this project takes full advantage of contemporary GUI development standards. It also serves as a personal exploration of GUI development with GTK4.

Current GUI Features

The application already supports several core functionalities for interacting with ROS2:

  • Viewing Nodes: Display detailed information about running nodes (similar to ros2 node list and ros2 node info), including their topics, services, and more.
  • Viewing Topics: List all topics (similar to ros2 topic list), inspect details of specific topics (similar to ros2 topic info), and view message definitions.
  • Viewing Services: List all services (similar to ros2 service list), inspect specific services (similar to ros2 service info), and view message definitions.
  • Viewing Actions: List all actions (similar to ros2 action list), inspect specific actions, and view message definitions.
  • Viewing Message Definitions: Access detailed message structures, including raw definitions. This was the first feature developed and the original motivation for creating the GUI.
  • Viewing Transformations (TFs): Visualize all coordinate frames and calculate transformations between frames (similar to ros2 run tf2_ros tf2_echo source_link target_link).

Key GUI Features

  • Filtering: Each page includes robust filtering options for quickly finding relevant content.
  • Navigation: User-friendly navigation, no menu bar.
  • Nested Pages: Navigate through nested message definitions.
  • Copy Button: Simply press a button to copy relevant content (like the command to execute a node, eg. ros2 run turtlesim turtlesim_node)
  • View Online: See a message definition in the browser.
  • Open folder: Open the folder of a package.

Planned Features

To further enhance the application’s utility, I plan to implement the following features:

  • RQT Graph Equivalent: A visual representation of the ROS2 graph, showing nodes and their connections.
  • Subscribing and Publishing Data to Topics: Enable users to send and receive messages directly from the GUI.
  • Calling Services: Provide an intuitive interface for interacting with ROS2 services.
  • Logging: A dedicated screen to display recent logs, with advanced filtering capabilities.

Screenshots

Here are some impressions of the current state of the application:

refresh_page
refresh_page922Ă—622 18.5 KB

pkg_info
pkg_info922Ă—548 20.5 KB

node_info
node_info922Ă—849 32.1 KB

msg_browser
msg_browser922Ă—795 32.2 KB

msg_filtering
msg_filtering922Ă—795 48.4 KB

msg_info
msg_info922Ă—422 16.4 KB

msg_definition
msg_definition922Ă—694 25.2 KB

srv_info
srv_info922Ă—694 22 KB

tf_calculation
tf_calculation922Ă—798 26.9 KB

Development Process

This project is developed during my free time and currently has no fixed timeline for completion. As a side project, I am open to contributions from experienced ROS package developers and GUI developers who are interested in collaborating.

Also the application is not released yet, as it is my first ROS package, and I still need to test stuff, before releasing the first version.

I welcome your feedback and suggestions as I continue to refine this application. If you have ideas for features or improvements, I’d love to hear from you. Thank you for your time and interest!

16 Likes
2

Curious to hear why you thought GTK was the right technology to use for this kind of GUI. Why not a web based UI? Web based UIs have some serious advantages, incl.:

  • cross-platform,
  • no installation required,
  • remotely accessible.

In fact, a lot of the functionality you show is already available in the Transitive ROS Tool (topic list + message types, service list + service type), plus some you don’t yet have namely publish messages and call services.

1 Like
3

Replacing rqt is a fantastic project idea!

I’m unfamiliar with GTK4. Can it be used on Windows and macOS, or is it Linux only?

Each of the rqt displays is a different plugin. Do you intend to go the plugin route so that others could create an insight_gui plugin in their own repo, or do you intend for insight_gui to contain all the functionality in once place? There are pros and cons to both. If you’re hoping to have rqt deprecated and replaced, then going down the route of each display being a plugin might make that easier to get buy-in on in the future.

1 Like
4

Thanks for this initiative @julianmueller.
I learnt about it via this linkedin post.
I am trying to test it but I am struggling to install and run it (ubuntu noble/ROS2 jazzy). I opened an issue with details.

5

Depending on how much “cross-platform” you are looking for, but GTK is cross-platform too. Otherwise, you couldn’t run GIMP (the origin of GTK) on other platforms, too.

And “no installation required” is a bit of a simplification. Your “web based UI” will need software to serve the website, and of course, you need some kind of “client” too. And on top of this, you sometimes have to deal with different browser engines.

I think running software locally is totally fine, especially when you are looking for a low-overhead solution and minimum latency.

6

That’s how a lot of robotics company start building their UIs. Then, if they are successful as a business, they’ll scale their fleet to around 5-10 robots and stop chaperoning them around all the time. At that point they realize that running UIs locally on the robot is really cumbersome – some try to bridge that using VNC over VPN, others try to run Rviz remotely. This is awkward especially for non-engineering staff, who may need help installing VPN and VNC. Then they realize a web app would be so much easier to access remotely (for monitoring, configuration management, control, etc.), and wouldn’t require any installation on part of the remote user (e.g., field operations staff). Some then go and deploy a web server on the each robot that hosts a UI they can access remotely, still requiring VPN. However eventually everyone realizes that "robots should be clients"™, set up a web app in the cloud and let all robots connect to that (no more VPN required). At that point they can finally support all their user personas, incl. customers. But unfortunately the switching cost between these three stages is significant and costs robotics companies valuable time, both in terms of wasted engineering effort and in terms of delays deploying more robots and hence vital revenue growth.

2 Likes
7

this is a vary good work

1 Like
8

Thank you very much for your suggestion, but I think you just asked the question. I hope you can give some suggestions to improve this question while asking it?

9

I already answered above (before the comment you quoted). Robot fleet management GUIs should be web based, hosted in the cloud (not on the robot), and robots should be clients (not servers). In top of that the cloud should cache the latest data received from each robot to always be able to show the latest from each robot, even if the robot is offline and the data is old.

1 Like
10

Hello, I’m aware of the very modular plugin nature of rqt. I’m not planning on integrating something like that in Insight. And I dont think, that I want to replace rqt.

I want Insight to be easy to use and just give basic functionality. So I guess its more for beginner and intermediate ROS users, to ease the entry.

Since my initial post, I already implemented more functionalities, like viewing images, TFs, detaching windows, etc. To I’m willing to integrate popular “plugins” into what Insight ships with as default.

Hope this answers your questions.

11

Thanks for the question. I’m not a big fan of webguis and Insight was originally for myself to try out GTK4 and ROS2. So it comes down to personal preferences, and you have a valid point that web-based applications have merit. I just want my programs to run locally (with respect to that ROS2 is network compatible).

Also I wont port anything to Windows, as I dont see an open source project like ROS on a propriotery OS. Again just my opinion, but wont happen.