Hi everyone,
at iRobot we are investigating the state of ROS2 tools and we think that it would be useful to allow the possibility of running all visualization plugins from a single application.
In ROS a tentative solution to this problem had been identified in the rqt_rviz plugin. As its name states, this allows to run rviz as if it was a regular rqt plugin. It would share the same interface and it would be able to communicate with the other plugins through the ROS communication framework.
As you can see from the plugin wikipage, the ROS plugin is marked as experimental because it has frequent crash-related issues.
This problem is being tracked through the following tickets:
According to these tickets, the problems are due to
rqt runs an async spinner for C++ plugins
rviz is not designed to be run as a nodelet in the first place therefore I assume it is running its own spinner. With two different spinners running the context / thread in which objects are created / used is not deterministic
In ROS2 there is no more a difference between nodes and nodelets. Moreover, the whole managing of threading has been made simpler.
It’s important to note that rqt_rviz was not designed to supersede rviz, but it depends on it.|
For this reason, this port will eventually require to make changes to rviz itself.
I would like to discuss with you about the possible challenges of this port and whether you think this is the best solution for incorporating all the tooling functionalities in a single place.
Besides this, I would like to also ask to the rqt and rviz users if they would be interested in such a plugin.
The topic was already mentioned by some users when rqt for ROS2 was announced RQT in ROS2 - #2 by lucasw.
While the effort involved may be large, there are probably groups that are interested in an integrated solution just for the convenience of it all. I helped port rqt with Mike Lautman at Picknik and Dirk Thomas, and those two might be able comment more on the threading issues related to cpp plugins in rqt and ROS 2. However, I’m wondering what extra utility such an integration may bring? rqt plugins communicate through standard ros communication channels, so rviz sitting inside an rqt window wouldn’t really integrate the plugins any closer to rviz. Are you thinking of tackling this problem for the convenience of putting all visualization tools in a single window, or are you looking to add more functionality to rqt or rviz?
I think that at first this would be mainly useful in order to have all functionalities in the same window.
For the future, this can also be considered as a first step towards expanding the functionalities of the ROS2 visualization tools.
Maybe it will be possible to exploit intra-process communication, but this is just a speculation.
I agree with you that the required effort will not be negligible. That’s why I would like first to gather all possible information on this topic.
@dirk-thomas do you have any thoughts on whether the threading issues of the plugin can be solved in ROS2?
This problem is not specific to ROS 2 - it was already present in ROS 1. The existing ticket referenced above describes the problem.
As far as I recall rviz would need to be updated to support running in a nodelet/component-style of way - not assuming it is alone in the process to coexist with other nodes.
Actually it makes all the difference I think. Since the problem in ROS 1 was to due with both rviz and rqt using the same node singleton. In ROS 2, they can each have their own if desired.
I haven’t looked into what exactly the original issue was and whether or not it is implicitly solved, but from what I remember it may just work in ROS 2.