Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build docker variant for GUI apps #188

Open
franklinselva opened this issue Sep 10, 2024 · 5 comments · May be fixed by #190
Open

Build docker variant for GUI apps #188

franklinselva opened this issue Sep 10, 2024 · 5 comments · May be fixed by #190
Labels
enhancement New feature or request

Comments

@franklinselva
Copy link

franklinselva commented Sep 10, 2024

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 franklinselva added the enhancement New feature or request label Sep 10, 2024
@franklinselva
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Contributor

Bckempa commented Sep 21, 2024

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
Copy link
Author

franklinselva commented Sep 22, 2024

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.

franklinselva added a commit to franklinselva/spaceros-stacks that referenced this issue Sep 26, 2024
Related to space-ros#188
 - Add docker file for GUI stack
 - Add build.sh at root level to build GUI stack
 - Add run.sh at root level to run GUI stack
@franklinselva franklinselva linked a pull request Sep 26, 2024 that will close this issue
franklinselva added a commit to franklinselva/spaceros-stacks that referenced this issue Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

3 participants