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.

[cooperj]

I understand that exposing the Docker socket is something we cannot rely on to access other containers terminals. But this was an idea on how to implement the user having access to spawn items from other containers inside the web view.

I am now considering the purpose of accessing anything other than running a display inside this container, or to put it simply, why/when does a user/developer need to launch any apps inside the container?

I am a little concerned about implementing the vnc container on top of a ROS enabled base with a minimal ROS environment. As if the display container is only being used as a x11 destination, this will then make the container larger than it needs to be (and have more deps).

Unless what you're considering is to have this as an alternative base for using with development allows for a similar experience to what is inside LCAS/docker_cuda_desktop.

From my perspective that is adding a lot more complexity when it comes to real world deployment as you're using a completely different environment from deployment. Should the developer be running the vnc container as a part of a compose stack inside VS Code?

I think it would be best to work through to an MVP, so what I am thinking and my concept can be fully demoed. Then we can go from there and decide which is the best way forward.

[marc-hanheide]

I understand that exposing the Docker socket is something we cannot rely on to access other containers terminals. But this was an idea on how to implement the user having access to spawn items from other containers inside the web view.

I am now considering the purpose of accessing anything other than running a display inside this container, or to put it simply, why/when does a user/developer need to launch any apps inside the container?

I am a little concerned about implementing the vnc container on top of a ROS enabled base with a minimal ROS environment. As if the display container is only being used as a x11 destination, this will then make the container larger than it needs to be (and have more deps).

Unless what you're considering is to have this as an alternative base for using with development allows for a similar experience to what is inside LCAS/docker_cuda_desktop.

From my perspective that is adding a lot more complexity when it comes to real world deployment as you're using a completely different environment from deployment. Should the developer be running the vnc container as a part of a compose stack inside VS Code?

I think it would be best to work through to an MVP, so what I am thinking and my concept can be fully demoed. Then we can go from there and decide which is the best way forward.

OK, I think I understand (maybe). You want “just” an X Server that other containers can connect to (via normal X protocol?), So, they may set export DISPLAY=vnc:0? Is that the idea? In that case all the other containers still need to have all the things for acting as an X client installed. So they all would contain a lot of X-related libs, wouldn’t they?

That is very different to what I had in mind, indeed then. To clarify what I had in mind:

• A base line ROS container (and one with CUDA)
• A lean add-on on top of that that is a GUI-enabled ROS container image. Basically, just adds VGL, turbovnc and novnc. (will not add more than a few Mb), the CUDA flavour is OpenGL accelerated through VGL (as is currently the case)

Then whenever we build bespoke images they are built on top of either these flavours.

E.g., I would suggest a dedicated “rviz”/rqt image, build on top of CUDA-enabled VNC. This can then be used in many instances to introspect another container

But, by all means, complete a MVP as I’m still not sure I fully get it.