Awesome,
I should have known you'd already added this tool to your toolbox.
@William
Docker can defiantly be useful for end users who what or need to use graphical interfaces.
In fact that was one of the points I spent most of my time getting nailed down before I decided I'd approach the community as I wanted a proof of concept working first. If you take I look at
my Dockerfile setup, I followed OpenCog's approach, and built up a series of base images for our project ranging from a simple ros desktop install all the way to a functional GUI demo app, with a few degrees in between depending on whats only required for my lab mates to develop in.
The last bit in getting the x-server to play nice with my container was a bit tricky, but its not hard to implement once you've got a solution. I remember playing with docker-desktop, but I was a little disappointed with the frame-rates using x11 forwarding over an ssh tunnel, especially for stuff like video, 3D GUI apps or any other bandwidth intensive display scenarios. So I tried a different approach, similar to
docker-browser-box, where instead of piping the display over a network I could mount my host's xserver unix socket to the container directly instead. I also have PulseAudio working with this, not that my ros app uses it now, but I'm sure others certainty do.
From there you can also give the container access to graphical hardware acceleration, so with a short
start up script, you can have gazebo using the Nvidia driver in the container to accesses the Nvidia driver of the host, to use the GPU for all of the OpenGL rendering. So with this, I can get the same FPS in the container as would if I ran the instructions on my host's shell. This allows me to play around with newer versions of gazebo without constantly breaking my host's stable development environment. I think I have this working for Intel's HD graphics as we'll, so I'll have push that Dockerfile and script. Maybe I could post a youtube video of an example.
@Tully
Although I've gotten my lab's project working under an automated build setup now, such that when I push new commits to the project's public release repo, the web-hook for the dockerhub registry triggers, and the image(s) are rebuilt using the newest source/packages, the same posses for official repos looks to be a bit more involved. But there seems to be a tool called
Bashbrew for automating the process.
As an aside: I think the minimum naming isn't an issue for official repo names, as they are not tagged under any user, e.x. the official PHP repo is simply "php", so a repo name like "ros" should be fine there.
I agree rosdistro is probably too busy, as it might cause some trouble with all the web-hooks poking about. Could we make a new repo under ros specific to just Dockerfiles, duly named "docker"?
Ruffin