DDS sandbox限制与ROS2运行验证边界

当前项目里有一部分“还没完全验证”的现象,并不是代码逻辑本身还错着,而是运行环境对ROS 2通信路径施加了额外限制

这个区分非常重要.

因为如果不把“代码缺陷”和“环境阻断”分开记账,最后很容易出现两种误判:明明代码主链路已经跑通,却误以为系统根本没成立,明明只是某种环境下的验证边界,却把它当成应用层bug一直追

而当前项目的BUGS.md和STATUS.md其实已经把这个问题记得很清楚了:sandbox里存在DDS socket限制, ros2 service call形式的独立CLI验证会卡在service discovery,但在正常shell里, end-to-end demo task submission和planner failure recovery已经被跑通

当前阶段目标

这里的目标不是讨论ROS 2底层中间件原理有多复杂,而是回答一个更工程化的问题:当一个ROS 2多节点系统运行在受限环境里时,我们该如何判断“这是代码坏了”还是“这是验证边界到了”

这个问题在当前项目里非常实际.

因为ros2-fleet-coordinator不是单进程程序,而是依赖:/多个node启动/topic通信/service发现与调用/launch过程里的环境写入

只要运行环境在这些链路上卡住其中某一层,表面现象就很容易看起来像“系统没通”.但在工程分析上,这两类问题必须拆开.

先看当前sandbox里到底发生了什么

ROS 2 nodes可以启动.DDS transport在sandbox里报告socket permission相关限制.独立的ros2 service call /submit_task ...客户端会卡在service discovery等待阶段

这里记录了另一个更前置的环境问题: ros2 launch默认尝试往~/.ros/log写日志. 但这个路径在sandbox里是只读的.需要先把ROS_LOG_DIR重定向到workspace内可写目录

也就是说,当前环境限制其实不是只有一层,而至少有两层.

第一层: launch写日志路径受限

这层问题比较表面.

如果不先处理,ros2 launch就会因为默认日志目录不可写而受影响. 当前项目给出的workaround也很明确:

1

export ROS_LOG_DIR=/home/bruce/project-a/ros2-fleet-coordinator/fleet_ws/log/ros

这类问题虽然麻烦,但本质还只是文件系统写权限问题.

第二层: DDS discovery / socket路径受限

这层才更关键.

因为它影响的不是“日志能不能写出来”,而是:ROS 2参与者能不能完成发现. 独立CLI客户端能不能真正连上service. sandbox里的运行验证能不能覆盖完整跨参与者路径

也就是说,这一步卡住以后,你看到的就不再是一个单纯的启动报错,而是:系统看起来像已经起来了,但某些CLI驱动的runtime验证就是过不去

这也是为什么它更容易和代码问题混淆.

为什么这种现象特别容易被误判成代码缺陷

因为从表面看,你会看到一个很像应用故障的场景:ros2 launch启动了/node日志也在滚/但是另一个shell里的ros2 service call卡住了/然后你自然会怀疑是不是:
submit_task服务没真正注册
manager代码没真的工作
service名写错了
甚至整个任务链路根本没接上

但当前项目文档之所以值得信任,就在于它没有把这些现象直接粗暴归结成“代码未完成”,而是做了更细的区分.

BUGS.md已经明确给出判断:这是environment limitation/当前没有相应代码fix/不作为应用逻辑缺陷提交代码修复

这类判断很重要,因为它背后实际上是在回答:问题发生在系统行为层,还是发生在验证介质层

如果验证介质本身被限制了,那你继续盯着业务逻辑改代码,往往只是空转.

那当前项目到底已经验证到了哪里

这个问题必须说清楚,否则这篇文章就会变成“环境有问题,所以一切都不确定”. 这其实不对.

根据当前STATUS.md, 已经明确跑通并验证的东西包括:fleet_msgs, fleet_manager, robot_agent, path_planner, fleet_bringup都能成功build. demo.launch.py能在正常shell里启动整套节点. submit_demo_task.sh可以通过ros2 run提交demo任务. submit_task能够接受任务. fleet_manager能够把任务排队并分配给idle robot. path_planner能够在当前图上返回route. robot_agent能够逐waypoint执行并回报完成. check_planner_failure_path.sh验证了planner rejection之后,后续有效任务仍能继续跑通

而且这些不是只停留在文档意图上,而是已经被记录为:在正常shell环境里完成的实际验证结果

这点非常关键.

因为它说明当前项目并不是“只能编译,不能运行”. 更准确的说法应该是:项目的主链路运行验证已经成立,但成立的验证环境不是当前这个sandbox-only CLI路径

那还没验证到哪里

当前没完全覆盖到的,不是整个系统运行,而是更具体的一段验证边界.

STATUS.md已经把这件事说得很明确:ros2 service call在sandbox里无法完成对应的独立CLI验证. 原因是separate CLI participant卡在service discovery.这与DDS socket restrictions相关

也就是说,还没被当前sandbox完整覆盖到的,更准确地说是:sandbox-only条件下的独立CLI服务发现路径依赖该发现路径的某些端到端验证手段

这和下面这些说法并不一样:/manager一定不能接任务/planner一定没响应/assignment flow一定没成立/整个系统一定没法运行

当前文档之所以写得比较成熟,正是因为它没有把这些层次混在一起.

为什么这篇专题对ROS 2工程判断很重要

因为ROS 2项目和普通单进程程序有一个很大的不同:“代码可编译”“节点可启动”“节点彼此可通信”“独立CLI可发现并调用服务”其实是四层不同的事情

当前项目恰好把这件事暴露得很清楚.

第一层: build和打包

当前已经通过.

第二层: launch启动

在处理好日志目录问题后,当前也已经通过.

第三层: 正常shell里的主链路运行验证

当前也已经通过, 包括demo task和planner failure recovery.

第四层: sandbox-only环境下的独立CLI discovery验证

当前还受限.

也就是说,当前项目最值得记录的经验之一其实是:对于ROS 2系统,验证结论必须带环境上下文,不能脱离运行边界裸说“验证通过”或“验证失败”

否则结论很容易误导后续开发和后续博客分析.

从这个现象也能反过来看当前项目文档为什么写得对

我觉得这个项目现在有一点做得挺对,就是它没有把所有未完成验证都往“代码bug”里塞.

BUGS.md把环境阻断也单独记成有状态的问题.
STATUS.md把正常shell已验证的部分和sandbox受限的部分拆开写.

这种写法的价值在于:/你知道哪些结论是代码层已经拿到的/你知道哪些结论是环境层暂时拿不到的/你不会因为环境噪声去错误回滚已经成立的实现判断/你也不会因为正常shell能跑,就误以为所有验证场景都等价成立

从工程管理角度看,这其实比“问题有没有完全解决”本身还重要.

因为它保证了问题归因是清楚的.

这个专题之后最自然会接到哪里

把DDS sandbox限制这件事单独写完之后,系列里其实又清楚了一层:代码主链路现在已经被验证过/调度和冲突处理是接下来的核心功能升级/运行验证本身也有环境边界,不能脱离上下文看

所以后面如果继续往专题线走,一个自然的方向会是:为什么当前阶段还没有选择Nav2-first integration

因为到了这一步,就会更容易看出:当前系统为什么先停留在graph + BFS + simulated agent/为什么在环境验证边界都还需要单独记账时,过早引入更重的导航栈会让调试面进一步爆炸

它提醒我们,在ROS 2多节点系统里,运行验证失败不自动等于应用逻辑失败; 当前ros2-fleet-coordinator已经在正常shell里验证了主链路,而sandbox里尚未完全覆盖的是一段受DDS discovery/socket限制影响的CLI验证边界

• ← Previous Post
• Next Post →