1. 这不是“敲命令”的速查表而是ROS2命令行工具的底层逻辑课很多人第一次打开终端输入ros2 node list看到一串节点名就以为“会用了”等遇到Failed to contact master或No nodes are available又立刻去搜报错、翻文档、重装环境折腾半天发现只是当前终端没 source 工作空间。这不是操作不熟的问题是根本没理解 ROS2 命令行工具CLI tools的设计哲学——它不是一组孤立指令而是一套面向分布式机器人系统状态观测与交互的实时诊断协议栈。核心关键词ros2 cli、ros2 node、ros2 topic、ros2 service、ros2 action、ros2 param、ros2 daemon。这些命令背后没有中心化的“master”没有全局状态缓存所有响应都来自本地运行时发现机制DDS discovery和实时DDS通信层的直接反射。这意味着你敲下的每一行命令本质是在向本机DDS域发起一次轻量级查询请求并等待对等节点的主动响应。它不像 Linux 命令那样“执行即完成”而更像用手机拨号——拨通了才有回音没人接就超时。所以本教程不教你怎么背命令而是带你拆开ros2 node info /talker的调用链从 shell 解析、CLI 参数绑定、rclpy/rclcpp 客户端封装、DDS participant 发起 discovery request到最终收到 remote node 的 endpoint metadata 并格式化输出。适合三类人刚配好colcon build却卡在ros2 run报错的新手能写节点但总被topic not advertised困住的中级开发者以及想把 CLI 工具嵌入自研监控面板、需要理解其底层通信语义的系统集成工程师。你不需要提前掌握 DDS但得接受一个事实ROS2 CLI 不是“工具”它是你与整个机器人通信网络之间的第一道对话接口。2. 整体设计思路为什么 ROS2 要用这套命令行体系而不是 GUI 或 Web2.1 拒绝“黑盒式”调试命令行即最小可观测单元ROS1 的rosnode info和rostopic echo在单机调试时够用但一旦上车、上无人机、进工厂产线GUI 工具如 rqt就成了负担它依赖 X11 转发、占用内存、启动慢、无法脚本化。ROS2 彻底放弃 GUI 作为默认调试入口把所有可观测能力下沉到 CLI 层原因很务实终端是唯一跨平台、零依赖、可管道化、可远程 SSH、可嵌入 CI/CD 流程的通用界面。我去年帮一家 AGV 厂商做产线部署他们要求每台车启动后自动上报节点健康状态。我们没写新服务只用一行 crontab*/5 * * * * ros2 node list --no-daemon | grep -q nav2_lifecycle_manager echo OK || echo FAIL。这行命令能在 ARM64 Ubuntu Core 系统、x86_64 Docker 容器、甚至树莓派 Zero W 上原样运行——因为它的依赖只有ros2cli包和底层 DDS 实现Fast DDS 或 Cyclone DDS不碰 GUI 栈、不碰浏览器、不碰网络服务。这种“终端即运维面”的设计让 ROS2 CLI 天然适配边缘场景。反观某些所谓“ROS2 可视化平台”动辄要装 Node.js、Electron、WebSocket 代理部署成本反而比写个 C 节点还高。2.2 分层解耦CLI ≠ 功能实现而是协议翻译器ROS2 CLI 工具严格遵循分层架构最上层ros2主命令由ros2cli包提供它不做任何业务逻辑只做两件事解析子命令node/topic/service、加载对应插件模块ros2node、ros2topic。你可以把它看作 Python 的argparse 插件注册表。所有子命令都是独立 Python 包通过entry_points注册到ros2cli.command组。这意味着你想加个ros2 battery查电池状态不用改 ROS2 源码只需新建ros2battery包实现BatteryCommand类并注册即可。我团队去年为某巡检机器人加了ros2 thermal命令查红外相机温度30 行代码搞定客户现场直接pip install ros2thermal就生效。中间层ros2subcommand插件如ros2node它负责将用户命令如ros2 node info /talker翻译成标准 ROS2 Client LibraryRCL调用。注意这里不涉及 DDS它只调用rclpy.create_node()、rclpy.spin_once()等 RCL 接口。RCL 才是真正与 DDS 对接的胶水层。这种设计让 CLI 与底层通信实现完全解耦——换 Fast DDS 为 Cyclone DDSCLI 命令一句不用改。最底层RCLROS Client Library它才是真正的“DDS 适配器”。rclpyPython和rclcppC都封装了 DDS Participant、Publisher、Subscriber 的创建、QoS 配置、序列化等细节。当你执行ros2 topic pub /cmd_vel geometry_msgs/msg/TwistCLI 插件调用rclpy.create_publisher()RCL 再调用 Fast DDS 的create_publisher()。整个链路清晰可测、可替换、可打桩。提示这种分层不是为了炫技而是为了解决真实痛点。某次我们调试多车协同时发现ros2 topic list返回节点数不稳定。排查发现是 Fast DDS 的 discovery timeout 设置太短默认 10s而产线电磁干扰导致 discovery packet 延迟。我们没动 CLI只改了RMW_FASTRTPS_USE_QOS_FROM_XML1并配置 XML QoS 文件问题立解——因为 CLI 层根本不关心 discovery 是怎么做的。2.3 Daemon 机制为什么ros2 node list有时快有时慢ROS2 CLI 默认启用ros2 daemon后台守护进程它本质是一个常驻的rclpy节点缓存了本地 DDS 域内已发现的节点、话题、服务等元数据。当你执行ros2 node listCLI 优先向 daemon 查询毫秒级响应若 daemon 未运行或缓存过期则 CLI 自己启动临时节点去 discovery可能耗时数秒。这就是为什么新手常遇到“第一次运行很慢之后就快了”的现象。Daemon 不是必须的你可以用--no-daemon强制禁用ros2 node list --no-daemon。实测对比Ubuntu 22.04 Fast DDS场景首次执行耗时后续执行耗时适用场景启用 daemon默认1.2sdaemon 启动discovery18ms查缓存日常开发、交互式调试--no-daemon850ms纯 discovery850ms每次重 discoveryCI/CD 自动化、资源受限嵌入式设备注意Daemon 缓存有 TTL默认 10 秒且只缓存 discovery 结果不缓存实时数据如ros2 topic echo仍需建立 Subscriber。别指望它让echo变快。3. 核心命令逐层拆解从参数到 DDS 底层行为3.1ros2 node不只是列节点而是节点生命周期的探针ros2 node子命令家族是 ROS2 CLI 的基石它直接映射到 ROS2 节点的核心抽象Node 是计算单元、命名空间、参数服务器、生命周期管理的载体。我们以ros2 node info /talker为例拆解其完整执行路径第一步CLI 参数解析与校验命令输入ros2 node info /talkerros2node插件首先验证/talker是否为合法节点名正则^/[a-zA-Z][a-zA-Z0-9_]*$并检查是否以/开头强制绝对命名空间。若输成talker无斜杠会报错Node name must be absolute——这不是 bug是 ROS2 强制命名空间一致性的体现避免相对名在多机器部署时歧义。第二步创建临时 discovery 节点CLI 调用rclpy.create_node(_ros2_node_info_client)创建一个匿名节点名字带下划线表示内部使用。该节点不发布/订阅任何话题只做一件事调用rclpy.get_node_names_and_namespaces()。这个 API 底层触发 DDS 的Participant Discovery向本地 DDS 域广播 discovery request等待其他 Participant即/talker节点返回其 participant GUID、domain ID、以及注册的 endpointsPublisher/Subscriber/Service/Action 等。第三步解析 endpoint 元数据并格式化收到/talker的响应后RCL 解析其 endpoints 列表。例如/talker若有Publisher:/chatter(std_msgs/msg/String)Service:/add_two_ints(example_interfaces/srv/AddTwoInts)CLI 插件会进一步调用rclpy.get_publishers_info_by_topic(/chatter)获取该 topic 的 QoS 配置可靠性、持久性、历史深度并用rclpy.expand_topic_name()解析命名空间。最终输出结构化信息/talker Subscribers: None Publishers: /chatter (std_msgs/msg/String) [Reliable, Transient Local] Services: /add_two_ints (example_interfaces/srv/AddTwoInts) [Reliable]实操心得ros2 node info的关键价值在于验证节点是否“真正在线”。曾有个客户反馈/camera/compressed话题收不到数据ros2 topic list能看到它但ros2 node info /camera显示Publishers: None。我们立刻定位到是 camera driver 节点崩溃后残留了 discovery 信息DDS discovery cache 未及时清理实际 publisher 已销毁。此时ros2 node kill /camera强制清理再重启驱动问题解决。这说明ros2 node info比ros2 topic list更可靠因为它查的是节点级 endpoint而非 topic 级 advertisement。3.2ros2 topic从“看数据”到“测通信质量”的跃迁ros2 topic是新手最常用也最容易误解的命令。ros2 topic list只显示当前活跃的话题名但ros2 topic info /chatter才揭示真相。我们以ros2 topic info /chatter输出为例Type: std_msgs/msg/String Publisher count: 1 Subscription count: 2这三行信息背后是三次独立的 DDS discovery 操作Type 查询CLI 调用rclpy.get_topic_names_and_types()获取/chatter的消息类型字符串std_msgs/msg/String。注意ROS2 不在 discovery 中传输完整消息定义只传类型名因此ros2 topic echo需要本地有对应.msg文件即工作空间已 source才能反序列化。Publisher countCLI 向/chattertopic 发送 discovery request统计响应的 Publisher endpoint 数量。这个值反映“有多少节点正在发布此话题”。Subscription count同理统计响应的 Subscriber endpoint 数量。但注意这个值不等于实际接收数据的节点数因为 DDS 的 subscription discovery 是“声明式”的——节点只要调用create_subscription()就会上报无论是否spin()或是否处理回调。曾有个案例某节点订阅了/tf但忘记spin()ros2 topic info /tf仍显示Subscription count: 1但数据流中断。这时需结合ros2 node info查该节点是否存活。更实用的是ros2 topic hz /chatter它不是简单算频率而是基于 DDS SampleInfo 的精确测量。CLI 创建一个临时 Subscriber接收 100 个消息样本记录每个SampleInfo.reception_timestampDDS 层时间戳然后计算相邻时间戳差值的倒数并取中位数。这比rostopic hzROS1更准因为绕过了 ROS1 的 TCPROS 传输层抖动。实测在千兆局域网误差 0.5%。注意事项ros2 topic hz默认采样 100 个消息若话题发布率低如/diagnostics每 5 秒一次可能等很久。可用-w 500等待 500ms或-p 10只采 10 个样本加速。但切记样本越少统计越不准。我一般设-p 50作为平衡点。3.3ros2 param参数系统的双面性——便利与陷阱并存ROS2 参数系统Parameter System是节点配置的核心ros2 param命令直击其要害。ros2 param list /turtlesim列出所有参数但真正关键的是ros2 param get /turtlesim background_r。它的执行流程特殊CLI 创建临时节点调用rclpy.set_parameters()向/turtlesim发送SetParameters服务请求注意参数读写走的是 Service 通道不是 Topic/turtlesim节点的参数回调函数on_parameter_event()被触发返回当前值CLI 解析ParameterEvent响应提取new_parameters[0].value.integer_value这带来两个重要推论参数读写依赖 Service 通信若/turtlesim的 parameter services 被禁用如启动时加--ros-args --param use_sim_time:false --remap __ns:/ros2 param list会报Service not available。这不是节点挂了是参数服务没暴露。参数值类型强约束ros2 param set /turtlesim background_r 255成功但ros2 param set /turtlesim background_r 255字符串会失败报Type mismatch: expected integer, got string。ROS2 参数类型在编译时由.yaml参数文件或declare_parameter()确定运行时不可变。实操心得参数调试最常踩的坑是“修改不生效”。比如ros2 param set /turtlesim linear_velocity 2.0但 turtle 还是慢跑。原因往往是该参数是只读的read_only或节点未实现on_set_parameters_callback来动态响应。正确做法是先ros2 param describe /turtlesim linear_velocity查参数属性确认read_only: false且dynamic_type: true。我团队写节点时必加日志self.get_logger().info(fParameter {name} set to {value})确保回调真被触发。3.4ros2 action理解 Action 的三阶段状态机Action 是 ROS2 特有的长期运行任务抽象如导航、抓取ros2 action命令专为此设计。ros2 action list只显示 action server 名但ros2 action info /navigate_to_pose才揭示其状态机Action: navigation_msgs/action/NavigateToPose Server is ready Goals in queue: 0这里的 “Server is ready” 不是简单的布尔值而是 CLI 向 action server 发送GoalStatusArray请求后的解析结果。Action server 必须实现三个接口/navigate_to_pose/_action/send_goalGoal/navigate_to_pose/_action/get_resultResult/navigate_to_pose/_action/get_statusStatusros2 action info实际调用的是第三个。Goals in queue: 0表示当前无待处理 goal但不保证 server 正在运行——它可能刚处理完一个 goal 就崩溃了。要验证 server 活性得用ros2 action send_goal /navigate_to_pose navigation_msgs/action/NavigateToPose {pose: {pose: {position: {x: 1.0, y: 0.0}}}}并观察响应。若超时说明 server 未响应需查ros2 node info确认节点存活。关键技巧Action goal 的 JSON 格式极易出错。ros2 action send_goal要求严格符合.action文件定义。例如NavigateToPose的pose字段是geometry_msgs/PoseStamped必须写全ros2 action send_goal /navigate_to_pose navigation_msgs/action/NavigateToPose \ { \pose\: { \header\: {\frame_id\: \map\}, \pose\: { \position\: {\x\: 1.0, \y\: 0.0, \z\: 0.0}, \orientation\: {\x\: 0.0, \y\: 0.0, \z\: 0.0, \w\: 1.0} } } }漏掉header或字段名大小写错误如Position都会报Failed to parse goal。建议用ros2 interface show navigation_msgs/action/NavigateToPose先看结构。4. 实操全流程从零构建可验证的 CLI 调试环境4.1 环境准备避开 90% 新手的安装陷阱ROS2 安装本身不难但 CLI 工具链的完整性常被忽略。以 HumbleLTS为例官方推荐apt install ros-humble-desktop但它不包含ros2cli的全部插件。例如ros2 pkg查包、ros2 launch启动 launch 文件在desktop中是有的但ros2 lifecycle生命周期管理需单独装sudo apt install ros-humble-lifecycle更隐蔽的坑是 DDS 实现。Ubuntu 22.04 默认装 Fast DDS但某些硬件如 NVIDIA Jetson因 ABI 兼容问题需强制用 Cyclone DDS# 卸载 Fast DDS sudo apt remove ros-humble-fastrtps # 安装 Cyclone DDS sudo apt install ros-humble-cyclonedds # 设为默认 echo export RMW_IMPLEMENTATIONrmw_cyclonedds_cpp ~/.bashrc source ~/.bashrc验证 CLI 完整性# 检查所有子命令是否可用 ros2 --help | grep -E ^(node|topic|service|action|param|pkg|launch|lifecycle) # 检查 daemon 状态 ros2 daemon status # 应显示 The daemon is running # 检查 DDS 实现 echo $RMW_IMPLEMENTATION # 应为 rmw_fastrtps_cpp 或 rmw_cyclonedds_cpp注意事项source /opt/ros/humble/setup.bash后ros2命令才生效。新手常忘这步直接敲ros2 node list报command not found。建议在~/.bashrc末尾永久添加source /opt/ros/humble/setup.bash source ~/ros2_ws/install/setup.bash # 你的工作空间4.2 构建最小可验证案例一个会“说话”的节点我们不用turtlesim而是手写一个极简talker节点全程用 CLI 验证步骤 1创建工作空间mkdir -p ~/ros2_ws/src cd ~/ros2_ws colcon build --symlink-install source install/setup.bash步骤 2写 Python talkersrc/talker_pkg/talker_pkg/talker.pyimport rclpy from rclpy.node import Node from std_msgs.msg import String class Talker(Node): def __init__(self): super().__init__(talker) self.publisher_ self.create_publisher(String, chatter, 10) timer_period 1.0 # seconds self.timer self.create_timer(timer_period, self.timer_callback) self.i 0 def timer_callback(self): msg String() msg.data fHello World: {self.i} self.publisher_.publish(msg) self.get_logger().info(fPublishing: {msg.data}) self.i 1 def main(argsNone): rclpy.init(argsargs) talker Talker() rclpy.spin(talker) talker.destroy_node() rclpy.shutdown() if __name__ __main__: main()步骤 3添加 package.xml 和 setup.py略标准模板步骤 4编译并运行cd ~/ros2_ws colcon build --packages-select talker_pkg source install/setup.bash ros2 run talker_pkg talker步骤 5CLI 全链路验证# 1. 确认节点存在查 discovery ros2 node list # 应输出 /talker # 2. 查节点详情确认 publisher ros2 node info /talker # 应显示 Publisher: /chatter # 3. 查话题确认 topic advertisement ros2 topic list # 应输出 /chatter # 4. 查话题详情确认 type 和计数 ros2 topic info /chatter # Type: std_msgs/msg/String, Publisher count: 1 # 5. 监听数据验证 end-to-end 通信 ros2 topic echo /chatter # 应滚动输出 Hello World: 0, Hello World: 1... # 6. 测频率验证 timing ros2 topic hz /chatter -p 20 # 应接近 1.0 Hz这个流程看似简单但覆盖了 CLI 的核心能力发现node/list、元数据node/info、类型匹配topic/info、数据流topic/echo、性能topic/hz。每一步失败都指向不同层级的问题ros2 node list无输出 → DDS domain 不一致检查ROS_DOMAIN_IDros2 node info /talker显示Publishers: None→ 节点未正确创建 publisher代码 bugros2 topic echo /chatter无输出但topic info显示Publisher count: 1→ QoS 不匹配如 talker 用Best Effortecho 用Reliable4.3 进阶调试用 CLI 定位多机器通信故障ROS2 多机部署是高频故障区。假设robotIP 192.168.1.10和workstationIP 192.168.1.20需通信故障现象workstation上ros2 topic list看不到robot的/scan话题。CLI 排查四步法第一步确认本机 discovery 正常在workstation执行ros2 node list --no-daemon # 若能列出本地节点说明本机 DDS 正常第二步检查 domain ID 一致性ROS2 默认 domain ID 为 0但多机需统一# 在 robot 和 workstation 都执行 echo $ROS_DOMAIN_ID # 必须相同如 42 # 若不同临时设置 export ROS_DOMAIN_ID42第三步验证网络连通性DDS 层DDS 使用 UDP multicast默认组播地址239.255.0.1。用ros2 daemon的 debug 模式查# 在 workstation 启动 debug daemon ros2 daemon stop RMW_IMPLEMENTATIONrmw_fastrtps_cpp FASTRTPS_DEFAULT_PROFILES_FILE/dev/null ros2 daemon start --log-level debug # 然后看日志中是否有 Discovered participant from IP 192.168.1.10 journalctl -u ros2-daemon -f | grep Discovered第四步强制指定 unicast绕过 multicast 限制若企业防火墙禁 multicast改用 unicast# 在 robot 启动 talker 时指定 peer ros2 run demo_nodes_py talker --ros-args --remap __node:robot_talker \ -p ros__parameters.use_sim_time:false \ --env FASTRTPS_DEFAULT_PROFILES_FILE/path/to/peers.xmlpeers.xml内容?xml version1.0 encodingUTF-8? profiles xmlnshttp://www.eprosima.com/XMLSchemas/fastRTPS_Profiles participant profile_namerobot_participant rtps builtin initialPeersList locator udpv4 address192.168.1.20/address /udpv4 /locator /initialPeersList /builtin /rtps /participant /profiles实操心得多机调试时永远先ping再ros2。我见过太多人花 2 小时调 ROS2最后发现是iptables拦了 UDP 7400-7410 端口。用sudo ufw allow 7400:7410/udp放行即可。记住ROS2 CLI 是你的第一道探针但它的有效性依赖于底层网络基础。5. 常见问题与独家排查技巧实录5.1 “No nodes are available” —— 最经典的幻觉错误现象ros2 node list返回空但ps aux | grep ros2明明看到节点进程在跑。根因分析这不是节点没启动而是 CLI 与节点不在同一 DDS domain。ROS2 用ROS_DOMAIN_ID环境变量隔离 domain默认为 0。但以下情况会导致 domain ID 错乱终端 Aexport ROS_DOMAIN_ID1启动节点终端 B未设ROS_DOMAIN_ID默认 0执行ros2 node list此时 CLI 在 domain 0 查节点在 domain 1 运行自然“看不见”。排查命令# 查当前终端 domain ID echo $ROS_DOMAIN_ID # 查所有终端中 ROS2 进程的 domain IDLinux ps aux | grep ros2 | grep -v grep | xargs -I {} sh -c echo {} cat /proc/{}/environ 2/dev/null | tr \0 \n | grep ROS_DOMAIN_ID终极解决方案在~/.bashrc中统一设置export ROS_DOMAIN_ID42 # 选 1-101 之间任意数避开默认 0注意ROS_DOMAIN_ID必须是整数不能是字符串。曾有客户设export ROS_DOMAIN_ID42带引号导致 CLI 解析失败报invalid literal for int()。去掉引号即可。5.2ros2 topic echo卡住不动 —— QoS 匹配的隐形杀手现象ros2 topic echo /chatter启动后无输出CtrlC 也卡住。根因QoSQuality of Service策略不匹配。ROS2 要求 Publisher 和 Subscriber 的以下 4 个 QoS 属性必须兼容Reliability可靠性ReliablevsBest EffortDurability持久性Transient LocalvsVolatileHistory历史深度Keep Last(10)vsKeep AllDeadline截止时间必须相同最常见是Reliability不匹配talker用Reliable默认而echo用Best Effort某些旧版 CLI 默认。echo发送Best Effort订阅请求talker的ReliablePublisher 拒绝建立连接。验证方法# 查 talker 的 QoS需在 talker 代码中打印 # 或用 info 命令部分版本支持 ros2 topic info /chatter --verbose # 若支持会显示 QoS强制匹配方案# 用 --qos-reliability 指定 ros2 topic echo /chatter --qos-reliability reliable # 或 --qos-durability ros2 topic echo /chatter --qos-durability transient_local实操心得QoS 是 ROS2 的“暗物质”看不见摸不着但决定一切。我团队规定所有节点启动时必须打印其 Publisher/Subscriber 的 QoS 配置。例如self.get_logger().info(fPublisher /chatter QoS: {self.publisher_.get_qos_profile()})这样ros2 node info时就能看到日志快速比对。5.3ros2 daemon启动失败 —— 端口冲突的静默杀手现象ros2 daemon start无报错但ros2 daemon status显示not running。根因ros2 daemon默认监听 TCP 端口11311与 ROS1 兼容若该端口被占用如 Docker 容器、其他程序daemon 启动失败但不报错。排查命令# 查 11311 端口占用 sudo lsof -i :11311 # 或 netstat sudo netstat -tulpn | grep :11311解决方案# 方案1杀掉占用进程 sudo kill -9 PID # 方案2换端口推荐避免冲突 export ROS2_DAEMON_PORT11312 ros2 daemon start注意换端口后所有 CLI 命令会自动连接新端口无需额外配置。这是ros2cli的设计亮点——daemon 端口通过环境变量注入完全透明。5.4ros2 param set失败但无提示 —— 参数作用域的迷雾现象ros2 param set /turtlesim background_r 100执行后无报错但ros2 param get /turtlesim background_r仍是旧值。根因参数作用域namespace错误。/turtlesim节点可能在/turtlesim命名空间下启动但参数实际在/turtlesim/turtlesim下。ROS2 参数路径是层级的ros2 param list显示的是全路径。验证方法# 查所有参数含全路径 ros2 param list --full-name # 输出类似 # /turtlesim/turtlesim/background_r # /turtlesim/turtlesim/background_g正确命令ros2 param set /turtlesim/turtlesim background_r 100实操心得永远用ros2 param list --full-name开头。我见过太多人因命名空间多一层/少一层/调试半天。ROS2 的命名空间规则是节点名/a/b/c启动时其参数默认在/a/b/c/c下节点名重复除非显式用--ros-args --params-file指定。6. 工具链延伸如何把 CLI 能力嵌入你的工作流6.1 CLI 脚本化自动化部署检查清单ROS2 项目上线前我必跑一个check_ros2.sh脚本内容如下#!/bin/bash echo ROS2 Environment Check echo Domain ID: $(echo $ROS_DOMAIN_ID) echo RMW: $(echo $RMW_IMPLEMENTATION) echo -e \n Node Health if ! ros2 node list --no-daemon | grep -q my_robot_core; then echo ERROR: my_robot_core node not found! exit 1 fi echo -e \n Topic Liveness if ! ros2 topic list --no-daemon | grep -q /scan; then echo ERROR: /scan topic not advertised! exit 1 fi ros2 topic hz /scan -p 10 | grep Average | awk {print Scan rate:, $3, Hz} echo -e \n Parameter Sanity if ! ros2 param get /my_robot_core max_velocity | grep -q 1.0; then echo WARN: max_velocity not set to 1.0 fi echo -e \n All checks passed! 这个脚本被集成到 Jenkins Pipeline每次部署自动执行5 秒内给出系统健康快照。它不替代单元测试但能拦截 80% 的配置类低级错误。6.2 CLI 与 VS Code 深度集成一键调试VS Code 的 ROS2 插件如ms-iot.vscode-ros支持直接运行 CLI 命令。我在launch.json中配置{ version: 0.2.0, configurations: [ { name: