Add QtQuick / QML support

[machinekoder]

Rviz only supports building QtWidgets applications. Although widgets are great for desktop applications, they are very unsuitable for HMIs and modern touch-friendly apps.

Since ROS may sooner or later be used for industrial robot applications, it makes sense to support QtQuick top enable building modern touch-friendly HMIs.

I have a patch upcoming that integrates the Rviz visualization into QtQuick.

[machinekoder]

I migrated this issue over from rviz/ROS1 as this is very likely not going to happen without some ABI changes. https://github.com/ros-visualization/rviz/issues/1209

[simonschmeisser]

We would be using that mode, currently we can live with having an embedded Qml window with our UI next to a traditional Rviz QWidget. However this is not a very common use case of Qt and has numerous window manager and graphics driver dependent issues. Ie for mesa based drivers we need to use Qml software rendering as OpenGl based Qml rendering messes up the state of OpenGl/Ogre in rviz. On Nvidia however we can enable both in OpenGl mode as they use separate rendering contexts by default

I'm not sure how much time we can contribute actively as we will stay on ros1 for the time being (we use mainly MoveIt!). We shortly talked about ROS1 support in Rviz2 at ROScon but I haven't had a look at how hard/attractive that really is.

[machinekoder]

@simonschmeisser You might be interested in taking a look at the PR for ROS1.

We also tried the widget window + QML application method but discarded it quickly because of the rendering issues you mention.

The approach in the PR renders Ogre under QML, which works nicely even with mesa drivers. The only drawback is, that it doesn't work with multiple render windows so far. We solved this problem by using only a single render window and re-using it for all screens. There are a few other tweaks necessary to make it work with scaling QML GUIs, but overall it works very well.

RViz2 can be combined with ROS1 with the ros1_bridge. I haven't tested it yet, but I have heard that people already use it for setups that include wifi.

[Martin-Idel-SI]

Yes, rviz2 works well with the ros1_bridge. However the idea is that it would be great (from a maintenance perspective) to have rviz2 work natively with ROS 2 and ROS 1 - then one of the repositories could be archived in the long run and maintenance would be easier.

I think that already now one can see that it would be a good idea to have only one place for rviz. There are already quite a few bugfixes in rviz2 that would be nice in rviz and vice versa. However, there are a lot of smaller and bigger things not working in rviz2 at the moment (missing message filters for instance) so until those are present, I doubt any ros 1 user would really want to switch.

Regarding backporting to ros 1. For reference, I'd add my thoughts here:

I once had a look but it's not straightforward to do this. There are some problems to overcome:

• There are a few core features missing that I think would be best to port first: In particular, message filters are not yet ported to rviz2 because until recently they just weren't available.
• The encapsulation of ROS in rviz2 is not complete: First one would have to finish encapsulating all calls to rclcpp, rcl, etc. into the ros_integration subpackage (in principle, this could be a separate package such that all other parts of rviz would be independent of ros2).
• Then one would have to investigate whether the abstraction can be used to reintroduce ros1. I think this is not straightforward (in particular, node handling is drastically different in rviz2 - in rviz, every display has it's own node handle, while in rviz2, every display only has a subscription and there is only one node. I guess this could be mimicked, but it's probably not straightforward) -> I guess this means one would then have to make the ros_integration package a true abstraction

This would leave a few other points to discuss:

• Namespacing of message definitions has changed between ros and ros 2. There are of course easy ways to deal with this (have files with type mappings for instance) but I don't see a really nice way, so this should be discussed
• Build system: RViz 2 uses ament_cmake. So either we get support of ament_cmake in ros1 (via colcon?) or we'd have to get catkin in somehow.
• In addition, the ament index is heavily used for meshes and the like (this is also where other plugins can put their meshes, etc. to be found by rviz). The mechanism in ROS works differently, but this is already limited to one place in the code base (loading resources), so it should be rather easy to deal with.

In addition, some more time should be spent on making migration of plugins easier or automating it.

[simonschmeisser]

@machinekoder I've seen your PR before but would prefer not to use a fork of rviz1. I would however really appreciate and support you with a PR against rviz2 where ever possible.

@Martin-Idel-SI thanks for the exhaustive summary!

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/gsoc-and-intern-projects-for-summer-2020/16237/9