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 doesnāt 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 isnāt 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).
