feat: add seperate display container

[cooperj]

this is the code I have been working on locally to create a display container that is seperate and not ros enabled

the idea with it not being ros enabled and running on debian:trixie-slim is to keep the size of this display container down, and reduce complexity.

This code is to be merged into the PR #1

[cooperj]

I do want to slim this down further, but not change too much to make it too much harder to use.

The rough plan was to install docker tooling inside this container and sharing the docker.sock allowing for us to have desktop shortcuts for running docker exec into other containers, and I propose we should configure that with docker labels.

[cooperj]

@marc-hanheide do we want to rebase this onto the main branch and merge this after #1?

[marc-hanheide]

I do want to slim this down further, but not change too much to make it too much harder to use.

The rough plan was to install docker tooling inside this container and sharing the docker.sock allowing for us to have desktop shortcuts for running docker exec into other containers, and I propose we should configure that with docker labels.

I'm not convinced by making an assumption of access to docker socket. That's a deployment question that shouldn't have an impact on the container.

we can use devcontainer labels to facilitate attaching to it

[marc-hanheide]

@marc-hanheide do we want to rebase this onto the main branch and merge this after #1?

yes, feel free to merge #1 if happy with it and bring it all together

[marc-hanheide]

I have merged #1 and rebased here.

[marc-hanheide]

Ok, I looked a little closer. I think given the commitment to ROS, I think it’s better to base the display container on a simple basic ROS image, or rather one of our base images. These don’t have to be big (i.e. don’t have ROS packages installed, but have the ROS repos enabled and rosdep initialised, and then put VGL and novnc on top of it. Not more, but also no less. They should be ready to install ROS2 packages. We could have 2 flavours (and I wouldn’t call them display):

• ros_vnc
• ros_cuda_vnc (also with environment variables configured to use VGL correctly to provide host acceleration via EGL)

Both should have novnc with a reasonable window manager (e.g. xfce4) and an entry point to launch the desktop in my view. They may not install anything else (not even rviz), but be ready to simple resolve package.xml via rosdep install -i —from-paths <WHATEVERPATH> so that it’s super easy to derive specific images from them but just copying in a ROS2 workspace and run the rosdep command.

That comes with very little overhead but provides an X11-ready ROS2 environment. What do you think, @cooperj ?

[marc-hanheide]

then my cuda_desktop should be depend on your ros_vnc flavours, to offer a full containeriesed ROS2 desktop experience, with rviz2 ready to go. So, I suggest the following pipelines:

ros (or ros_cuda) -> ros_vnc (or ros_cuda_vnc) -. ros_desktop (or ros_cuda_desktop)

with the *_cuda_* flavours being much bigger, but providing EGL/VGL acceleration utilising the host’s GPU.