最近圈子里经常有人问三件事：人形机器人到底火到什么程度、转行做测试要不要学 ROS2、以及网上传的“ROS2 被弃用了”是真的假的。
先说结论：ROS2 没有被弃用。它依然是人形机器人软件架构里最常用的中间件之一，尤其在开源项目、高校研究、做系统验证和测试工具链时，出现频率非常高。那些说“弃用”的人，多数是在讲部分端到端 AI 大模型路线不依赖 ROS2，但这不是“被弃用”，而是某些产品选择自研软件栈。对于想转行人形机器人测试的人来说，ROS2 不是唯一必学技能，但它是一张很好用的通行证，能帮你快速看懂被测系统的消息流、控制链路和数据回放逻辑。
这篇文章就围绕三件事展开：第一，人形机器人哪些模块会用到 ROS2；第二，作为测试工程师，学 ROS2 的优先级和学习边界；第三，面对“ROS2 被弃用”的说法，怎么判断技术路线。最后会给出一套适合测试岗的 ROS2 学习、验证和环境准备方案。
1. 核心问题速览：ROS2 与人形机器人的关系
| 问题 | 快速结论 |
|---|---|
| 人形机器人哪些模块会用到 ROS2 | 感知、定位建图、运动规划、导航、机械臂控制、传感器驱动、日志记录、仿真验证、接口对接等 |
| 转行测试要不要学 ROS2 | 建议学，但不用学源码级开发；先掌握节点、话题、服务、动作、bag 回放等概念和常用命令 |
| ROS2 真的被弃用了吗 | 没有。端到端 AI 路线不一定用 ROS2，但大量机器人系统和测试环境仍依赖 ROS2 |
| 哪些人最需要学 ROS2 | 机器人测试工程师、算法验证工程师、系统集成工程师、应届生转行人员 |
| 哪些人可以不学 ROS2 | 只做嵌入式电机驱动、只做纯视觉模型训练、只做上层 App 开发的人 |
| 学习成本 | 比 ROS1 略高，但比从零学一套自研机器人框架更低；建议从 Humble 或 Jazzy 版本入手 |
2. 人形机器人软件架构：哪些模块真的会用到 ROS2
人形机器人的软件栈通常分为感知层、决策规划层、控制层和系统支撑层。ROS2 在这几层里出现的频率差别很大。
2.1 感知层：相机、激光雷达、点云数据的传递
人形机器人要避障、识别物体、估计姿态，离不开视觉和深度传感器。摄像头图像、激光雷达点云、IMU 数据通常先由驱动节点采集，再发布到 ROS2 话题上。后续的视觉 SLAM、目标检测、点云分割、语义地图都需要订阅这些话题。
在测试环节，工程师最常见的操作就是用ros2 topic echo检查话题是否有数据，或者用ros2 bag record录制传感器数据，再回放给算法节点验证。没有 ROS2 的话，这些传感器数据流会变成每个团队各写一套私有协议，测试和联调的复杂度会高很多。
2.2 定位与建图模块：SLAM 和坐标变换
人形机器人在室内移动时，需要知道自己在哪里，这就需要 SLAM 或者基于地图的定位。ROS2 生态里有成熟的 Cartographer、Nav2 等参考实现，虽然人形机器人不一定完全照搬轮式机器人的导航方案，但建图、定位、坐标变换这套思想是一致的。
更关键的是tf坐标树。人形机器人全身有几十个连杆，从基座到腰部，从腰部到手臂末端，每个关节都需要定义坐标系。ROS2 的tf2负责维护这些坐标变换关系。测试时定位不准、手抓不到目标，很多情况下是tf树断了或者坐标变换延迟过高导致。
2.3 运动规划与机械臂控制：MoveIt2 的高频使用
人形机器人的上半身本质上就是双臂系统。机械臂的路径规划、避障、插补、逆解，目前很多团队直接在 ROS2 上调用 MoveIt2 来做。MoveIt2 在 ROS2 里已经是比较成熟的机械臂运动规划框架，能对接多种规划器和底层控制器。
测试机械臂功能时，可以通过 ROS2 的话题发布目标关节角度，或者通过 action 接口发送规划好的运动目标。ros2 action list、ros2 action send_goal这类命令是机械臂测试的常用工具。
2.4 底层控制对接：关节状态反馈和指令下发
人形机器人的底层关节控制器一般运行在 MCU 或实时控制器上，通常不会直接跑 ROS2。但 ROS2 节点可以充当“翻译层”，把高层的运动指令转换成底层能识别的协议格式，再把底层上传的关节状态转换成 ROS2 话题。
在这个模块中，ROS2 更多是数据中转和状态同步。测试工程师不需要懂电机控制算法，但要能看懂/joint_states这类话题的发布频率和数据格式，能确认控制指令是不是正确下发。
2.5 系统支撑：日志、参数、生命周期、仿真对接
ROS2 的 launch 文件可以一次启动多个节点，参数服务器可以统一管理整机参数，日志系统可以记录节点运行状态。这些能力对机器人这种多节点、多进程的系统非常实用，尤其是在测试环境里做自动化部署和回归验证时。
另外，仿真环境也经常通过 ROS2 接口与算法层对接。Gazebo、Isaac Sim 等仿真软件都可以和 ROS2 通信，这在人形机器人的算法开发和测试中很常见。测试工程师可以在仿真环境中先验证逻辑，再部署到真机。
3. 转行人形机器人测试：ROS2 的优先级与投入产出
转行测试的人经常问：我到底要不要学 ROS2？学到什么深度？
我的建议是：如果你是做人形机器人的系统集成测试、算法测试、软件在环测试，花两周时间把 ROS2 的基础命令和数据流搞明白，回报非常高。如果你只做嵌入式硬件测试，不碰上层软件，那可以不学。
3.1 不同测试岗位对 ROS2 的需求
| 测试方向 | ROS2 需求等级 | 主要工作内容 |
|---|---|---|
| 系统集成测试 | 高 | 启动整机软件栈、检查节点状态、分析话题数据、录制和回放数据 |
| 算法测试 | 高 | 给导航、感知、机械臂算法构造测试输入，用 bag 回放或话题注入 |
| 软件测试 | 中 | 验证 ROS2 节点逻辑、参数配置、launch 文件、生命周期 |
| 嵌入式/硬件测试 | 低 | 关注电机驱动、电源、通信协议，不依赖 ROS2 上层 |
| 仿真测试 | 高 | 在 Gazebo、Isaac Sim 中搭建场景，和 ROS2 节点联调 |
3.2 必须会的 ROS2 概念清单
- 节点：一个可执行程序，负责某种功能，整个机器人就是多个节点的组合
- 话题：点对点的异步通信方式，用于持续性的数据流，比如传感器数据
- 服务：请求响应式的同步通信，适合开关类操作和查询
- 动作：适合长时间执行、可反馈、可取消的任务，比如机械臂运动
- 参数：节点运行时可配置的变量
- launch 文件：一键启动多个节点的配置文件
- bag 文件：录制和回放话题数据的工具
- tf 坐标变换：机器人各个坐标系之间的关系
这些概念理解到“知道它解决什么问题”就够用，不一定要能手写 C++ 或 Python 节点。
3.3 不建议一上来就死磕的内容
不要一开始就花大量时间读 ROS2 源码、研究 DDS 协议细节、写自定义消息类型。测试工程师最重要的是“会用”、“能定位问题”、“能构造测试场景”。等你真正遇到性能瓶颈或跨机器通信问题时，再回头补底层知识，效率更高。
从投入产出比看，ROS2 非常像“机器人世界的 TCP/IP”。你不一定能写出完美的网络协议栈，但你知道怎么抓包、怎么判断连接是否正常，这已经足够支撑大多数测试工作。
4. “ROS2 被弃用”了吗：技术路线判断
很多讨论里说“某头部人形机器人公司不用 ROS2”，这在某些端到端大模型方案里确实是现状。端到端模型把感知、决策、控制集成进一个神经网络，控制流变得很紧凑，不需要像 ROS2 那样把每个传感器、每步规划都拆成独立节点。这会让人产生“ROS2 被抛弃”的错觉。
但判断一个技术是否被弃用，要看整个行业的渗透率，而不是只看个别头部公司。
4.1 从开源生态看
目前大量开源人形机器人项目、高校机器人实验室、各类机器人开发板配套 SDK，底层依然依赖 ROS2。原因是 ROS2 解决了机器人系统里非常基础的问题：进程通信、节点管理、数据录制、模块复用、仿真对接。
4.2 从工程效率看
人形机器人是一个极其复杂的系统工程，涉及几十个节点、十几个算法模块。没有 ROS2 这种中间件，团队之间的接口协调会变成灾难。即使最终产品选择自研软件栈，在研发原型阶段，大量团队仍然会用 ROS2 来做快速原型验证。
4.3 从行业趋势看
ROS2 本身也在演进，比如新的 LTS 版本持续发布，社区活跃度仍然很高。加上机器人仿真、云机器人、机器人集群调度等方向发展，ROS2 作为标准中间件的价值反而在扩大。
更稳妥的判断是：未来人形机器人行业会呈现“自研专用软件栈 + ROS2 生态工具链”并存的局面。ROS2 不会被完全弃用，但它在不同公司中的角色会有差异。对测试工程师来说，掌握 ROS2 依然是一门通用技能，能让你快速进入大多数机器人项目的工作流。
5. ROS2 学习路线与环境准备
环境准备尽量简单，用一台支持 Ubuntu 的机器就够了。如果没有 Linux 机器，先用虚拟机也可以，但性能会差一些，建议至少给虚拟机分配 8GB 内存和 4 核 CPU。
5.1 环境清单
| 项目 | 推荐配置 |
|---|---|
| 操作系统 | Ubuntu 22.04 配 ROS2 Humble，或 Ubuntu 24.04 配 ROS2 Jazzy |
| CPU | 4 核以上 |
| 内存 | 8GB 以上 |
| 磁盘 | 至少 30GB 空闲空间 |
| GPU | 如果只跑 ROS2 基础功能，不需要独立显卡；如果跑仿真或视觉模型，需要 NVIDIA 显卡并装好驱动 |
| Python | 3.8 以上，Ubuntu 自带版本即可 |
5.2 安装 ROS2
以 Ubuntu 22.04 和 ROS2 Humble 为例，官方二进制安装方式大致如下：
# 1. 配置软件源并安装基础包，注意替换为官方源或可用镜像源 sudo apt update sudo apt install software-properties-common curl sudo add-apt-repository universe # 2. 添加 ROS2 软件源 sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \ -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] \ http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | \ sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null # 3. 安装桌面版 ROS2 sudo apt update sudo apt install ros-humble-desktop # 4. 配置环境变量 echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc source ~/.bashrc如果访问官方源比较慢，可以换成国内镜像源，或者使用社区提供的一键安装脚本。具体地址和用法需要根据项目文档确认。
5.3 验证安装
打开两个终端，验证 ROS2 基础通信是否正常：
# 终端 1：启动一个话题发布节点 ros2 run demo_nodes_cpp talker# 终端 2：订阅刚才的话题 ros2 topic echo /chatter如果终端 2 能持续打印字符串，说明 ROS2 环境已经可用，节点通信、话题订阅都没有问题。
6. 测试工程师最常用的 ROS2 功能验证流程
学习 ROS2 时，不要只看概念，要边学边用命令验证。下面这套流程是我认为测试工程师最常用的。
6.1 查看当前系统的节点和话题
假设机器人系统已经启动，先用下面的命令摸清系统里有什么：
# 列出所有节点 ros2 node list # 列出所有话题 ros2 topic list # 查看某个话题的发布频率 ros2 topic hz /joint_states # 查看某个话题的数据内容 ros2 topic echo /joint_states --onceros2 topic hz在测试中非常实用。如果关节状态话题发布频率明显低于预期，可能是传感器驱动卡住、CPU 占用过高，或者节点崩溃后自动重启导致。
6.2 录制和回放测试数据
人形机器人测试中经常需要复现某个场景。比如机器人在特定位置出现了感知异常，你不可能让机器人反复走到那个位置，所以需要用 bag 文件把传感器数据录下来，离线回放给算法节点验证。
# 录制所有话题的数据 ros2 bag record -a # 录制指定话题 ros2 bag record /camera/image_raw /scan /joint_states # 查看 bag 文件信息 ros2 bag info bag_directory # 回放 bag 文件 ros2 bag play bag_directory回放时可以先暂停话题ros2 bag play --pause，配合调试工具逐步排查。
6.3 机械臂运动控制验证
如果被测对象是机械臂或人形机器人上半身，通常会有 action 接口用于发送运动目标。先查看有哪些 action：
ros2 action list然后手动发送一个运动目标，验证机械臂是否能到达指定位置：
ros2 action send_goal /arm_controller/follow_joint_trajectory \ control_msgs/action/FollowJointTrajectory \ "{trajectory: {joint_names: [joint1, joint2], points: [{positions: [0.5, -0.3], time_from_start: {sec: 2}}]}}"注意：在真机上测试时，必须确保安全围栏和急停按钮可用，不要直接对未验证过的机械臂下发大幅动作。
6.4 用 Python 快速测试话题收发
测试工程师偶尔也需要写点小工具，比如批量发假传感器数据、统计某个话题的频率、验证节点响应逻辑。下面是一个基础的话题发布示例：
#!/usr/bin/env python3 import rclpy from std_msgs.msg import String def main(): rclpy.init() node = rclpy.create_node('test_publisher') pub = node.create_publisher(String, '/test_topic', 10) count = 0 while rclpy.ok(): msg = String() msg.data = f'test message {count}' pub.publish(msg) count += 1 rclpy.spin_once(node, timeout_sec=0.1) rclpy.shutdown() if __name__ == '__main__': main()运行前先编译环境：
source /opt/ros/humble/setup.bash python3 test_publisher.py这个脚本适合在仿真环境里做数据注入测试。实际项目中请根据 ROS2 版本和消息类型调整。
7. 接口机制与数据流：话题、服务、动作怎么用
ROS2 的通信机制是理解整个软件架构的关键。三种通信方式对应不同场景，测试工程师必须区分清楚。
| 通信方式 | 适用场景 | 测试观察点 |
|---|---|---|
| 话题 | 持续数据流：传感器、状态反馈、图像 | 发布频率、数据内容、延迟 |
| 服务 | 瞬时请求响应：开灯、启停任务、查询状态 | 请求是否被响应、响应内容 |
| 动作 | 长时间任务：机械臂运动、导航到目标点 | 目标是否接受、实时反馈、是否可取消 |
7.1 QoS 对测试的影响
ROS2 的通信质量依赖于 QoS 配置。如果发布端和订阅端的 QoS 策略不匹配，数据可能传输不了。测试时如果遇到“节点明明在发布，但另一个节点收不到”，优先检查 QoS 是否一致。
查看话题的 QoS 配置：
ros2 topic info /joint_states --verbose7.2 坐标变换是隐藏的坑
人形机器人全身坐标系非常多，tf树一旦断掉，感知和控制就会出现难以定位的问题。测试时可以用下面命令查看整棵坐标树：
ros2 run tf2_tools view_frames或者直接输出坐标变换：
ros2 run tf2_ros tf2_echo base_link left_hand如果坐标变换显示 NaN 或长时间不更新，基本可以判断是某个节点发错了坐标，或者传感器标定数据有问题。
8. 资源占用与性能观察
ROS2 本身不是吃资源的大户，但机器人系统节点很多，通信频繁，加上仿真渲染和视觉模型推理，整机负载会明显上升。
8.1 网络和 CPU 负载
先看系统总负载：
top htop再看 ROS2 节点的 CPU 占用：
ros2 node list ps -aux | grep ros如果某个节点的 CPU 占用异常升高，先观察它订阅了哪些话题、这些话题的发布频率是不是过高。
8.2 话题发布频率监控
用下面的命令持续观察话题频率：
ros2 topic hz /camera/image_raw ros2 topic hz /joint_states如果瞬时频率抖动很大，且系统 CPU 偏高，说明通信或处理链路存在瓶颈。可以降低消息频率、缩小图像分辨率，或者把视觉模型切到 GPU 推理，观察是否改善。
8.3 显存占用观察
在跑视觉感知或仿真时，用nvidia-smi查看显存占用：
nvidia-smi具体显存大小取决于模型、分辨率和 batch 数。第一次跑仿真或视觉模型时，建议从低分辨率、小 batch 开始，确认显存占用稳定后再调大参数。
8.4 降低负载的常见手段
- 降低图像话题的分辨率和帧率
- 减少同时开启的可视化工具
- 使用 QoS 的 Best Effort 策略丢帧而非阻塞
- 在仿真环境中关闭不必要的渲染效果
- 把模型推理放到 GPU 或独立推理服务器上
- 避免多个 bag 文件同时回放
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 节点启动失败 | 依赖包缺失或版本不匹配 | 查看启动日志和rosdep输出 | 安装缺失依赖，用rosdep install --from-paths src -y |
| 话题收不到数据 | QoS 配置不匹配、发布端崩溃、命名空间不对 | 用ros2 topic list查看实际话题名，用ros2 topic info --verbose查看 QoS | 对齐 QoS，检查 launch 文件命名空间 |
ros2 run找到不到包 | 环境变量未加载或包未编译 | source /opt/ros/humble/setup.bash，检查colcon build输出 | 重新编译并 source 本地 install 目录 |
| bag 回放时数据乱序 | 录制和回放环境网络不同、时间戳不一致 | 检查 bag 的时间戳和 ROS2 使用时间源 | 回放时确保使用同一环境或使用--clock |
| 坐标树显示 NaN | 传感器标定错误或节点发错坐标系 | 用tf2_echo逐级检查坐标变换 | 重新标定，检查坐标发布代码 |
| 仿真环境卡顿 | CPU/GPU 负载过高 | 查看top和nvidia-smi | 降低分辨率、减少光源和粒子效果、提升硬件配置 |
| 机械臂运动到错误位置 | 运动规划参数错误、关节限位未配置 | 检查urdf和srdf文件 | 核对关节角范围，重新加载模型 |
10. 最佳实践与测试建议
10.1 先从仿真开始
人形机器人测试风险高，真机调试成本大。建议在 Gazebo、Isaac Sim 等仿真环境里先把 ROS2 节点、话题、动作流程跑通，再部署到真机。仿真的主要价值不是完全复现真机物理特性，而是验证软件逻辑、接口时序和异常处理。
10.2 建立标准数据回放库
测试工程师应该养成录制 bag 的习惯。正常工况录一批、异常工况录一批、边界工况录一批。后续算法调整后，可以快速用相同数据做回归测试，而不需要每次都重新跑真机。
10.3 写测试用例时关注接口而非效果
机器人测试经常被误认为只看“机器人走不走得稳”。实际上，测试工程师更应该关注接口层面的表现：话题是否按预期频率发布、关节指令是否正确下发、异常输入是否会被节点正确处理。效果类指标主要由算法工程师优化，测试负责把环境、数据、日志准备好，并且保证发现的缺陷能复现、可追踪。
10.4 安全合规边界
人形机器人真机测试必须设立安全围栏、急停按钮、限位保护。测试前检查所有安全相关的话题和控制指令是否正常。使用开源 ROS2 包时注意许可证要求，涉及人脸、语音、私有数据的处理要遵守隐私和版权规范。
10.5 目录管理建议
把模型文件、录制数据、launch 配置、测试脚本分目录管理，避免全部堆在 home 目录下。测试脚本尽量使用相对路径，防止换机器后大量脚本失效。
11. 总结
回到开头三个问题：
第一，人形机器人哪些模块会用到 ROS2。感知、定位建图、运动规划、机械臂控制、传感器驱动、仿真对接、数据回放这些环节都有 ROS2 的参与。它更像一个贯穿测试和开发的数据总线，不是简单的“某个功能包”。
第二，转行人形机器人测试要不要学 ROS2。如果走系统测试、算法测试、仿真测试方向，建议学。学习重点是节点、话题、服务、动作、bag、tf 这几个概念，外加一套常用命令。不需要一开始就深挖 DDS 原理和源码实现。
第三，ROS2 真的被弃用了吗。没有。端到端 AI 路线会减少对传统中间件的依赖，但大量机器人项目和测试工具链仍然围绕 ROS2 构建。对新人来说，ROS2 依然是进入机器人行业性价比很高的技能。
建议先准备一台 Ubuntu 机器，装好 ROS2，跑通 talker/listener，再录一段 bag 尝试回放。这一套流程走通之后，你再去看人形机器人的软件架构，会发现很多概念都能对上了。之后不管是面试还是上手项目，你都有底气说一句：ROS2 的基本数据流，我能熟练操作。
