I’m excited to share ROS Dev Container Templates! If you’re looking to ease your ROS development environment setup process in Visual Studio Code, this template might be for you.
Why Use Dev Containers?
Dev containers offer a standardized and reproducible development environment. They encapsulate all the dependencies, tools, and settings needed for your project, ensuring consistency across different development setups.
Why Use Dev Container Templates?
Dev container templates aim to simplify and standardize the dev container setup process. You don’t have to search for an example Dockerfile and devcontainer.json. Instead, you can generate a basic Dockerfile and devcontainer.json through the command palette in VS Code!
About the ROS Dev Container Template
The ROS Dev Container Template is designed to get you up and running with ROS in a matter of minutes (or even seconds!). It is especially useful for:
Developers who want to spin up a workspace in a clean Docker container to test out a package they found on GitHub.
Package maintainers who want to quickly spin up workspaces across different ROS distros to test them. (Oh, and did you know that you can set up multiple dev containers in a workspace?)
For a detailed walkthrough and demonstration, click on the thumbnail below to watch a video from Articulated Robotics. The video covers everything from using the templates to common modifications you may want to make to your dev container files.
Feel free to ask any questions or provide feedback. I’m looking forward to hearing how this template helps streamline your ROS development process!
Recent news - Templates for 24.04-based images (ie. jazzy / rolling) are working now (Details)
One thing that is missing from both the community support documentation and this repository is the proper configuration of the pid and ipc docker options to allow containers to communicate with each other via shared memory. As shared memory is enabled by default in Fast DDS, failure to configure the pid and ipc options can lead to confusing behavior where subscribers can discover topics but not receive any data.
There are also some other issues with the community support documentation, such as hard-coding the DISPLAY variable instead of taking it from the host, but that can be addressed via an update there,
Can you explain the reasoning for using the --privileged option? I have been able to get running with hardware with a docker container without it. Hardware does require some tricks in some cases.
i think that is to give the permission to access devices in the host system from the container in general, instead of binding each device to the container.
That makes sense; I suppose since it’s a development container it doesn’t matter too much on the security end. I’ve been using this on my docker run command to get similar results:
thanks for sharing.
thanks for pointing those out. I will track them.