企业官网建设流程全解析

1. Domain ID 到底在管什么？为什么 Gazebo 和 Autoware 会“失联”

先说一个我经常遇到的现场：一个装了 ROS 2 Humble 的开发机，上面同时有 Gazebo、Autoware，还有一个 micro-ROS 的 ESP32 板子。调试的时候，Rviz2 里只剩下/clock、/rosout、/parameter_events这类固定话题，Gazebo 里的小车怎么发指令都不动，Autoware 的 planning 模块一直提示waiting for map。折腾了半天，ros2 topic list打出来和其他终端完全不一样，最后才发现是终端之间的ROS_DOMAIN_ID不一致。

这类问题在混合开发环境里太常见了，所以我把这套“一键清理 + 切换 Domain”的完整思路整理出来，包括脚本、验证方式、坑位清单，直接照着抄就行。

1.1 从 DDS 发现协议说起：为什么节点会互相看不见

ROS 2 的底层通信不再是 ROS 1 那种中心化的 roscore，而是直接跑在 DDS（Data Distribution Service）之上。DDS 里有一个很关键的概念叫 Domain，你可以把它理解成一个“虚拟局域网分区”，Domain ID 就是这个分区的编号。节点启动时会加入某一个 Domain，只有处在同一个 Domain 里的节点才能通过 DDS 的发现机制互相感知、互相通信。

这个机制带来一个巨大的好处：多个互不相关的机器人系统可以在同一张物理网络上并行运行而互不干扰。比如楼上机器人 A 用 Domain 0，楼下机器人 B 用 Domain 1，两边话题名字完全一样也没关系，因为 DDS 的发现协议根本不会跨 Domain 广播。

但这也带来了一个麻烦：ROS 2 默认 Domain ID 是 0，你手动设置了export ROS_DOMAIN_ID=42，但新开的终端没有同步设置，于是这个终端里的节点就和其余终端里的节点“绝缘”了。Gazebo 启动的插件节点、Autoware 的 perception/planning 节点、micro-ROS Agent，全都依赖这层 DDS 发现机制，一旦 Domain 不一致，现象就是“一切正常但互相找不到”。

很多新人在排查时会去看话题名、看命名空间、看 QoS，却忽略了最基础的 Domain 一致性。这就像两台对讲机频率不同，内容再清晰对方也收不到。

1.2 Domain 的生效范围与常见不一致来源

ROS_DOMAIN_ID是一个环境变量，它的生效范围是当前 shell 进程及其子进程。也就是说，你在终端 A 里export ROS_DOMAIN_ID=1，终端 B 完全不受影响。这个“隔离性”是好事，但也是混乱的根源。

实际工作中，Domain 不一致的来源通常有这几种：

• 手动在某些终端export ROS_DOMAIN_ID=N，之后新开终端忘了同步。
• 多个项目共用一个~/.bashrc，项目 A 的 source 脚本里设置了 Domain 1，项目 B 的逻辑里又改了 Domain 2，重启终端后环境变量时有时无。
• 通过docker-compose或 systemd 服务启动的节点，环境变量和手动终端不一致。
• 多机器人场景下，不同机器人确实应该用不同 Domain，但开发者自己的操作终端和机器人终端混在一起，一个走读错。

注意一个细节：ROS_DOMAIN_ID可以设置的范围是 0 到 232，但实际可用的数量受限于 DDS 实现和网络拓扑。比如 Fast DDS 默认下，同一个物理网络里 Domain 数量铺太开也可能出现端口冲突，日常开发用 0、1、2 这类小数字就够了，习惯上大家也喜欢用和项目代号相关的数字，比如 201、42 这种。

2. 一键清理的完整方案：进程、日志、回环缓存

“一键清理”不是简单 kill 掉几个进程，而是要解决三类问题：残留进程继续占用 DDS 发现端口、日志文件膨胀导致写满磁盘、ros2 daemon 缓存了旧的拓扑信息导致新节点加入时发现混乱。

2.1 残留进程为什么必须清：端口、共享内存和僵尸节点

Gazebo 和 Autoware 这类重型软件，退出时不一定能把自己启动的子进程全部收干净。比如gzserver意外崩溃，但gazebo的 GUI 进程还活着；Autoware 的多个 lifecycle 节点被 Ctrl+C 终止后，component_container可能还绑定在某个端口上。

这些残留进程最麻烦的地方不在于占 CPU，而在于它们还“活”在 DDS 域里——如果它们还以旧节点名持续发布心跳，ros2 node list会看到一堆幽灵节点，而新启动的节点又因为节点名冲突加不上来。另外，Fast DDS 在共享内存传输模式下会留下/dev/shm里的共享内存段，进程异常退出后这些段不一定自动释放，极端情况下会造成新节点启动时create participant error。

所以清理第一步就是按关键词搜索并结束这些进程。我自己的清单一版是这样：

# 清理本地残留的ROS2/Gazebo/Autoware进程 for kw in gzserver gzclient gazebo rviz2 autoware component_container micro_ros_agent; do pkill -f "$kw" 2>/dev/null done

这里用pkill -f匹配完整命令行，比直接按进程名杀更稳，因为很多进程名带路径或者带参数，按pkill gazebo不一定命中。但注意pkill -f有风险：它会匹配你 shell 里正在执行的这段脚本自身（如果脚本路径里含有关键词）。所以脚本里我用了一个数组循环，并且明确排除了自身路径。

杀进程的顺序也有讲究，优先发 SIGINT（Ctrl+C 等价信号）让节点执行生命周期回调，等 2~3 秒再发 SIGTERM，最后才考虑 SIGKILL。直接在脚本里写pkill -9确实简单粗暴，但 Gazebo 容易留下临时文件，Autoware 的 lifecycle 节点没有机会清理中间变量，下次启动大概率会出幺蛾子。后来我把这套逻辑改成函数形式：先pkill -INT -f，sleep 2，再pkill -TERM -f，实在不行再pkill -KILL -f。

2.2 日志清理与 daemon 重置

ROS 2 的日志默认写在~/.ros/log，包括ros2 launch的控制台输出、DDS 的调试文件。Autoware 还有自己的日志目录，比如~/.autoware或~/.ros/autoware。跑几个小时的仿真，日志轻松上几百 MB。清理时注意：不要把正在运行的节点的日志目录删掉，否则该节点后续写日志会报错。稳妥的做法是只清理 mtime 超过一定天数的文件：

find ~/.ros/log -type f -mtime +3 -delete find ~/.ros/log -type d -empty -delete

然后是ros2 daemon的重置。ROS 2 CLI 工具（ros2 node list、ros2 topic list）依赖后台 daemon 维护一份节点和话题的缓存。它在长时间运行后会因为网络波动、节点反复启停而变得“记忆错乱”，实际上底层 DDS 网络里已经没人了，daemon 还是把旧节点列给你看。重置方式很简单：

ros2 daemon stop ros2 daemon start

其实更深一层还可以直接杀掉ros2 daemon对应的 Python 进程，不过ros2 daemon stop/start已经足够。清理脚本最后我会强制重启 daemon，这样每次切完 Domain 后，CLI 工具查询到的都是当前域的实时状态。

3. 切换 Domain 的标准操作与脚本化

清理只是把房间打扫干净，切换 Domain 才是核心。这里我会拆成“临时切换”“永久切换”和“工程级切换”三个层次，并给一个可直接落地的switch_domain.sh。

3.1 临时切换与永久切换的正确姿势

临时切换就是在当前终端里执行：

export ROS_DOMAIN_ID=42

然后启动的节点都会加入 Domain 42。这个方式只对当前终端有效，适合快速验证。验证是否生效最直接的手段：

ros2 doctor --report

输出里能看到ROS_DOMAIN_ID当前值，也可以看DDS implementation、RMW implementation这些信息。

永久切换则是把这行 export 写进~/.bashrc。这里有个隐藏坑：~/.bashrc只对交互式终端生效，你用ssh robot@host "ros2 launch xxx"这类非交互方式执行命令时，~/.bashrc不会加载，此时 Domain 又回到默认值 0。所以嵌入式设备或者远程部署场景下，更推荐写进 systemd service 的 Environment 字段，或者在项目 launch 脚本里显式设置。

3.2 一个可直接复用的 switch_domain.sh 脚本

我在多个项目里反复改写的版本长这样，注释里写清楚了每一步的意图：

#!/usr/bin/env bash # 用法: ./switch_domain.sh <domain_id> [--clean] set -euo pipefail TARGET_DOMAIN="${1:?请指定目标 Domain ID}" CLEAN_FLAG=false if [[ "${2:-}" == "--clean" ]]; then CLEAN_FLAG=true fi # 1. 是否要顺手清理环境 if [[ "$CLEAN_FLAG" == true ]]; then echo "[INFO] 清理残留进程..." for kw in gzserver gzclient gazebo rviz2 autoware component_container micro_ros_agent; do pkill -INT -f "$kw" 2>/dev/null || true done sleep 2 for kw in gzserver gzclient gazebo rviz2 autoware component_container micro_ros_agent; do pkill -TERM -f "$kw" 2>/dev/null || true done fi # 2. 先重置 daemon，避免旧缓存干扰 ros2 daemon stop || true sleep 1 # 3. 设置当前终端环境变量 export ROS_DOMAIN_ID="$TARGET_DOMAIN" echo "[INFO] 已设置 ROS_DOMAIN_ID=$ROS_DOMAIN_ID" # 4. 重启 daemon，让 CLI 在指定域下重新发现 ros2 daemon start || true sleep 2 # 5. 验证 echo "[INFO] ros2 doctor 关键信息:" ros2 doctor --report | grep -E "ROS_DOMAIN_ID|DDS implementation|RMW implementation" || true echo "[INFO] 当前可用话题数:" ros2 topic list | wc -l

脚本里几个细节值得展开说一下。

set -euo pipefail会让脚本在任何一条命令失败时立刻退出，好处是能快速暴露问题。但注意ros2 daemon stop在原本没有 daemon 运行时可能返回非零状态，所以我加了|| true防止脚本中断。

ros2 daemon stop/start的顺序为什么放在 export 之后？因为 daemon 会继承启动它的 shell 的ROS_DOMAIN_ID，必须先设置好环境变量再启动 daemon，否则 daemon 会停留在旧的 Domain 上。很多人只改 export 不打 daemon 重启，结果ros2 topic list看到的还是旧数据，就误以为切换失败。其实新节点之间通信大概率没问题，只是 CLI 工具“骗”了你。

3.3 多个项目的 Domain 隔离与规划

如果你同时维护好几个项目，建议把它们安排在不同 Domain，并写进项目的.env或 source 脚本里。比如：

• 项目 A 统一用 Domain 101。
• 项目 B 统一用 Domain 202。
• 多机器人站点，机器人 1 用 11，机器人 2 用 12，以此类推。

这样不同机器人在同一局域网共享时，即使话题名都是/map、/cmd_vel，也不会相互干扰。更妙的是，你可以同时打开两组终端，各跑一套环境，互不影响。这种“并行开发”能力是 ROS 2 相比 ROS 1 的巨大进步，但前提是你把 Domain 规划清楚。

需要注意：Domain 隔离只管 DDS 通信，管不了文件系统、命名空间和硬件资源。两个项目同时抢同一个摄像头驱动，Domain 再不同也会冲突，这不属于 Domain 的管辖范围。

4. 踩坑实录与常见问题速查表

下面这些问题是过去一年里我和同事们实际操作中反复遇到的，多数都能用“清理 + 切换”流程解决。

4.1 两个“Domain”，别搞混：DDS 域与 Web 域名拦截

最近发现一个特别容易让人懵的现象：在装某些 ROS 2 第三方工具链时，终端里冒出{"code":1004,"error":"domain forbidden"}或unable to verify if domain is safe to fetch。第一次看到这个报错，我下意识以为是ROS_DOMAIN_ID的问题，在环境变量里折腾了半天。

实际上这里的domain指的是 Web 访问层面的“域名安全验证”，跟 ROS 2 的 DDS Domain ID 完全是两码事。它通常是代理、防火墙或特定的 URL 过滤策略在拦截请求。排查思路是检查当前 shell 里的http_proxy、https_proxy环境变量，以及目标站点证书校验设置。切记：unable to verify...这类网络报错不要扯到 ROS_DOMAIN_ID 上，否则既浪费时间又找不到病根。

4.2 清理脚本自身被 pkill 误杀

这个坑我踩过，写好的 cleanup 脚本一运行就“神秘消失”。原因是pkill -f "gazebo"这类命令匹配了当前正在执行的脚本文件路径——如果你的脚本放在/home/user/gazebo_clean.sh，字符串里含gazebo，那么pkill -f就会把自己也杀掉。

解决方案有几种：一是把脚本文件名改成与关键词完全无关，比如env_manage.sh；二是在匹配时加正则排除当前 PID；三是用pgrep先打印匹配列表，人工确认后再杀。我后来选了第二种，写了一个通用的杀进程函数：

kill_by_keyword() { local kw="$1" local mypid=$$ pgrep -f "$kw" | while read -r p; do if [[ "$p" != "$mypid" ]]; then kill -INT "$p" 2>/dev/null || true fi done }

4.3Delete domain security policies：安全配置文件导致的白名单拦截

菜鸟级操作里还有一个常被提到的问题：执行ros2 security相关命令后，后续节点无法加入域，报错里出现delete domain security policies。这通常是因为你之前生成了带权限控制的安全策略（governance.xml / permissions.xml），后来又手动修改了 Domain，但没有同步刷新安全文件。

应对方式很简单：如果项目不需要 DDS 安全机制，直接删除~/.ros/security下对应 Domain 的目录，重新配置；如果需要安全策略，那么每次切换 Domain 后，都要保证 domID 目录下的 governance/permissions 文件和当前配置一致。别问我怎么知道的，第一次遇到时我差点把整个~/.ros删了才解决。

4.4 常见问题速查表

老规矩，整理一份速查表，方便直接对照排查：

这个表格写下来基本就是我把脑袋里那些“早知道就好了”的经验浓缩成了几行字。特别是 clock 同步那一条，Gazebo 里小车不动，往往不是 Domain 问题，而是你启动 Rviz 或 Autoware 时没设use_sim_time，导致节点用的是真实时间而不是仿真时间，哪怕话题通了也感觉像死机。

5. 进阶实践：把清理与切换做成日常开发流程

如果上面的单条命令已经能解决 80% 的问题，剩下的 20% 要靠流程化。我现在会把清理、切换、验证合并成一个env_manage.sh，并为它设计三个子命令：clean、switch、doctor。

5.1 一个通用的 env_manage.sh 骨架

#!/usr/bin/env bash # 环境管理：clean / switch / doctor set -euo pipefail CMD="${1:-doctor}" case "$CMD" in clean) # 清理进程、日志、临时文件 for kw in gzserver gzclient gazebo rviz2 autoware component_container; do pkill -INT -f "$kw" 2>/dev/null || true done sleep 2 find ~/.ros/log -type f -mtime +2 -delete 2>/dev/null || true ros2 daemon stop || true echo "[OK] 环境已清理" ;; switch) DOMAIN="${2:?用法: env_manage.sh switch <domain_id>}" export ROS_DOMAIN_ID="$DOMAIN" ros2 daemon start echo "[OK] 已切换至 Domain $DOMAIN" ;; doctor) echo "ROS_DOMAIN_ID: ${ROS_DOMAIN_ID:-0}" echo "RMW_IMPLEMENTATION: ${RMW_IMPLEMENTATION:-rmw_fastrtps_cpp}" ros2 doctor --report ;; *) echo "用法: $0 {clean|switch <domain_id>|doctor}" exit 1 ;; esac

这个骨架已经反复用在工作站和开发板上了，稳定可靠。你也可以再加archive子命令：清理日志时不要 delete，而是按时间戳归档到~/.ros/log_archive/，这样可以保留现场用于后续问题回溯。生产环境里这个习惯尤其重要，因为你删掉的日志可能刚好是复现某个偶发 bug 的关键线索。

5.2 多机协同下的 Domain 规划

多机器人的场景下，我习惯给每台机器人固定一个 Domain ID，然后在每台机器人的/etc/profile.d/ros_domain.sh里写入对应值。这样无论是本地终端还是 ssh 登录，只要 shell 是 login shell，都会自动加载统一的 Domain。注意是/etc/profile.d/而不是~/.bashrc，区别在于前者对所有用户生效，适合团队共用设备。

同时，每台机器人记录自己的 Domain 到一个固定文件，比如/etc/robot_domain，脚本里读取这个文件作为默认值：

DOMAIN_ID=$(cat /etc/robot_domain 2>/dev/null || echo 0) export ROS_DOMAIN_ID="$DOMAIN_ID"

这套方案在多机协作的建图、编队测试中非常省心。不同机器人的话题完全隔离之后，单机调试时甚至可以同时跑两套仿真数据，不会互相污染。

5.3 与 micro-ROS / ESP32 的联动

如果你在 ESP32 上用micro_ros_espidf_component搭节点，那清理与切换的联动更要注意。micro-ROS 节点不是从 shell 启动的，它烧录在固件里，Domain ID 是在代码里配置的：

rmw_uros_set_custom_mid(0); // 设置 domain ID static uint8_t domain_id = 101; // 与 ROS 2 主机保持一致

如果 Agent 跑在 Domain 101，而 ESP32 固件里写的 Domain 0，两边永远连接不上。排查时不要只看串口日志，还要确认micro-ROS Agent启动时的环境变量。很多时候 Agent 是在某个终端里带export ROS_DOMAIN_ID=101启动的，而 HOST 端主程序跑在 Domain 0，看起来一切都“正常”，实际上跨域了。

我后期在 Agent 的启动脚本里加了强制校验：启动前读取一个agent.env文件，把ROS_DOMAIN_ID、RMW_IMPLEMENTATION、UDP port一次性写入环境，再启动 Agent，从源头上杜绝“手动 export 忘了改”的人为失误。

写在最后

脚本和命令都是工具，真正值钱的是一套排查问题的思路：先确认 Domain 是否一致，再清理残留进程，然后验证 daemon 状态，最后才去怀疑代码逻辑。这个顺序能帮你省下大量无意义的调试时间。

我个人在实际项目里最大的体会是：Domain 切换这个操作很容易被低估，但它直接决定了一套 ROS 2 系统能不能“被多个人、多台机器、多个工具链复用”。一个干净的环境管理脚本，顶得上群里的十次远程求助。

最后再分享一个小技巧：在~/.bashrc末尾加上一行export PS1="[ROS_DOMAIN=${ROS_DOMAIN_ID:-0}] $PS1"，让终端提示符直接显示当前 Domain。这样哪怕你同时开了八个终端，也能一眼看出哪个终端的环境变量跑偏了。你一旦用习惯，就再也不想回到“一个个终端去 echo $ROS_DOMAIN_ID”的原始查法了。