Build docker variant for GUI apps

[franklinselva]

Feature description

Based on the current refactoring (from space-ros/space-ros#186), the space-ros images doesn't support any GUI apps. However the demo packages still use Gazebo, Rviz2 and Other GUI apps which might make it harder to have better reproducibility and maintainence. The proposal here is to add one more docker tag variant called gui that fills up the gap here.

Implementation considerations

This is the workflow consideration based on all the image variants that have been developed so far.

graph LR
  A[Base/Core Variant] --> B[Dev Variant]
  A --> C[Nav2 Variant]
  A --> D[Moveit2 Variant]
  A --> E[GUI Variant]

subgraph Main Image
  A
B
end

subgraph Stacks
  C
  D
  E
end

Loading

The GUI variant can hold the following functionalities,

• Build gazebo fortress/harmonic
• Build rviz2 for visualization
• Structured docker networking to help message transfer
• Make the GUI apps independent of all the other docker images for easier maintainence

When trying to write a demo file,

graph LR
  A[Demo Image on top of Core/Dev/Moveit2/Nav2] <--bi-directional communication-->E[GUI app with Gazebo/Rviz2]
  A <--bi-directional communication--> F[Isaac Sim Docker]

Loading

There are few other gimmicks to the above proposal since we can easily switch different simulators without any issue. Additionally there are few other dependency issues since packages like moveit-ros-visualization and nav2-rviz-plugins depend on moveit2 and nav2 packages respectively.

[franklinselva]

Since this is purely a GUI variant only for simulation and visualization, do we need to follow the space ROS development critic practices? If not, the above changes are much more simpler.

[asimonov]

great idea.

I have a version that I currently use where I install Gazebo Harmonic from apt (think it is too tricky to build, but may be it is historical bias). the rest - rviz2, rosbag2, rqt, pluagins etc are from source. Mainly because I want to keep it in same derived image as space-ros

[franklinselva]

I have also added a version of the image with ros2-humble as the base version instead of space-ros. This version still keeps everything from apt skipping any builds from source.

[Bckempa]

The idea of putting development/visualization tools into a stack has been raised before and I'm a fan. I wonder if Gazebo should be separate from an RViz/RQT layer since it's a simulator not just a visualizer and you might either want it but not the other GUI tools, or might want a different sim as you mentioned.

[franklinselva]

Fair point. I recommend Rviz and RQT as additional tools written on top of the simulator stack image. This should fairly simplify the containers/nodes in the docker services. If we apply the same approach to a real robot, the rviz/rqt tools still stay outside of the robot in most cases, and it should tally things up. We can write a separate file for it at a requirement since this is a very narrow use case.