[ros-users] [Discourse.ros.org] [Next Generation ROS] RQT in ROS2

[Lucas Walter]

> Please do not mistake porting effort with arbitrary feature development. The main goal is to port the existing framework and several plugins to ROS 2 (Python 3 as well as Windows).



I'm responding to the 'While this is an ideal time to break API, given time and resource constraints, enhancements will be secondary to porting existing functionality. However, this thread will also act as a rough roadmap to guide future enhancements' above.  If there were decisions to be made in immediate porting effort that would benefit the sorts of features outlined above then that is the substance to take away.  For instance, if only a subset of the common plugins where to make the cut for the targeted release, the first few items are what I would like to see- and others will have an opinion, and maybe some shouldn't be ported at all?  (I'm drawing inspiration from other ros2 threads about if a given package or part of a package isn't used much, or has been superseded, or just is way less useful than some other parts or packages, don't bother porting right now or ever)



> There is no reason to implement yet another plotting plugin. There is already (at least) two:  `rqt_plot`  as well as  `rqt_multiplot`



If it were quicker to do it from scratch, or just narrow support to a single back end, and that would make the difference between having rqt_plot by the desired time or not, and/or it would end up with better performance, then that would be the reason to consider not just a direct port.  (Maybe it should publish the plot as an Image, or a generic vector image message type if pixels seem clunky?  Maybe every visual plugin should publish an Image instead of drawing directly to a window- that would simplify several of them, to the point where they are no longer even rqt plugins, just regular ros2 nodes with parameters set through a generic ros2 param setting rqt plugin?  If there are strong reasons not to that ties into the rviz-rqt idea)



> Dynamic reconfigure conceptionally / intentionally doesnt exist in ROS 2. The ROS 2 parameters are node specific and replace the ROS 1 parameters as well as dynamic reconfigure.



Instead of direct porting there would be an equivalently functional rqt ros2 plugin for viewing and changing per node parameters.  (Being able to hide some parameters and save that into the .perspective would be useful if every node has a lot of boiler plate parameters.)



> In the past Qt offered the ability to embed widgets from separate processes (at least on X11). That is not available in Qt 5 anymore and therefore this way of isolating plugins in  `rqt`  isnt possible anymore. If you see another way to achieve this please feel free to propose it.



That's unfortunate.  In the much longer term maybe the qt in rqt should be something else (which could also benefit the web/android/whatever cross platform capability, or some of the other items here).



> Publishing and rendering the  `rviz`  views and relaying the mouse / keyboard interaction sounds like a big no-go to me.



I'd be curious to know why- if it has anything to do with underlying limitations of ros or qt it will help me guide my future pull-request efforts and comments (if it is just timeframe this is something for the longer term, e.g. 'rviz2.5' or 'rviz3').  I've done similar things on a limited scale in ros1 with satisfactory results, I assume ros2 will perform better.



>> Convert a .perspective file to a webserver + html5/js, or an android app



> This sounds like an incredible complex task - even ignoring that there are no html5/js or Android components atm which could be the target of any mapping.



Yes that is true, but again I throw it in here in case someone else knows something can contribute, or in some decision between x or y it turned out x could be more easily converted to those platforms.  The short term would probably be a few of those components- a generic node parameter configuration widget, an image viewer, plotter, echo, publish, etc. and just a document to guide how to manually assemble them into something similar to the rqt file, and automation later.



> If you would like to specific features please feel free to contribute them - either to the current ROS 1 branches or to the -to-be-created ROS 2 branch.



Of course, I've always done this in the past.  I'm hopeful that if the right minimum coverage of standard ros interfaces have good general ui plugins then writing ui code now will pay off in my (or someone else in my place) not having it to write much or any application specific ui code in the future, it will just be a matter of selecting and positioning and configuring the widgets (we'd be writing ros nodes with ros interfaces mainly meant to be part of a ui that is a thin layer of generic plugins, but that is an improvement over having to write qt).











---

[Visit Topic](https://discourse.ros.org/t/rqt-in-ros2/6428/4) or reply to this email to respond.