We at Apex.AI have created a Docker image to make it easy to contribute to ROS 2 which we wanted to share with the community. It’s simply an image containing all the dependencies needed to build ROS 2 from source – after starting it, you’re immediately ready to do colcon build. Here it is: Apex.AI Public / ROS2 ADE · GitLab
It is intended to be used as an isolated, standard environment for development with the ADE tool. ADE improves the Docker experience by
Allowing to combine a base image like ours with add-on volumes for IDEs etc. such as VS Code
Automatically mounting a directory on the host as the home directory inside the container. It usually contains the source code, so that changes to the code are persistent, and allows sharing e.g. dotfiles.
Configuring Docker to allow graphical applications to run inside the container
Making it easy to open multiple terminals inside the container
among other niceties. There are currently images for Foxy and Rolling, built nightly – more distributions can be added in the future.
Please try it out and let us know what you think, or open an issue if something doesn’t work.
Awesome! Could we combine our efforts with the existing ros2 Dockerfiles and tags hosted here?
For example, the osrf/ros2:devel tag is quite similar, but also conforms to the same Dockerfile setup layout as the Docker Official Images for ROS defined in the same repo; such as install paths, default entrypoint scripts, set environment variables, installed colcon mixins, etc:
This repo also includes several nightly tags, updated daily, that build from the nightly fat archive compiled from the last successful build job on ci.ros2.org. They are designed to be interchangeable with the Official Library Images, so if one would like to switch the parent image from say ros:rolling to the bleeding edge nightly build without compiling all of ROS2 master yourself, one needs only to change the FROM directive in the Dockerfile to osrf/ros2:nightly.
Here is an excerpt from the repo’s README that describes each current tag available:
This repo contains images specific to ROS 2, and are particularly for development and continuous integration. These may contain experimental features or unstable interfaces for testing the latest ROS 2 branches.
closely mimics the Official Library images as to be interchangeable
Purpose:
intended for development and bootstrapping source builds
when an isolated workspace is needed for dependency checking
Notice:
no pre-built image hosted on Docker Hub
provides many ARG options, like running tests
Note: only core packages are available via these images. An alternative for development is to use the rolling distribution images, while less recent than the nightly they allow you to install many ROS packages from deb.
@ruffsl Thanks for pointing me to this project, I agree it’s worth considering.
How would you get a Dockerfile for Foxy? “Nightly” sounds like it only contains master.
One difference is that in the OSRF images, it looks like the source checkout is actually built, and source and binaries are kept in the container. In ADE, the source would never be used because the repository is mounted into the container’s home directory, so the /opt source checkout adds 430M of weight. Maybe the compiled ROS2 would be useful to some, although I wouldn’t want to get it mixed up with the fresh ROS2 build in the home directory.
.bashrc and entrypoint.sh would be overwritten/ignored by ADE as well, but that’s probably not too bad.
It has been about a year that we discovered ADE and we love it ever since ! It is just great to work with it, we never want to go back to installing the stuff on our machines
It has been a journey for us with ADE, and along the way, as we needed several images for various purposes, we built a series of new image building upon the pre-existing conventions used in your existing Autoware image. We needed to
Have something that really feels like an Ubuntu machine, with all the convenience and command line utilities,
Choose our Ubuntu release : 14.04, 16.04, 18.04, 20.04… depending on the projet to run
Automatically build it upon startup, as both the pull and the build are time taking processes, we needed to speed up the thing
Make it as auto-discoverable as possible for a new user, i.e. respecting the standards and conventions whenever possible, displaying READMEs at the end of the build and such
We also have some needs that we do not yet have a satisfying solution for at the moment :
Use environment variables in the .aderc to choose which project to build on startup (if any), based on .repos files and using vcstool
Be able to archive a project (although I don’t know if it is possible, with dependencies coming from external git repositories and package registries)
It is still somewhat a not very polished work in progress and some reflections are still ongoing.
If you are interested, I would love to have a call to discuss our experience, possible conventions to put in place and how we coule help move this project forward.
I also feel like there is something common and great that is possible with Ruffin’s official ROS 2 images, although I haven’t reflected enough on this subject to come up with anything concrete to imagine.
As a finishing note, there are several things that we still haven’t made publicly available because we didn’t take the time to do it and/or we still do not have definitive solutions for, including
A convenient way to choose which project to auto-build on startup
Packaging AppImages (like http://qgroundcontrol.com/), which is especially difficult for old formats of AppImages without the --extract-and-run option
And stuff that I still don’t know how to go about, like
Packaging Snaps in ade images
Daemons and stuff that depends on systemd, like some snaps (although I don’t remember a particular example at the moment, but I definitely had the need for it at some point)
Sound issues, I couldn’t yet interface it with Alsa
Probably other things that I don’t remember at the moment
I already have made my first contributions for some of the problems that we ran into, but not everything has yet been contributed, either by lack of time or because we are not sure of how you guys see things for this project.
I strongly believe in this project for the future of ROS 2, which is why I am stating again that I would love to discuss it with you guys over a call.
