Docker ROS2 容器化开发

解决的问题

ROS2 开发环境的一致性问题远比“装个 Docker”复杂。同一个 workspace，在开发者机器、CI 服务器、目标机器人上行为不一致，根源往往是 DDS 实现、CUDA 版本、系统依赖这些隐藏变量。ROS2 的分布式通信依赖 DDS 发现机制，而容器默认的网络隔离与组播行为和宿主机不同，容器间的节点经常互相“看不见”。涉及视觉、激光雷达的感知节点还需要 GPU 和 USB 设备透传，rviz2、rqt 等可视化工具又依赖显示服务转发。

技能如何工作

这个技能把上述问题拆解为可执行的工程任务：

• 镜像分层选择：基于 OSRF 官方镜像的分层体系，只选满足依赖的最小基础镜像，避免镜像臃肿拖慢构建。
• DDS 发现调试：覆盖 CycloneDDS 与 FastDDS 两种实现的配置差异，定位共享内存、组播、单播回环等典型故障点。
• 硬件透传：通过 NVIDIA Container Toolkit 配置 GPU 直通；用 --device 映射 USB 摄像头、激光雷达和串口设备；通过 X11 或 Wayland 转发让 rviz2、rqt 在容器内渲染到宿主机显示。
• 编排与开发体验：用 docker-compose 组织多容器机器人系统；用多阶段构建区分开发镜像（含 colcon 工具链与调试器）和部署镜像（仅运行时依赖）。
• 缓存与流水线：优化 colcon workspace 的 Docker layer 缓存，避免依赖重装触发全量重建；搭建 Docker 化的 CI/CD 构建与测试运行环境；配置带 ROS2 扩展的 VS Code devcontainer，让 IDE 直接挂载进容器。

适用边界与注意点

• 技能聚焦容器化工程实践，不涉及 ROS2 节点逻辑本身，应用层代码质量仍取决于开发者。
• 镜像选择依赖项目实际的 ROS2 发行版与依赖项，分层建议是决策框架而非唯一答案。
• GPU 与 USB 透传依赖宿主机硬件与驱动，跨平台迁移时需重新验证。
• DDS 调试结论随网络环境（bridge 模式、CNI 插件）变化，应在与生产一致的拓扑中测试。