2 years in the past, I wrote A Information to Docker and ROS, which is one in every of my most continuously seen posts — probably as a result of it’s a tough subject and folks had been looking for solutions. Since then, I’ve had the prospect to make use of Docker extra in my work and have picked up some new methods. This was lengthy overdue, however I’ve lastly collected my up to date learnings on this publish.
Just lately, I encountered an article titled ROS Docker; 6 explanation why they aren’t a great match, and I largely agree with it. Nonetheless, the fact is that it’s nonetheless fairly troublesome to make sure a reproducible ROS setting for individuals who haven’t spent years preventing the ROS studying curve and are adept at debugging dependency and/or construct errors… so Docker continues to be very a lot a crutch that we fall again on to get working demos (and generally merchandise!) out the door.
If the article above hasn’t utterly discouraged you from embarking on this Docker journey, please get pleasure from studying.
Revisiting Our Dockerfile with ROS 2
Now that ROS 1 is on its ultimate model and approaching finish of life in 2025, I assumed it might be acceptable to rehash the TurtleBot3 instance repo from the earlier publish utilizing ROS 2.
Many of the huge modifications on this improve should do with ROS 2, together with shopper libraries, launch recordsdata, and configuring DDS. The examples themselves have been up to date to make use of the most recent instruments for conduct bushes: BehaviorTree.CPP 4 / Groot 2 for C++ and py_trees / py_trees_ros_viewer for Python. For extra data on the instance and/or conduct bushes, confer with my Introduction to Conduct Timber publish.
From a Docker standpoint, there aren’t too many variations. Our container format will now be as follows:
We’ll begin by making our Dockerfile, which defines the contents of our picture. Our preliminary base layer inherits from one of many public ROS pictures, osrf/ros:humble-desktop, and units up the dependencies from our instance repository into an underlay workspace. These are outlined utilizing a vcstool repos file.
Discover that we’ve arrange the argument, ARG ROS_DISTRO=humble, so it may be modified for different distributions of ROS 2 (Iron, Rolling, and so on.). Fairly than creating a number of Dockerfiles for various configurations, it is best to attempt utilizing construct arguments like these as a lot as attainable with out being “overly intelligent” in a manner that impacts readability.
ARG ROS_DISTRO=humble
######################################### Base Picture for TurtleBot3 Simulation #########################################FROM osrf/ros:${ROS_DISTRO}-desktop as baseENV ROS_DISTRO=${ROS_DISTRO}SHELL [“/bin/bash”, “-c”]
# Create Colcon workspace with exterior dependenciesRUN mkdir -p /turtlebot3_ws/srcWORKDIR /turtlebot3_ws/srcCOPY dependencies.repos .RUN vcs import < dependencies.repos
# Construct the bottom Colcon workspace, putting in dependencies first.
WORKDIR /turtlebot3_ws
RUN supply /choose/ros/${ROS_DISTRO}/setup.bash
&& apt-get replace -y
&& rosdep set up –from-paths src –ignore-src –rosdistro ${ROS_DISTRO} -y
&& colcon construct –symlink-install
ENV TURTLEBOT3_MODEL=waffle_pi
To construct your picture with a selected argument — let’s say you wish to use ROS 2 Rolling as an alternative — you possibly can do the next… supplied that each one your references to ${ROS_DISTRO} even have one thing that accurately resolves to the rolling distribution.
docker construct -f docker/Dockerfile –build-arg=”ROS_DISTRO=rolling” –target base -t turtlebot3_behavior:base .
I personally have had many points in ROS 2 Humble and later with the default DDS vendor (FastDDS), so I like to modify my default implementation to Cyclone DDS by putting in it and setting an setting variable to make sure it’s all the time used.
# Use Cyclone DDS as middlewareRUN apt-get replace && apt-get set up -y –no-install-recommends ros-${ROS_DISTRO}-rmw-cyclonedds-cppENV RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
Now, we are going to create our overlay layer. Right here, we are going to copy over the instance supply code, set up any lacking dependencies with rosdep set up, and arrange an entrypoint to run each time a container is launched.
############################################ Overlay Picture for TurtleBot3 Simulation ############################################FROM base AS overlay
# Create an overlay Colcon workspaceRUN mkdir -p /overlay_ws/srcWORKDIR /overlay_wsCOPY ./tb3_autonomy/ ./src/tb3_autonomy/COPY ./tb3_worlds/ ./src/tb3_worlds/RUN supply /turtlebot3_ws/set up/setup.bash && rosdep set up –from-paths src –ignore-src –rosdistro ${ROS_DISTRO} -y && colcon construct –symlink-install
# Arrange the entrypointCOPY ./docker/entrypoint.sh /ENTRYPOINT [ “/entrypoint.sh” ]
The entrypoint outlined above is a Bash script that sources ROS 2 and any workspaces which are constructed, and units up setting variables essential to run our TurtleBot3 examples. You should use entrypoints to do every other forms of setup you may discover helpful to your software.
#!/bin/bash# Primary entrypoint for ROS / Colcon Docker containers
# Supply ROS 2source /choose/ros/${ROS_DISTRO}/setup.bash
# Supply the bottom workspace, if builtif [ -f /turtlebot3_ws/install/setup.bash ]thensource /turtlebot3_ws/set up/setup.bashexport TURTLEBOT3_MODEL=waffle_piexport GAZEBO_MODEL_PATH=$GAZEBO_MODEL_PATH:$(ros2 pkg prefix turtlebot3_gazebo)/share/turtlebot3_gazebo/modelsfi
# Supply the overlay workspace, if builtif [ -f /overlay_ws/install/setup.bash ]thensource /overlay_ws/set up/setup.bashexport GAZEBO_MODEL_PATH=$GAZEBO_MODEL_PATH:$(ros2 pkg prefix tb3_worlds)/share/tb3_worlds/modelsfi
# Execute the command handed into this entrypointexec “$@”
At this level, it is best to be capable of construct the total Dockerfile:docker construct -f docker/Dockerfile –target overlay -t turtlebot3_behavior:overlay .
Then, we will begin one in every of our instance launch recordsdata with the correct settings with this mouthful of a command. Most of those setting variables and volumes are wanted to have graphics and ROS 2 networking functioning correctly from inside our container.
docker run -it –net=host –ipc=host –privileged –env=”DISPLAY” –env=”QT_X11_NO_MITSHM=1″ –volume=”/tmp/.X11-unix:/tmp/.X11-unix:rw” –volume=”${XAUTHORITY}:/root/.Xauthority” turtlebot3_behavior:overlay bash -c “ros2 launch tb3_worlds tb3_demo_world.launch.py”
Introducing Docker Compose
From the previous couple of snippets, we will see how the docker construct and docker run instructions can get actually lengthy and unwieldy as we add extra choices. You possibly can wrap this in a number of abstractions, together with scripting languages and Makefiles… however Docker has already solved this drawback via Docker Compose.
Briefly, Docker Compose permits you to create a YAML file that captures all of the configuration wanted to arrange constructing pictures and working containers.
Docker Compose additionally differentiates itself from the “plain” Docker command in its capability to orchestrate providers. This entails constructing a number of pictures or targets inside the identical picture(s) and launching a number of packages on the identical time that comprise a complete software. It additionally enables you to lengthen current providers to attenuate copy-pasting of the identical settings in a number of locations, outline variables, and extra.
The tip aim is that we’ve got quick instructions to handle our examples:
docker compose construct will construct what we’d like
docker compose up will launch what we’d like
The default title of this magical YAML file is docker-compose.yaml. For our instance, the docker-compose.yaml file appears as follows:
model: “3.9”providers:# Base picture containing dependencies.base:picture: turtlebot3_behavior:basebuild:context: .dockerfile: docker/Dockerfileargs:ROS_DISTRO: humbletarget: base# Interactive shellstdin_open: truetty: true# Networking and IPC for ROS 2network_mode: hostipc: host# Wanted to show graphical applicationsprivileged: trueenvironment:# Wanted to outline a TurtleBot3 mannequin type- TURTLEBOT3_MODEL=${TURTLEBOT3_MODEL:-waffle_pi}# Permits graphical packages within the container.- DISPLAY=${DISPLAY}- QT_X11_NO_MITSHM=1- NVIDIA_DRIVER_CAPABILITIES=allvolumes:# Permits graphical packages within the container.- /tmp/.X11-unix:/tmp/.X11-unix:rw- ${XAUTHORITY:-$HOME/.Xauthority}:/root/.Xauthority
# Overlay picture containing the instance supply code.overlay:extends: baseimage: turtlebot3_behavior:overlaybuild:context: .dockerfile: docker/Dockerfiletarget: overlay
# Demo worlddemo-world:extends: overlaycommand: ros2 launch tb3_worlds tb3_demo_world.launch.py
# Conduct demo utilizing Python and py_treesdemo-behavior-py:extends: overlaycommand: >ros2 launch tb3_autonomy tb3_demo_behavior_py.launch.pytree_type:=${BT_TYPE:?}enable_vision:=${ENABLE_VISION:?}target_color:=${TARGET_COLOR:?}
# Conduct demo utilizing C++ and BehaviorTree.CPPdemo-behavior-cpp:extends: overlaycommand: >ros2 launch tb3_autonomy tb3_demo_behavior_cpp.launch.pytree_type:=${BT_TYPE:?}enable_vision:=${ENABLE_VISION:?}target_color:=${TARGET_COLOR:?}
As you possibly can see from the Docker Compose file above, you possibly can specify variables utilizing the acquainted $ operator in Unix based mostly methods. These variables will by default be learn from both your host setting or via an setting file (often referred to as .env). Our instance.env file appears like this:
# TurtleBot3 modelTURTLEBOT3_MODEL=waffle_pi
# Conduct tree kind: Could be naive or queue.BT_TYPE=queue
# Set to true to make use of imaginative and prescient, else false to solely do navigation behaviors.ENABLE_VISION=true
# Goal coloration for imaginative and prescient: Could be crimson, inexperienced, or blue.TARGET_COLOR=blue
At this level, you possibly can construct every little thing:
# By default, picks up a `docker-compose.yaml` and `.env` file.docker compose construct
# You can too explicitly specify the filesdocker compose –file docker-compose.yaml –env-file .env construct
Then, you possibly can run the providers you care about:
# Convey up the simulationdocker compose up demo-world
# After the simulation has began,# launch one in every of these in a separate Terminaldocker compose up demo-behavior-pydocker compose up demo-behavior-cpp
Establishing Developer Containers
Our instance thus far works nice if we wish to bundle up working examples to different customers. Nonetheless, if you wish to develop the instance code inside this setting, you’ll need to beat the next obstacles:
Each time you modify your code, you’ll need to rebuild the Docker picture. This makes it extraordinarily inefficient to get suggestions on whether or not your modifications are working as meant. That is already an instantaneous deal-breaker.
You possibly can resolve the above by utilizing bind mounts to sync up the code in your host machine with that within the container. This will get us heading in the right direction, however you’ll discover that any recordsdata generated contained in the container and mounted on the host can be owned by root as default. You may get round this by whipping out the sudo and chown hammer, but it surely’s not mandatory.
All of the instruments it’s possible you’ll use for growth, together with debuggers, are probably lacking contained in the container… except you put in them within the Dockerfile, which might bloat the dimensions of your distribution picture.
Fortunately, there’s a idea of a developer container (or dev container). To place it merely, this can be a separate container that allows you to truly do your growth in the identical Docker setting you’ll use to deploy your software.
There are numerous methods of implementing dev containers. For our instance, we are going to modify the Dockerfile so as to add a brand new dev goal that extends our current overlay goal.
This dev container will do the next:
Set up extra packages that we might discover useful for growth, equivalent to debuggers, textual content editors, and graphical developer instruments. Critically, these is not going to be a part of the overlay layer that we’ll ship to finish customers.
Create a brand new person that has the identical person and group identifiers because the person that constructed the container on the host. It will make it such that each one recordsdata generated inside the container (in folders we care about) have the identical possession settings as if we had created the file on our host. By “folders we care about”, we’re referring to the ROS workspace that comprises the supply code.
Put our entrypoint script within the person’s Bash profile (~/.bashrc file). This lets us supply our ROS setting not simply at container startup, however each time we connect a brand new interactive shell whereas our dev container stays up.
###################### Improvement Picture ######################FROM overlay as dev
# Dev container argumentsARG USERNAME=devuserARG UID=1000ARG GID=${UID}
# Set up additional instruments for developmentRUN apt-get replace && apt-get set up -y –no-install-recommends gdb gdbserver nano
# Create new person and residential directoryRUN groupadd –gid $GID $USERNAME && useradd –uid ${GID} –gid ${UID} –create-home ${USERNAME} && echo ${USERNAME} ALL=(root) NOPASSWD:ALL > /and so on/sudoers.d/${USERNAME} && chmod 0440 /and so on/sudoers.d/${USERNAME} && mkdir -p /house/${USERNAME} && chown -R ${UID}:${GID} /house/${USERNAME}
# Set the possession of the overlay workspace to the brand new userRUN chown -R ${UID}:${GID} /overlay_ws/
# Set the person and supply entrypoint within the person’s .bashrc fileUSER ${USERNAME}RUN echo “supply /entrypoint.sh” >> /house/${USERNAME}/.bashrc
You possibly can then add a brand new dev service to the docker-compose.yaml file. Discover that we’re including the supply code as volumes to mount, however we’re additionally mapping the folders generated by colcon construct to a .colcon folder on our host file system. This makes it such that generated construct artifacts persist between stopping our dev container and bringing it again up, in any other case we’d should do a clear rebuild each time.
dev:extends: overlayimage: turtlebot3_behavior:devbuild:context: .dockerfile: docker/Dockerfiletarget: devargs:- UID=${UID:-1000}- GID=${UID:-1000}- USERNAME=${USERNAME:-devuser}volumes:# Mount the supply code- ./tb3_autonomy:/overlay_ws/src/tb3_autonomy:rw- ./tb3_worlds:/overlay_ws/src/tb3_worlds:rw# Mount colcon construct artifacts for sooner rebuilds- ./.colcon/construct/:/overlay_ws/construct/:rw- ./.colcon/set up/:/overlay_ws/set up/:rw- ./.colcon/log/:/overlay_ws/log/:rwuser: ${USERNAME:-devuser}command: sleep infinity
At this level you are able to do:
# Begin the dev containerdocker compose up dev
# Connect an interactive shell in a separate Terminal# NOTE: You are able to do this a number of instances!docker compose exec -it dev bash
As a result of we’ve got mounted the supply code, you may make modifications in your host and rebuild contained in the dev container… or you need to use useful instruments just like the Visible Studio Code Containers extension to instantly develop contained in the container. As much as you.
For instance, when you’re contained in the container you possibly can construct the workspace with:
colcon construct
As a consequence of our quantity mounts, you’ll see that the contents of the .colcon/construct, .colcon/set up, and .colcon/log folders in your host have been populated. Which means should you shut down the dev container and produce up a brand new occasion, these recordsdata will live on and can velocity up rebuilds utilizing colcon construct.
Additionally, as a result of we’ve got gone via the difficulty of creating a person, you’ll see that these recordsdata will not be owned by root, so you possibly can delete them should you’d like to wash out the construct artifacts. You must do that with out making the brand new person and also you’ll run into some annoying permissions roadblocks.
$ ls -al .colcontotal 20drwxrwxr-x 5 sebastian sebastian 4096 Jul 9 10:15 .drwxrwxr-x 10 sebastian sebastian 4096 Jul 9 10:15 ..drwxrwxr-x 4 sebastian sebastian 4096 Jul 9 11:29 builddrwxrwxr-x 4 sebastian sebastian 4096 Jul 9 11:29 installdrwxrwxr-x 5 sebastian sebastian 4096 Jul 9 11:31 log
The idea of dev containers is so widespread at this level that a typical has emerged at containers.dev. I additionally wish to level out another nice assets together with Allison Thackston’s weblog, Griswald Brooks’ GitHub repo, and the official VSCode dev containers tutorial.
Conclusion
On this publish, you’ve gotten seen how Docker and Docker Compose might help you create reproducible ROS 2 environments. This consists of the flexibility to configure variables at construct and run time, in addition to creating dev containers that will help you develop your code in these environments earlier than distributing it to others.
We’ve solely scratched the floor on this publish, so ensure you poke round on the assets linked all through, check out the instance repository, and usually keep interested in what else you are able to do with Docker to make your life (and your customers’ lives) simpler.
As all the time, please be happy to succeed in out with questions and suggestions. Docker is a extremely configurable instrument, so I’m genuinely interested in how this works for you or whether or not you’ve gotten approached issues otherwise in your work. I’d be taught one thing new!
Sebastian Castro
is a Senior Robotics Engineer at PickNik.