Docker ROS 2 Development

Problem: local ROS 2 environments often work but are hard to reproduce

ROS 2 development depends on a colcon workspace, DDS discovery, node toolchains, and device drivers. Installing dependencies directly on the host can introduce version drift, while multi-robot systems often hit container-to-container communication failures, missing rviz2 displays, unavailable cameras or LiDAR devices, and poor CI build caching. This skill targets the engineering problem of aligning development containers with deployment environments.

How it works: generating Docker and ROS 2 configurations

It breaks the task into concrete outputs:
- Write Dockerfiles for ROS 2 workspaces, focusing on dependency setup and colcon build layer caching.
- Use docker-compose for multi-container robotic systems, covering service names, networks, ports, and environment variables.
- Debug DDS discovery failures between containers with CycloneDDS or FastDDS, rather than only starting nodes.
- Configure NVIDIA Container Toolkit GPU passthrough for perception nodes, and handle X11 / Wayland display forwarding for rviz2 and rqt.
- Plan USB device passthrough for cameras, LiDARs, and serial devices.
- Create Docker-based CI/CD pipelines, test runners, and devcontainer configurations for VS Code.
- Choose official OSRF base images according to their layered hierarchy, preferring the smallest image that satisfies dependencies.

Limits

Best for ROS 2 teams that need reproducible dev containers, multi-node debugging, device passthrough, and CI integration. It does not replace ROS 2 node implementation and cannot guarantee hardware bring-up without GPU, display server, or device permissions.