Adding Gazebo

[ruffsl]

Hello again Docker Library Admins,

We are from the Open Source Robotics Foundation (OSRF). We are an independent non-profit organization founded by members of the global robotics community. Our mission is to support the development, distribution, and adoption of open source software for use in robotics research, education, and product development.

We would like to create a new Official Repositorie for our large opensource project: Gazebo.

Included is the gzserver tag for our latest long term release, version 5, suitable for newer users just learning how to incorporate Docker with Gazebo, as well as for advanced developers requiring a common foundation to build and test their cloud robot simulations. This official image contains only build and communication libraries and environmental setup.

Examples that could build from this repo include:
CloudSim and The Construct

After some exploration and research on the process, would appreciate your help and advice in polishing this pull request and incorporating Gazebo into an official DockerHub image.

Helpful Links:

Gazebosim.org: Main Gazebo website
Answers: Find answers and ask questions
Wiki: General information and tutorials
Mailing List: Join for news and announcements
Simulation Models: Robots, objects, and other simulation models
Blog: Stay up-to-date
OSRF: Open Source Robotics Foundation

[ruffsl]

Bump...

Just wanted to check if they was any questions/activity on the PR.
Thanks guys.

@yosifkit @tianon @psftw

[tianon]

Sorry for the delay, @ruffsl. New repos are usually much higher interactivity on review than updates, so a lot of times they'll get pushed back a bit while we deal with the constant deluge of updates.

I've taken a look at the Dockerfile here, and I don't see any obvious issues with it (given my limited knowledge of Gazebo); I am curious why the default command is bash when it seems like it maybe should be gzserver or something instead? It just feels strange to be doing something like docker run gazebo:gzserver and have that not actually run the server.

I'm also a little curious on the naming convention here. Is "Gazebo" the name of a collection of utilities, or the name of a single utility? Are there going to be more tags here at some point in the future? If the gzserver is something you'd actually run independently, I think gzserver:5 might be a better way to organize this (or even just gazebo:5 if it's common to refer to the server portion as "Gazebo").

It might even make more sense to have these live under a separate discrete gazebo/gzserver image, if you've got control of the "gazebo" organization on Docker Hub.

[ruffsl]

Sorry for the delay, @ruffsl. New repos are usually much higher interactivity on review than updates, so a lot of times they'll get pushed back a bit while we deal with the constant deluge of updates.

Hi @tianon , no problem.

I've taken a look at the Dockerfile here, and I don't see any obvious issues with it (given my limited knowledge of Gazebo); I am curious why the default command is bash when it seems like it maybe should be gzserver or something instead? It just feels strange to be doing something like docker run gazebo:gzserver and have that not actually run the server.

That's good point. I've changed the default command to reflect this and run gzserver on startup.

I'm also a little curious on the naming convention here. Is "Gazebo" the name of a collection of utilities, or the name of a single utility? Are there going to be more tags here at some point in the future? If the gzserver is something you'd actually run independently, I think gzserver:5 might be a better way to organize this (or even just gazebo:5 if it's common to refer to the server portion as "Gazebo").

Yes, Gazebo is the name of the project as a whole, and it's sum is comprised to two common components for client and server separation, gzclient and gzserver, as descriped here. And indeed the reason I didn't just leave the repo name as gzserver is that we'd like to eventuly release more tags. Gzweb is currenly in the works, and I have a Dockerfile for this tag too. Though gzweb is still in deveoplment and hasn't been packaged, thus still built from source in the image build. I thought this might be of a security consern and held off from adding the tag.

It might even make more sense to have these live under a separate discrete gazebo/gzserver image, if you've got control of the "gazebo" organization on Docker Hub.

I was thinking of keeping additinal deviants of Gazebo consolodated under our automated build osrf/gazebo repo. This could host tags for GUI components like gzclient, or for GPU driver intergration and tutorial tags.

Let me know what you think.

[psftw]

My 2 cents about naming: In my mind this should be called gzserver and only contain version tags based on that (and maybe some really common variants as well if they are not easy for the community to get elsewhere or build themselves). Something like gzserver:5, gzserver:5.1, gzserver:5.1.0. Per my comments in the docs PR, we won't be able to support the gzclient GUI app as an official image, and I think it would be weird to have a gazebo repo without it. I'm fine with gzweb becoming a separate repo down the road when it's ready.

[ruffsl]

hello @psftw,

My 2 cents about naming: In my mind this should be called gzserver and only contain version tags based on that (and maybe some really common variants as well if they are not easy for the community to get elsewhere or build themselves). Something like gzserver:5, gzserver:5.1, gzserver:5.1.0.

Hmm, another reason I'd be hesitant to use the name gzserver is that it might introduce some recognition issues or confusion for the user-base, as gzserver is not quite as a common vocab or search query as gazebo.

Also, just like how the meta packages for ROS stacked on top of one another, so too do the tags in the official ROS repo fit together; similarly we'd like to structure the metapackages for gazebo likewise. And so gzserver would serve as the core dependency image, then tags like gzeb and gzclient could build from it, as currenlty written in the froms for those unlisted Dockerfiles in the same directory.

A reservation I could think of not to do so, we be if gzweb could be used not only without a gzserver install inside the image, but without the libgazebo-dev libraries as well. Such that, isolating the two into separate repos would then be perfectly viable. Currently however, gzweb relies on libgazebo-dev that come with the gzserver install for messaging. So having the two images would involve either duplicate binaries due to unshared image layers, or having the official gzweb repo building from the official gzserver repo.

At that point, I'd think it'd be easier to maintain and use one repo named gazebo that just had the tags with the bit of hierarchy. So if a user wanted to run gzweb locally, they would only need to pull one tag; not two images, one gzserver and one gzweb, that maybe of subtle different versions that may or may not completely interoperate nicely with each other.

Per my comments in the docs PR, we won't be able to support the gzclient GUI app as an official image, and I think it would be weird to have a gazebo repo without it. I'm fine with gzweb becoming a separate repo down the road when it's ready.

Yep, I agree. That why I plan to host the gzclient tags at an automated build repo under OSRF's own organization account. If users want to experiment mounting GPU devices and and using X server for GUIs, they can play with our org's beta images or just use a local client .deb install. But if they want to deploy cloud simulations, they can easily find and rally around the official repo.

gzserver is just the name we gave to one of the executables, not really the project. Plenty of users run gazebo headless. Like you remarked in docs PR, (and I'll go back and provide more context about use cases in the docs), it's really not that strange. A lot of what researchers and developers need are performance statistics that can be acquired from logs and recordings. Say if you were training a machine learning algorithm for some kind of dynamic motion control on a cluster overnight, evaluating performance for you SLAM methods or planning techniques under various parameter sweeps. GUI clients are nice, but the majority current Gazebo use cases currently are as a headless workhorse for continuous integration in robotics.

What would you recommend for the persistent data? You ask that sense to make that folder to a volume? This folder currently serves as a mainly a dump directory for event logs. Is there a repo that already docs this kind of scenario?

[psftw]

Yup, I agree with your naming justification. As for the volume idea, I don't know enough yet to have a strong opinion about it. I'll wait to see what your recommended use cases look like. Declaring a volume in the Dockerfile forces it on all users and all derived images, so it would need to be a reasonable default thing to do.

[ruffsl]

@psftw , I've added some more detail to docs, but I think I've found a complication with sharing the ~/.gazebo/ volume among multiple containers. They write to the same same statically named log file, so I'm not sure about the best general way to handle that. Maybe that should be left up to the user to decide unless you know of a best practice that fits this?

[psftw]

LGTM. The volume options are described well in the docs and it isn't necessary to add it to the Dockerfile in my opinion.

[ruffsl]

Thanks for your help @psftw.
Guess we'll just hang tight until the other devs get a chance to audit the PR.

[yosifkit]

These seem a bit big. Is there a way they can be slimmed down?

$ docker images gazebo
REPOSITORY          TAG             IMAGE ID            CREATED              VIRTUAL SIZE
gazebo              gzserver5       1836866cb6b6        About a minute ago   1.413 GB
gazebo              latest          1836866cb6b6        About a minute ago   1.413 GB

[ruffsl]

@yosifkit, I'm going to catch up with our Debian Maintainer and see what can be done. I'll get back to you on this.

[ruffsl]

@yosifkit, I've broken out the dev package into its own tag, and so gzserver should be about 566.5 MB, with base trusty image being about 188.4 MB. Users will still be able to run gzserver, e.g. run the tutorial in the docs. But if they need to build any plugin from source, they'll need to either install libgazebo-dev package or pull the libgazebo tag that OSRF can host on our profile. I'll make the appropriate changes to the docs now.

[yosifkit]

I don't really mind the size, I was just trying to make sure all of it was needed for users (ie, would --no-install-recommends help or hurt?).

You could have both tags here if you want (gzserver5 and libgazebo5). I also noticed that you have gzserver6 in your repo but not here, did you want to add that here as well? The review from us should be instant since they are generated from the same template.

[ruffsl]

Oh, ok. I'll move libgazebo tag onto the official repo, and tag it as latest. That way users who want a minimal install will have access to just gzserver, and common users will get the basic libraries by default.

I've tried --no-install-recommends before, but the effect is small, and I think it leaves out some doc packages:

$ apt-get install  libgazebo5-dev=5.1.0*
...
0 upgraded, 642 newly installed, 0 to remove and 1 not upgraded.
Need to get 304 MB of archives.
After this operation, 1268 MB of additional disk space will be used.

$ apt-get install  gazebo5=5.1.0*
...
0 upgraded, 180 newly installed, 0 to remove and 1 not upgraded.
Need to get 118 MB of archives.
After this operation, 387 MB of additional disk space will be used.

$ apt-get install  libgazebo5-dev=5.1.0* --no-install-recommends
...
0 upgraded, 563 newly installed, 0 to remove and 1 not upgraded.
Need to get 241 MB of archives.
After this operation, 1035 MB of additional disk space will be used.

$ apt-get install  gazebo5=5.1.0* --no-install-recommends
...
0 upgraded, 157 newly installed, 0 to remove and 1 not upgraded.
Need to get 105 MB of archives.
After this operation, 314 MB of additional disk space will be used.

v6.0 is being released today! I've got to check the Dockerfile builds before I add it to the PR.

[ruffsl]

@yosifkit, Gazebo v6.0 release has been added to PR.

[tianon]

LGTM

[yosifkit]

LGTM, Build test of #855; 23cd622 (gazebo):

$ url="https://raw.githubusercontent.com/docker-library/official-images/23cd622d7a4e81bad97779a09f9152d5fbc482c8/library/gazebo"
$ bashbrew build "$url"
Fetching gazebo (git://github.com/osrf/docker_images) ...
Processing gazebo:gzserver5 ...
Processing gazebo:libgazebo5 ...
Processing gazebo:gzserver6 ...
Processing gazebo:libgazebo6 ...
Processing gazebo:latest ...
$ bashbrew list --uniq "$url" | xargs test/run.sh
testing gazebo:gzserver5
    'utc' [1/3]...passed
    'cve-2014--shellshock' [2/3]...passed
    'no-hard-coded-passwords' [3/3]...passed
testing gazebo:libgazebo5
    'utc' [1/3]...passed
    'cve-2014--shellshock' [2/3]...passed
    'no-hard-coded-passwords' [3/3]...passed
testing gazebo:gzserver6
    'utc' [1/3]...passed
    'cve-2014--shellshock' [2/3]...passed
    'no-hard-coded-passwords' [3/3]...passed
testing gazebo:libgazebo6
    'utc' [1/3]...passed
    'cve-2014--shellshock' [2/3]...passed
    'no-hard-coded-passwords' [3/3]...passed

[ruffsl]

Thank you guys,
You've all been a great help!
Dont forget about pending docker-library/docs#265