Docker 多版本 ROS：图形、GPU 与 micro-ROS 避坑

上周帮朋友清理他那台开发本/home底下躺着三套 ROS双系统 20.04 分区里的 Noetic、22.04 分区里的 Humble还有一台虚拟机跑着 Jazzy。他说每次想复现一个老教程第一件事不是写代码而是先花二十分钟重启切换环境编译一次再等十分钟。我当时给他的建议就一句话别跟系统版本死磕了把 ROS 塞进 Docker十几个版本随便切删一个环境只要两秒。这篇东西就是把这套做法从头到尾讲透。Docker 一键安装 ROS 这件事本身不复杂docker run一行命令就能跑起来但真正决定你能不能长期用下去的是十几个版本怎么对应镜像标签、图形界面怎么转发、GPU 怎么挂进去、容器里生成的文件为什么全是 root 属主、micro-ROS 的串口设备怎么透传。这些坑我基本都踩过一遍下面按顺序讲清楚。适合刚接触 ROS 的同学也适合被多版本环境折腾很久、想找个干净方案的老手。1. 版本地狱是真事我为什么把整套 ROS 环境塞进 Docker1.1 一台机器装三个 ROS 版本的隐性成本ROS 1 的时代版本和 Ubuntu 是硬绑定的Kinetic 只能装 16.04Melodic 只能装 18.04Noetic 只能装 20.04。ROS 2 稍微好一点但同样绑得死死的Humble 对应 22.04Jazzy 对应 24.04。你想在一台 24.04 的机器上跑一个只支持 Noetic 的老包原生安装基本没戏。更难受的是依赖污染。ROS 的 apt 源一旦加进系统apt upgrade就可能顺手把系统里的 Python、OpenCV、Boost 版本往上顶一档然后你某个编译得好好的包突然就链接失败了。卸载呢apt remove ros-noetic-*删不干净残留的/opt/ros目录和环境变量会在你装下一个版本时继续捣乱。我自己统计过一笔账原生方式装一个完整桌面版 ROS从换源、装依赖、rosdep 初始化到能跑起 Gazebo顺利的话四十分钟不顺利两个小时。三个版本就是三倍时间而且这套成本在换电脑、重装系统的时候要再来一遍。1.2 Docker 真正隔离掉的是什么又没有隔离掉什么很多人对容器有个误解觉得它是个轻量虚拟机。实际上 Docker 隔离的是文件系统、进程视图、网络栈和用户空间依赖共享的是宿主机的内核。这个特性对 ROS 来说刚好合适ROS 的绝大部分麻烦都出在用户空间的库版本冲突上而内核部分我们并不需要动。反过来讲Docker 解决不了的问题也要说清楚。硬实时场景下容器会引入额外调度抖动做机械臂力控这种微秒级要求的工作容器方案不合适老老实实上实时内核。GPU 也不是自动可用的NVIDIA 卡要装容器工具链Intel 核显要把/dev/dri挂进去否则 RViz2 和 Gazebo 会退化到软件渲染帧率低到没法看。这些在后面第 5 节会详细讲。一句话总结这一节Docker 解决的是版本和可复现不解决实时性和性能。想明白这条边界后面的技术选型就不会走偏。2. 十四个 ROS/ROS2 版本怎么选底包、镜像标签与生命周期对照2.1 版本、Ubuntu 底包与镜像标签对照表一键脚本菜单里之所以能列出十几个选项是因为官方镜像仓库把这些版本都保留着。下面这张表是我自己常用的对照关系注意镜像标签以实际拉取时仓库里的 tag 为准个别老版本可能已经下架。序号发行版代际Ubuntu 底包常用镜像标签1KineticROS 116.04ros:kinetic-ros-base2MelodicROS 118.04ros:melodic-ros-base3NoeticROS 120.04ros:noetic-ros-base4DashingROS 218.04ros:dashing5EloquentROS 218.04ros:eloquent6FoxyROS 220.04ros:foxy7GalacticROS 220.04ros:galactic8HumbleROS 222.04ros:humble9Humble 桌面版ROS 222.04osrf/ros:humble-desktop-full10IronROS 222.04ros:iron11JazzyROS 224.04ros:jazzy12Jazzy 桌面版ROS 224.04osrf/ros:jazzy-desktop-full13RollingROS 224.04ros:rolling14Noetic 感知版ROS 120.04ros:noetic-perception如果你要长期维护项目我的建议只有一个只选 LTS 版本。ROS 1 里选 NoeticROS 2 里选 Humble 或 Jazzy。Humble 的支持周期到 2027 年Jazzy 到 2029 年中间不用折腾升级。Iron、Galactic、Foxy 这些非 LTS 版本生命周期只有一到两年等你项目上线时可能已经在 EOL 列表里躺着了。老版本存在的意义只有一个跑别人写好的、来不及迁移的历史代码。2.2 base、ros-core、perception、desktop 四种镜像到底差在哪同一个版本下面往往有好几个标签很多人第一次看会懵。差别其实就一句话装了多少东西。ros-core最小只有核心通信库和构建工具镜像大概几百兆适合当基础层自己往上叠。ros-base在 core 基础上加了常用工具链、colcon、rosdep之类日常开发够用。perception额外带了 PCL、OpenCV、图像处理相关的包做视觉和点云的选它。desktop/desktop-full最全包含 RViz、Gazebo、各种教程包和仿真插件镜像体积能到三四个 G。这里有个实际经验如果你要用 Gazebo 做仿真别在ros-base上手动装gazebo_ros_pkgs依赖关系容易解错装完跑起来缺插件是常事。直接用desktop-full起手多花两三个 G 的磁盘省下的是半天排查时间。磁盘不够可以先docker system prune清一遍再拉。3. 宿主机这一层Linux 与 Windows/WSL2 的准备工作差异3.1 Linux 侧装 Docker Engine 和免 sudo 配置Linux 是三端里最省事的因为--nethost、/dev/dri、X11 socket 这些机制都原生可用。安装建议走官方 apt 仓库不要用发行版自带的老版本包sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \ sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] \ https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo usermod -aG docker $USER最后那条usermod加完组要重新登录才生效很多人在这里卡住一直sudo docker用着结果容器里生成的文件属主全是 root后面第 7 节会专门讲这个问题。验证就两步docker version能看到 Server 端信息docker run --rm hello-world能打印出提示环境就算通了。3.2 Windows 用户的 Docker Desktop 与 WSL2 必调项Windows 侧现在的标准路径是 Docker Desktop 加 WSL2 后端。装之前确认 BIOS 里虚拟化是开着的然后在 PowerShell 里跑wsl --install -d Ubuntu-22.04 wsl --set-default-version 2 wsl --update装完 Docker Desktop 之后一定要去设置里把Resources WSL Integration打开并且勾上你用的那个发行版。这一步没做的话WSL 里敲docker会提示找不到命令。有两个坑必须提前说。第一是代码别放在/mnt/c/下面。WSL2 访问 Windows 盘符走的是 9P 协议colcon build一个小工作空间能慢到让你怀疑人生放到 WSL 自己的~/ros_ws里速度能差十倍以上。第二是内存占用WSL2 默认会吃掉宿主机一半内存跑 Gazebo 的时候容易把整个系统拖卡可以在用户目录下建.wslconfig限制一下[wsl2] memory12GB processors6 swap4GBWindows 上图形界面靠 WSLg 转发比早年折腾 X Server 舒服太多具体配置放在 5.2 节讲。3.3 macOS 与 arm64 平台的现实情况macOS 上 Docker Desktop 跑的是虚拟机没有--nethost没有/dev/driROS 2 的 DDS 组播发现也容易出问题。日常写代码、跑纯算法节点是可以的但 Gazebo 仿真基本别想帧率个位数。真的要在 Mac 上做机器人开发建议把仿真部分放到局域网里的 Linux 机器上Mac 只当开发终端两个容器配同一个ROS_DOMAIN_ID做分布式通信也就是第 6 节要讲的内容。另外 M 系列芯片是 arm64 架构拉镜像前先确认有没有对应架构的版本docker manifest inspect ros:humble | grep architecture如果只有 amd64Docker Desktop 会用 QEMU 模拟能跑但速度感人。这种时候要么换用有 arm64 支持的版本要么干脆上云主机。顺带提一句安装方式的选择社区里有不少成熟的一键安装脚本比如常被提到的鱼香 ROS 脚本走的是原生 apt 安装路线装完就是一个干净的宿主环境。如果你的机器只打算用一个 ROS 版本那类脚本足够了但一旦要在同一台机器上并存多个版本Docker 方案的边际成本几乎为零这也是我最终选它的原因。4. 一键安装脚本拆开看它到底替你做了哪些事4.1 脚本的四个阶段与设计思路所谓一键安装本质是把下面四步串起来任何声称一键的脚本都跑不出这个框架环境体检确认 Docker 装没装、守护进程起没起、是不是 Linux、有没有独显、~/.X11-unix在不在。镜像准备先docker image inspect看本地有没有没有再docker pull避免每次重复下载几个 G。容器创建把一大堆docker run参数按当前环境拼装出来这部分是整个脚本的核心。进入与初始化source环境变量创建工作空间目录然后开一个交互式 shell。为什么第一步要做本地检查而不是无脑 pull因为ros:humble和osrf/ros:humble-desktop-full加起来能占七八个 G一个几十行的判断能省下大量带宽和等待时间。同理第三步里所有可选参数显卡设备、串口、X11 目录都要用if [ -e ... ]包起来不然在没独显的笔记本上会直接报错退出。4.2 关键启动参数逐条解释docker run的参数多到让人头大但真正必要的就那么几个我按重要性排一下--nethost让容器直接用宿主机网络栈。这是 ROS 场景下最重要的一条DDS 的组播发现、ROS 1 的 11311 端口、micro-ROS 的 UDP 8888 全都依赖它。只在 Linux 上有效。--ipchost与--shm-size1g共享内存相关。RViz2 基于 QtQt 的共享内存机制在没有 IPC 共享时会直接崩DDS 的大消息传输也依赖/dev/shm。默认 64M 太小。-v /tmp/.X11-unix:/tmp/.X11-unix:rw加-e DISPLAY$DISPLAY图形界面转发的两条命脉缺一个 RViz 就报 cannot connect to X server。-v $WS:/root/ros_ws把宿主机工作空间挂进去代码在宿主机编辑容器里编译。--device/dev/driIntel 或 AMD 核显直通让 Gazebo 有硬件加速。--group-add dialout串口访问权限注意要用 GID 而不是名字具体原因见 8.1。-e TZAsia/Shanghai加-v /etc/localtime:/etc/localtime:ro时区不设置的话日志时间全是 UTC排查问题时会很别扭。--privileged除非你知道自己在干什么否则不要加。它等于把宿主机设备全部敞开放进容器。关于-it和-d的选择我的建议是用-d后台跑再用docker exec进去而不是-it直接开前台会话。理由是这样终端断了容器不会跟着死长时间编译的时候不用一直挂着 SSH。4.3 一份可以直接抄的脚本#!/usr/bin/env bash set -euo pipefail ROS_DISTRO${1:-humble} IMAGEros:${ROS_DISTRO} CONTAINERros_${ROS_DISTRO} WS${WS:-$HOME/ros_ws} # 阶段一环境体检 command -v docker /dev/null || { echo 未检测到 docker请先安装; exit 1; } docker info /dev/null 21 || { echo docker 守护进程未运行; exit 1; } mkdir -p $WS/src # 阶段二镜像准备 if ! docker image inspect $IMAGE /dev/null 21; then echo 本地无 $IMAGE开始拉取... docker pull $IMAGE fi # 阶段三参数拼装 OPT() [ -d /tmp/.X11-unix ] OPT(-v /tmp/.X11-unix:/tmp/.X11-unix:rw -e DISPLAY$DISPLAY -e QT_X11_NO_MITSHM1) [ -e /dev/dri ] OPT(--device/dev/dri) DIALOUT_GID$(getent group dialout | cut -d: -f3 || true) [ -n ${DIALOUT_GID:-} ] OPT(--group-add $DIALOUT_GID) # 容器已存在就直接启动 if docker container inspect $CONTAINER /dev/null 21; then docker start $CONTAINER /dev/null else docker run -d \ --name $CONTAINER \ --hostname $CONTAINER \ --nethost --ipchost --shm-size1g \ -e TZAsia/Shanghai \ -v /etc/localtime:/etc/localtime:ro \ -v $WS:/root/ros_ws \ ${OPT[]} \ -w /root/ros_ws \ $IMAGE \ bash -c sleep infinity fi # 阶段四进入 docker exec -it $CONTAINER bash -lc \ source /opt/ros/$ROS_DISTRO/setup.bash exec bash用法就是./ros_docker.sh humble想换版本把参数改成jazzy、noetic都行脚本会自动拉对应的镜像、用对应名字建容器。4.4 一个很多人不知道的细节ENTRYPOINT 只在启动时生效rocker 或者官方 ros 镜像里有个/ros_entrypoint.sh它会在容器启动时自动source /opt/ros/$ROS_DISTRO/setup.bash。但docker exec进去的新 shell 不会走 entrypoint所以你会发现ros2 topic list报 command not found。解决办法就是在 exec 命令里手动 source上面脚本最后一行就是这么处理的。如果你嫌每次敲命令麻烦可以在宿主机的~/.bashrc里加一个别名alias roshdocker exec -it ros_humble bash -lc source /opt/ros/humble/setup.bash exec bash alias rosjdocker exec -it ros_jazzy bash -lc source /opt/ros/jazzy/setup.bash exec bash这样两个版本的容器同时跑着敲rosh进 Humble敲rosj进 Jazzy互不干扰。注意这时候两个容器都用了--nethost如果都跑 roscore 会抢 11311 端口ROS 2 则要靠ROS_DOMAIN_ID区分。5. RViz2 和 Gazebo 白屏黑屏图形与 GPU 的完整链路5.1 X11 转发的原理与 xhost 的安全边界容器里的 RViz2 要画窗口得把图形指令发到宿主机的 X 服务上。具体链路是容器内进程读DISPLAY环境变量得知往哪发通过挂载进去的/tmp/.X11-unix这个 Unix socket 连上宿主机 X 服务然后宿主机 X 服务要检查这个客户端有没有权限连我这就是xhost存在的意义。默认情况下容器里的 root 用户是被拒绝的所以必须授权。很多人图省事直接xhost 这等于把 X 服务对全网开放同一局域网里任何人都能截屏、注入键盘事件非常危险。正确做法是只授权本机特定用户xhost si:localuser:$USER如果容器里用的是 root 身份那就授权本机 root。更严格的方案是给容器建一个和宿主机同 UID 的用户这样授权粒度更细同时也顺手解决了第 7 节的文件属主问题。5.2 WSLg 场景下怎么配Windows 用户的运气比几年前好太多了WSL2 自带的 WSLg 会提供一个 X Server 和 Wayland 合成器/tmp/.X11-unix在 WSL 里是自动挂载的。你只需要确认echo $DISPLAY有输出通常是:0然后启动脚本里把 DISPLAY 和 socket 目录一起传进去就行。不需要装 VcXsrv也不需要跑xhost。实测下来 WSLg 跑 RViz2 没问题Gazebo 会有点卡因为 WSLg 的渲染走的是宿主机的 D3D 转译路径。如果卡到不能忍可以试试在.wslconfig里加guiApplicationsfalse然后换成外部 X Server但配置复杂度会上去不是必须的话不建议折腾。5.3 NVIDIA 独显与 Intel 核显的两条路径NVIDIA 的路子是装nvidia-container-toolkit配好之后启动参数加--gpus all再补两个环境变量docker run --gpus all \ -e NVIDIA_VISIBLE_DEVICESall \ -e NVIDIA_DRIVER_CAPABILITIESall \ ...装完之后一定要验证别以为参数加了就生效进容器跑nvidia-smi看有没有设备再跑glxinfo -B看渲染器是不是NVIDIA开头。如果显示llvmpipe说明还在软件渲染。Intel 核显简单得多不需要额外工具链把/dev/dri挂进去、把用户加进video组基本就通了。注意/dev/dri在容器里的权限继承自宿主机如果宿主机用户不在video组里容器里照样访问不了。不管哪种方案都建议额外装一个mesa-utils用来跑glxinfo验证。仿真跑得慢、画面一卡一卡的时候第一个要排除的就是它到底有没有用上 GPU这个判断只要一条命令。6. 容器之间、容器与宿主机之间通不上网络与 DDS 的排查顺序6.1 --nethost、ROS_DOMAIN_ID 与 ROS_LOCALHOST_ONLY 的配合ROS 2 的通信发现机制靠的是组播。容器默认的 bridge 网络是不转发组播的所以如果你用-p做端口映射会发现一个诡异的现象ros2 topic list只看得到自己发的看不到别人。这不是 bug是网络模型决定的。Linux 上最省事的做法就是--nethost容器和宿主机共享网络栈组播直接通。多个容器也都能看到彼此——这既是优点也是坑同一台机器上跑多个团队的项目时话题会互相串。这时候用ROS_DOMAIN_ID隔离取值范围 0 到 232-e ROS_DOMAIN_ID7如果只是单机测试不想让流量跑到局域网上去可以再加-e ROS_LOCALHOST_ONLY1把通信限制在回环接口。这个变量在 Humble 里叫ROS_LOCALHOST_ONLY在 Jazzy 之后被新的发现配置取代了跨版本共享时要留意。ROS 1 这边的概念要简单一些就是ROS_MASTER_URI指向 master 所在地址。多容器共享一个 master 的时候ROS_MASTER_URIhttp://127.0.0.1:11311配合--nethost就能直接通。6.2 /dev/shm 导致的时好时坏是最难查的一类问题Humble 默认用的是 Fast DDS它的共享内存传输通道依赖/dev/shm。Docker 容器的/dev/shm默认只有 64MB小话题没事一旦传点云或者图像就会出现消息丢失、节点莫名掉线、日志里飘出Failed to create shared memory这类警告。解法有两个二选一即可--shm-size1g给容器一块独立的共享内存隔离性更好。--ipchost直接共用宿主机的 IPC 命名空间性能最好但容器之间也共享了。我个人的选择是两个都加--ipchost保证 RViz2 的 Qt 不崩--shm-size兜底。排查这类问题的技巧是如果现象是偶尔丢、压力大才丢先怀疑共享内存别怀疑代码。用df -h /dev/shm在容器里看一眼就能确认。6.3 多容器联调时用自定义网络还是 host如果你的场景确实需要网络隔离比如一台服务器上跑好几组学生实验那就得建自定义 bridge 网络还要手动把组播打开配置复杂度不低。我的建议是单机开发、追求省事全部--nethost用ROS_DOMAIN_ID做逻辑隔离。需要模拟多机分布式用自定义 bridge 网络并且把 DDS 的发现方式从组播改成单播配置ROS_STATIC_PEERS或者 DDS 的 XML 配置文件。这条路能走通但调试时间至少翻倍非必要不上。7. 工作空间挂载与文件权限别让 root 生成的文件毁掉你的宿主目录7.1 三种 UID/GID 映射做法的取舍容器里默认是 root往挂载目录写文件就是 root 属主。跑几次colcon build之后宿主机~/ros_ws下面全是root root的文件夹你连删都删不掉得sudo才能清理。这个问题有三种解法方案做法优点缺点运行时指定-u $(id -u):$(id -g)一行搞定容器内没有对应家目录部分工具写缓存会失败镜像内建用户Dockerfile 里useradd同 UID 用户干净彻底每个宿主机 UID 不同镜像不能通用事后修正容器内chown -R应急可用治标不治本每次都要做我自己用的是第二种在 Dockerfile 里通过ARG传 UID构建时生成对应账户。虽然牺牲了镜像的通用性但团队里每人构建一次自己的开发镜像成本可以接受换来的是完全干净的权限关系。7.2 挂载点的选择与构建缓存的处理colcon build会在工作空间里生成build/、install/、log/三个目录。如果把它们也放在挂载卷里Windows 用户会经历地狱级的慢——几万个中间文件要通过 9P 协议来回读写。我的做法是src挂载另外三个用命名卷-v $WS/src:/root/ros_ws/src \ -v ros_humble_build:/root/ros_ws/build \ -v ros_humble_install:/root/ros_ws/install \ -v ros_humble_log:/root/ros_ws/log命名卷存在 Docker 自己的存储区里读写速度接近原生。代价是这些卷跟着容器走换容器时要重新挂。如果你需要install目录在宿主机上可见比如部署时要用那就只把build和log换成命名卷保留install挂载。7.3 软链接与路径穿越的一个隐蔽陷阱宿主机工作空间里如果有指向外部的软链接容器里会看到断链因为那个绝对路径在容器内可能指向完全不同的东西。这在用colcon的--symlink-install时特别容易出问题install目录里全是软链接一旦路径映射不一致运行时就会报找不到库。判断方法很简单在容器里ls -l看一下链接的目标路径find -L . -type l能列出所有断链。修的话要么改成真实拷贝要么把链接目标一起挂进去。这也是为什么我更推荐把整个工作空间放在宿主机、容器只做编译运行而不是在容器里 clone 代码。8. 串口、ESP32 与 micro-ROS硬件透传的正确姿势8.1 --device 与 dialout 组的 GID 问题接 USB 转串口模块的时候光有--device/dev/ttyUSB0还不够因为设备节点的属组是dialout容器里的用户默认不在这个组里打开串口会报Permission denied。有人会说那在容器里usermod -aG dialout不就行了不行。原因是容器里dialout组的 GID 和宿主机很可能不一样。Ubuntu 宿主机的 dialout 通常是 20但基础镜像里可能根本没有这个组。正确做法是把宿主机的 GID 直接传进去--group-add $(getent group dialout | cut -d: -f3) --device/dev/ttyUSB0如果整台机器就你自己用图省事也可以--device-cgroup-rulec 188:* rmw加上挂载整个/dev但不建议多人共用的服务器这么干。8.2 micro-ROS agent 的两种连接方式跑 micro-ROS 的时候agent 一般也放在容器里连接方式取决于开发板怎么上网网络方式开发板通过 Wi-Fi 或者以太网连过来agent 监听 UDP 端口容器用--nethost的时候宿主机网络直接可用什么都不用映射docker run -it --rm --nethost microros/micro-ros-agent:humble udp4 --port 8888 -v6这里的-v6是打开详细日志。刚上手的时候强烈建议开着能看到握手过程比在黑盒里猜快得多。串口方式开发板通过 USB 直接连机器那就把串口设备透传进去docker run -it --rm --nethost \ --device/dev/ttyUSB0 \ --group-add $(getent group dialout | cut -d: -f3) \ microros/micro-ros-agent:humble serial --dev /dev/ttyUSB0 -b 115200 -v6注意 agent 的版本要和固件里的 micro-ROS 版本对齐humble的 agent 配 humble 的固件最稳跨版本经常在握手阶段就卡住。8.3 热插拔与设备名漂移容器在启动的那一刻就把设备节点固定住了拔掉再插上容器里往往还是旧的节点甚至直接消失。这个限制没法绕过只能重启容器。如果开发过程中频繁插拔可以改写一下流程每次插拔后docker restart ros_humble两秒钟的事。另一个更烦人的问题是设备名漂移。同时插两块 USB 转串口板子的时候谁变成ttyUSB0谁变成ttyUSB1是随机的。解决办法是在宿主机上写一条 udev 规则按芯片序列号绑定固定名字SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{serial}xxxx, SYMLINKttyRosBase然后在容器里用/dev/ttyRosBase这个符号链接。这样无论插拔顺序怎么变代码里的设备名都不用改源码里那些写死ttyUSB0的地方也能一次性清理掉。9. 我实际踩过的坑与排查链路9.1 TF 报 extrapolation 错误结果查出来是时钟问题有一次起 RViz2 看机器人模型TF 一直报时间外插值错误看起来像坐标系配置错了。我照着这个方向查了半天ros2 run tf2_tools view_frames打出来的树结构完全正常。后来无意中在容器里敲了date发现和宿主机差了八个时区。原因是容器没挂/etc/localtime虽然时间戳本身是 UTC 一致的但依赖本地时间的节点做时间戳转换时会算错。加上-v /etc/localtime:/etc/localtime:ro -e TZAsia/Shanghai之后问题消失。排查链路是先看 TF 树树正常就怀疑时间时间再对不上就看时区。顺序别搞反不然会在坐标系上白耗一整天。9.2 磁盘被镜像吃掉以及安全的清理顺序十几个版本的镜像加起来轻松上 50G。我的排查顺序固定是这三条docker system df # 看总览镜像、容器、卷、构建缓存各占多少 docker image ls --format {{.Repository}}:{{.Tag}}\t{{.Size}} | sort -k2 -h docker system prune # 清掉悬空镜像和停止的容器第三条命令要小心docker system prune -a --volumes会把当前没用到的镜像和卷全删掉包括那些你手动commit出来但没打标签的成果。比较好的习惯是任何手动改过的容器第一时间docker commit并打上语义化标签否则下次 prune 就找不回来了。9.3 拉取慢和构建慢分别该怎么处理拉取慢是网络问题最干净的解法是让运维在内网搭一个私有 registry 做缓存团队里所有人从内网拉。这个方案一次投入长期受益尤其适合实验室和公司内网。构建慢往往是 apt 源的问题。在 Dockerfile 里换源的时候要注意只对基础镜像里对应的 Ubuntu 版本生效写死focal的源用在 22.04 镜像上会直接报错。稳妥的写法是用$(. /etc/os-release echo $VERSION_CODENAME)动态取和 3.1 节装 Docker 时的写法一样。9.4 两个容易忽略的小坑第一个是 Qt 共享内存。RViz2 启动后闪退日志里没什么有用信息八成就缺--ipchost或-e QT_X11_NO_MITSHM1。第二个是 roscore 端口冲突。两个--nethost的容器如果都跑 ROS 1 的 master后启动的会绑定 11311 失败表现是节点起不来但不报明显错误。检查方式是ss -ltnp | grep 11311看端口被谁占了。10. 从能用到团队共用Dockerfile、compose 与离线分发10.1 用 Dockerfile 固化环境而不是手动改容器容器里apt install装了一堆东西然后docker commit保存——这种做法只适合临时试验。真正要长期维护必须落到 DockerfileFROM ros:humble-ros-base ARG USER_UID1000 ARG USER_GID1000 RUN apt-get update apt-get install -y --no-install-recommends \ ros-humble-desktop \ ros-humble-rmw-cyclonedds-cpp \ python3-colcon-common-extensions \ python3-argcomplete \ mesa-utils \ rm -rf /var/lib/apt/lists/* RUN groupadd -g ${USER_GID} devuser \ useradd -m -u ${USER_UID} -g ${USER_GID} -s /bin/bash devuser \ echo devuser ALL(ALL) NOPASSWD:ALL /etc/sudoers.d/devuser USER devuser WORKDIR /home/devuser/ros_ws RUN echo source /opt/ros/humble/setup.bash /home/devuser/.bashrc这么写有三个好处镜像可以重建、变更可以进版本控制、新人上手只要docker build一条命令。USER_UID用构建参数传入团队里每个人构建时传自己的 UID权限问题自然消失。唯一要注意的是USER指令之后的工作目录和家目录要提前创建好否则后续命令会失败。10.2 用 compose 让多个版本并存当你需要同时跑 Humble 和 Jazzy或者要起一套仿真节点 算法节点 可视化的组合docker run那一长串参数就该收敛到 compose 文件里了services: ros-humble: image: ros:humble container_name: ros_humble network_mode: host ipc: host shm_size: 1gb environment: - DISPLAY${DISPLAY} - ROS_DOMAIN_ID7 - TZAsia/Shanghai volumes: - /tmp/.X11-unix:/tmp/.X11-unix:rw - ./ws:/root/ros_ws devices: - /dev/dri working_dir: /root/ros_ws command: sleep infinity ros-jazzy: image: ros:jazzy container_name: ros_jazzy network_mode: host ipc: host shm_size: 1gb environment: - DISPLAY${DISPLAY} - ROS_DOMAIN_ID8 - TZAsia/Shanghai volumes: - /tmp/.X11-unix:/tmp/.X11-unix:rw - ./ws_jazzy:/root/ros_ws devices: - /dev/dri working_dir: /root/ros_ws command: sleep infinity注意两个服务用了不同的ROS_DOMAIN_ID这是并存的必要条件否则话题会互相污染。docker compose up -d起全部docker compose exec ros-jazzy bash进指定容器。把这份 compose 文件放进项目仓库新同事 clone 下来一条命令就能拥有和你完全一致的环境。10.3 离线分发与版本归档有些实验室机器或者产线设备没有外网这时候docker save/docker load就是救命稻草docker save ros:humble | gzip -1 ros-humble.tar.gz # 拷到目标机器 gunzip -c ros-humble.tar.gz | docker load一个基础版镜像压缩后大概 1G 左右桌面版能到 3G 以上。建议只归档项目实际需要的那个版本别把整个docker images列表打成一个包。还有个容易被忽略的点给镜像打上你们自己的标签再归档。ros:humble这种公共标签过一段时间可能被上游更新重建出来的环境和半年前的不一致排查问题时会出现同样的 Dockerfile 结果不一样的诡异现象。改成myteam/ros-humble:2025-01这种带日期的标签环境才算真正锁死。真要说这套方案用了这么久的最大体会就是环境这东西能写进代码就别写进脑子。Dockerfile 和 compose 文件放进仓库比任何一份安装文档都可靠因为文档会过期代码不会。