第二届世界人形机器人运动会上，智元精灵 G2 同时拿下“消防应急场景”和“图书场景”两枚金牌。这个结果如果只看赛事新闻，只是一句成绩播报；放到人形机器人的工程语境里，它其实是一条完整技术链路的验证：自主导航、环境感知、目标识别、灵巧操作、双足步态稳定和任务状态恢复必须同时在线，才可能在两类差异很大的任务里稳定夺冠。
这篇文章不讨论赛事名次本身，而是把这两个夺金场景拆成机器人任务需求，梳理背后的软硬件架构、关键技术模块、验证方法、常见排错路径，以及从赛场走向生产时还需要补齐的工程能力。如果你正在做人形机器人的地图导航、机械臂抓取、任务编排，或者只是想把一场比赛成果转换成技术总结，这篇文章会提供一个可复用的分析框架。
1. 把“消防应急场景”和“图书场景”翻译成机器人任务需求
很多人看到“消防”“图书”两个词，第一反应是场景差别很大。但从机器人研发角度看，这两个场景恰好覆盖了人形机器人落地最核心的两类能力：移动环境下的感知与操作、受限空间里的精细作业。
1.1 消防应急场景考的是长任务自主执行
消防应急场景通常不会只有一个动作。它往往要求机器人在模拟场地里完成一套连续动作：搜索疑似起火点或热源，识别灭火器、消火栓、阀门等目标物，避开障碍物，接近目标，然后执行按压、旋转、拉取等末端操作。
这类任务可以拆成一张环节与能力对应表：
| 任务环节 | 机器人需要的能力 | 最容易失败的环节 |
|---|---|---|
| 场地搜索 | 自主导航、路径规划、避障 | 低矮障碍物漏检，碰撞后偏离路径 |
| 目标识别 | 目标检测、语义分类、位姿估计 | 光照变化导致漏检或误检 |
| 接近目标 | 步态控制、末端粗定位 | 双足站立不稳，身体朝向偏差 |
| 执行操作 | 夹爪/末端执行器控制、力控 | 按压力度不足、旋转角度误差大 |
| 返回或复位 | 重定位、任务状态恢复 | 中途断电、卡死、未恢复继续执行 |
这张表背后是一个很现实的问题：比赛任务不是单点技能考核，而是连续执行。搜索、靠近、操作三个环节只要有一个出现偏差，后续动作全部受影响。所以智元精灵 G2 能拿金牌，说明它的任务调度和多环节衔接能力很稳定，而不只是某一个传感器或某个抓取算法做得好。
1.2 图书场景考的是精细操作和语义理解
图书场景的比赛任务通常围绕“取书、放书、翻页、归位”展开。机器人需要识别书架层板、图书标签或封面信息，判断目标图书的位置和姿态，然后控制机械臂避开相邻书本，安全地取出或放入目标书。
这个场景的难点和消防场景完全不同：
- 目标物体积小，视觉定位精度要求更高。
- 书架空间狭窄，机械臂和机身的运动空间受限。
- 抓取力度必须合适，太紧会损伤书本，太松会滑落。
- 双足机器人在书架前站位不稳定，身体轻微晃动都会放大末端误差。
图书场景更像“精细操作”的考试。它要求机器人在已经知道自己大致位置的前提下，用视觉伺服、手眼标定和力控完成毫米级操作。相比消防场景强调“走得到、摸得准”，图书场景更强调“站得稳、夹得准、放得轻”。
1.3 两个场景共同测试的底层能力
把两个场景放在一起看，能发现人形机器人赛事真正在测试的共性能力有三个。
第一个是长任务可靠性。整个流程从启动到结束可能持续数分钟，中间包含多次导航、识别、抓取和状态切换，任何一个环节的偶发错误都可能让整个任务失败。
第二个是异常恢复能力。比如消防场景中夹爪没夹住灭火器，图书场景中书从手上滑落，系统不能直接崩溃，而要能检测到失败、重试或跳过，并记录日志。
第三个是人机安全边界。双臂人形机器人在有人活动的场景里作业，必须有碰撞检测、限力和急停机制。比赛环境相对可控，生产环境里这一点会被放大成最重要的需求。
2. 从传感器到动作：人形机器人任务系统的软硬件分层
智元精灵 G2 不是一台简单拼装出来的演示样机，它能在两个场景中切换，背后一定有一套清晰的分层架构。理解这套架构，比记住某个具体算法更有价值。
2.1 硬件与算力底座：先解决“感知从哪来、算力放哪里”
以 G2 这类参赛人形机器人为例，硬件层通常包含以下几类组件：
- 环境感知传感器：彩色相机、深度相机、激光雷达，用于建图、定位和目标识别。
- 本体状态传感器：IMU、关节编码器、六维力传感器、触觉传感器，用于估计机器人自身姿态、关节角度和末端接触力。
- 算力平台：一块或多块边缘计算板卡，承担感知模型推理、运动规划和状态机调度。
- 执行器：关节电机、减速器、夹爪或灵巧手、吸盘等末端工具。
在赛事场景里，算力平台的选择往往要比“峰值算力”更关注整体功耗、散热和实时性。常见的人形机器人边缘算力方案会兼顾 CPU、GPU 和 NPU 的分工：CPU 处理状态机和调度逻辑，GPU/NPU 跑目标检测模型，运动控制放在独立控制板或实时核上，避免被感知任务抢占导致控制延迟。
2.2 软件架构：感知、决策、控制到底怎么分层
人形机器人的软件架构可以按职责分为五层：
| 层次 | 职责 | 典型组件 |
|---|---|---|
| 感知层 | 采集并处理视觉、激光、力觉数据 | 目标检测、深度估计、点云分割 |
| 状态估计层 | 估计机器人位置、姿态、关节状态 | SLAM、IMU 融合、里程计 |
| 任务规划层 | 决策当前要执行哪个子任务 | 有限状态机、行为树、任务调度器 |
| 运动规划层 | 计算机械臂轨迹、步态序列和避障路径 | RRT、MPC、步态生成器 |
| 执行器接口层 | 向下发送关节指令，读取编码器反馈 | 控制板驱动、EtherCAT/CAN 通信 |
在 ROS 2 这类中间件环境中，各层之间通常以话题、服务和动作的形式通信。感知层发布目标物体位姿，任务规划层订阅位姿并决定下一步动作，运动规划层收到动作目标后生成轨迹，执行器接口层把轨迹转换成关节指令。
这种分层的好处是：任何一个环节出问题，都可以单独测试和替换。比赛现场调试时，团队不需要重新编译完整系统，只替换出问题的模块即可。
2.3 用状态机把两个场景组织成可执行流程
人形机器人完成一场比赛任务，不能靠一长串硬编码动作，而要维护一个“当前在做什么、下一步做什么、失败了怎么办”的状态机。
下面是消防应急场景的一个简化状态机示例，使用 Python 伪代码表示，用于说明任务调度的核心思路：
class FireFightingTask: def __init__(self): self.state = "IDLE" self.target = None def update(self): if self.state == "IDLE": if self.check_start(): self.state = "SEARCH" elif self.state == "SEARCH": # 感知模块持续发布目标物位姿 self.target = self.perception.get_target() if self.target is not None: self.state = "APPROACH" elif self.is_timeout(): self.state = "FAILED" elif self.state == "APPROACH": nav_result = self.navigation.goto(self.target.pose) if nav_result == "REACHED": self.state = "MANIPULATE" elif nav_result == "BLOCKED": self.state = "RECOVER" elif self.state == "MANIPULATE": operate_result = self.arm.operate(self.target) if operate_result == "SUCCESS": self.state = "VERIFY" else: self.state = "RETRY" if self.retry_count < 3 else "FAILED" elif self.state == "VERIFY": if self.sensor.confirm(): self.state = "DONE" else: self.state = "RETRY" elif self.state == "RECOVER": self.navigation.recover() self.state = "APPROACH" elif self.state == "FAILED": self.log.error("task failed at state: " + self.state)这个状态机的关键点有三个：
一是每个状态都要有超时检查。搜索状态不能无限等，接近状态不能一直走，否则一个小问题会导致整台机器人卡死。
二是失败不要直接回初始状态，而是先尝试局部恢复。比如导航被障碍物挡住时，先重规划路径，而不是回到起点重新开始。
三是状态切换必须记录日志。比赛结束复盘时，没有日志很难判断任务是在哪个环节失败的。
图书场景也可以使用相同的状态机框架，只是把 SEARCH 换成“定位书架层板”，把 MANIPULATE 换成“取书/放书/翻页”。状态机本身并不挂接具体业务逻辑，它只负责调度，这也是它能跨场景复用的原因。
3. 视觉、导航与操作：理解机器人如何完成一次完整交互
无论消防场景还是图书场景，机器人都要回答三个问题：我在哪、目标在哪、怎么把手脚伸过去并对目标施加正确操作。这一节拆解这三条技术链路。
3.1 环境感知与定位：先回答“机器人在哪、目标在哪”
人形机器人进入一个陌生比赛场地后，不能依赖预先标好的固定轨迹，而要先建立地图并估计自身位置。这里最常用的是 SLAM 技术，把激光雷达、深度相机和 IMU 的数据融合起来，在移动过程中同时完成建图和定位。
在消防应急场景中，比赛场地可能包含不同高度的障碍物，仅用 2D 激光雷达容易漏检低矮物体，因此通常会加入视觉或 3D 点云信息，构建 2D 栅格地图与 3D 语义地图叠加的混合地图。2D 地图负责路径规划，3D 语义信息负责确认目标物的种类和姿态。
环境感知模块的输出，在代码层面通常是一组结构化数据。下面是一个目标物位姿的 JSON 示例，用于说明感知层如何向任务规划层传递信息：
{ "timestamp": 1710000000.123, "object_type": "fire_extinguisher", "confidence": 0.97, "position_m": [3.2, 1.8, 0.4], "orientation_quat": [0.0, 0.0, 0.0, 1.0], "size_m": [0.3, 0.12, 0.12], "grasp_point_m": [3.25, 1.85, 0.5] }这份数据里，position_m表示目标物体在机器人地图坐标系中的位置，orientation_quat表示姿态四元数，grasp_point_m则是后续机械臂执行抓取时需要使用的最优抓取点。感知层不仅要告诉任务规划层“那里有一个灭火器”，还要告诉它“应该抓哪里”。这一步做不好，即使检测到目标，机械臂也会抓空。
3.2 抓取与精细操作：夹哪里、夹多紧、如何确认成功
目标定位完成之后，机械臂要完成一次可靠抓取。抓取不是简单地把夹爪移动到坐标点然后闭合，它包含三个步骤。
第一步是抓取姿态估计。视觉模块从点云中提取物体表面几何特征，计算夹爪接近方向和夹取点。比如图书场景中，机器人需要知道书脊朝哪个方向、书本倾斜角度是多少、夹爪应该从上方还是前方接近。
第二步是轨迹规划和运动控制。机械臂不能直接冲向目标，而要经过规划好的无碰撞路径，并在接近目标时降低速度，用视觉伺服做末端修正。
第三步是力控和抓取验证。夹爪合拢时如果遇到阻力超过阈值，说明夹住了物体；如果夹爪完全闭合但力传感器没有检测到阻力，说明物体已经滑落。下面是一段简化的抓取判断伪代码：
def grasp_and_verify(grasp_point): # 移动到预抓取点 arm.move_to_pose(pregrasp_pose) # 视觉伺服修正 pose = vision_servo(grasp_point) # 执行抓取动作 arm.grasp(pose, force_limit=5.0) # 检测夹爪内径和力传感器 if gripper.status == "CLOSED" and gripper.force > 1.0: return "SUCCESS" else: return "FAILED"力控是精细操作的核心。图书场景不能只要求“夹起来”，还要保证“夹得稳、夹不坏”。力传感器反馈的价值在于，机器人可以感知到“接触”“挤压”“滑落”这些状态，从而实时调整夹持力。没有力控，机器人就像蒙着眼睛搬书，结果只能靠运气。
3.3 双足稳定与作业姿态：移动中的平衡和窄空间转向
双足人形机器人和轮式机器人最大的区别，在于移动过程中必须时刻处理平衡问题。消防场景中机器人需要跨过或绕过障碍物，图书场景中需要在狭小书架通道里转身，这两类动作对步态稳定都是挑战。
常用的步态稳定思路是 ZMP 理论。ZMP 是机器人脚底支撑多边形内的一点，当这个点保持在支撑多边形内时，机器人不会倾覆。实际实现中，机器人通过 IMU 感知躯干姿态，通过关节编码器感知每个关节角度，再通过踝关节和髋关节的力矩补偿来维持平衡。
在图书场景里有一个容易被忽略的问题：当机械臂向前伸出去取书时，机器人的质心会前移，如果步态控制器没有补偿这个变化，机器人会向前倾倒。因此，机械臂运动规划要和步态规划联动，在机械臂伸出时，身体重心要向后调整，或者双腿采取更宽的站距。比赛现场看到的“机器人站得稳”，其实是多个控制器协同工作的结果。
3.4 任务编排与异常恢复：日志决定了你能否复盘
一次比赛任务可能包含几十个动作，任何一个动作出现异常，机器人都需要在一个时间窗口内做出反应。任务编排层通常会记录类似下面这样的日志：
[STATE] SEARCH -> target detected, object=fire_extinguisher, conf=0.97 [STATE] APPROACH -> navigate to (3.2, 1.8), cost=12.4s [STATE] MANIPULATE -> grasp attempt 1 failed, force=0.2N [STATE] RETRY -> regrasp at (3.25, 1.85, 0.5) [STATE] MANIPULATE -> grasp success, force=4.8N [STATE] VERIFY -> operation confirmed, task done在异常恢复设计上，推荐采用“局部重试优先、全局重启兜底”的策略。比如夹爪第一次没夹住，先重新执行视觉定位和抓取动作，最多重试三次；三次仍然失败，才执行整个任务的复位流程。这样既能提高成功率，又不会因为单点失败把整个比赛拖垮。
生产环境中还要考虑异常恢复的边界：有些异常不能无限重试，比如电机过热、电池电量不足、安全急停被触发。这时机器人必须停止并请求人工介入，而不是盲目继续执行。
4. 运行验证：把比赛表现转换成一套可量化指标
赛场上拿金牌，说明机器人综合表现领先，但作为技术团队，还需要把“表现好”转换成可测量、可复现、可改进的指标。只有这样，比赛结果才能指导下一轮研发。
4.1 一场机器人比赛任务，可以从五个维度评价
| 评价维度 | 说明 | 赛事指导意义 |
|---|---|---|
| 任务完成度 | 按顺序完成的任务环节占总环节的比例 | 决定最终成绩的核心项 |
| 用时 | 从启动到完成所有任务的总耗时 | 反映各环节衔接效率 |
| 干预次数 | 人工遥控、复位、重新开始的次数 | 越低说明系统自主性越强 |
| 稳定性 | 多次运行的成功率和一致表现 | 防止“单次成功、整体看运气” |
| 安全性 | 是否出现碰撞、跌落、越界等危险动作 | 生产落地最关键的指标 |
比赛现场通常会记录完成度和用时，但内部研发时，更值得关注的是干预次数和稳定性。比如一台机器人完成一次时间很短，但十次里有五次需要人工介入，那它离落地还有很大距离。
4.2 通过数据流确认每个环节是否正常工作
为了让指标体系落地，研发阶段建议把关键数据流打印出来或保存成 rosbag。以 ROS 2 为例，你至少要能查看以下几类数据：
# 查看感知模块是否正常发布目标位姿 ros2 topic echo /perception/target_pose # 查看导航模块执行状态 ros2 topic echo /navigation/status # 查看机械臂是否收到抓取指令 ros2 topic echo /arm/grasp_command # 查看关节电流，判断是否有卡死或碰撞 ros2 topic echo /joint_effort数据流正常，不代表任务执行正确；但数据流异常，通常能快速定位到问题模块。比赛调试时，建议先把每个模块的 topic 频率和内容格式检查一遍，再开始跑完整任务。很多“莫名其妙失败”的根因，都是感知话题没有数据或者数据格式不对。
4.3 用多轮测试替代单次演示
赛事机构在决赛时只看到一次运行结果，但研发团队不能只做一次成功测试。推荐对完整任务连续运行 10 次以上，记录每一次的环节成功率，然后计算整任务成功率。
下面是一个简单统计脚本的思路：
def evaluate(run_results): total_runs = len(run_results) success_runs = sum(1 for r in run_results if r["task_done"] == True) avg_time = sum(r["duration"] for r in run_results) / total_runs intervene_count = sum(r["intervention_count"] for r in run_results) print("整任务成功率:", success_runs / total_runs) print("平均完成时间:", avg_time) print("平均人工干预次数:", intervene_count)这组数据比任何“这是一次完美演示”都有说服力。研发目标应该是“整任务成功率不断上升，人工干预次数不断下降”，而不是“某一次跑得很漂亮”。
5. 赛场上最容易出问题的五个环节与排查思路
人形机器人比赛的高淘汰率，往往不是因为某个算法太难，而是因为稳定性问题。下面五个环节是我认为最值得提前排查的地方，每一个都对应真实比赛中的常见翻车点。
5.1 视觉检测抖动导致目标丢失
现象：机器人走到目标物附近，屏幕上却反复出现“检测到、丢失、再检测到”的情况，任务状态在 SEARCH 和 APPROACH 之间来回切换。
可能原因：光照变化导致模型置信度波动；相机帧率不够；目标物过小或部分遮挡；图像存在运动模糊。
排查方式：录制现场环境数据，查看目标物的置信度曲线；检查相机曝光参数是否固定；确认图像分辨率是否足以覆盖远端目标。
解决建议：优先调整相机曝光和白平衡参数，其次在检测结果里加置信度阈值和帧间平滑，最后考虑多视角检测融合。
5.2 夹爪滑落或夹空
现象：机械臂执行抓取动作后，夹爪闭合，但物体掉落或没有被夹住。
可能原因：抓取点位姿估计不准；夹爪闭合后没有通过力传感器确认；物体表面光滑导致摩擦力不足；抓取接近方向不对。
排查方式：查看视觉模块输出的 grasp_point 与物体实际位置的偏差；读取夹爪闭合后的力反馈数据；回看机械臂接近目标时的轨迹是否与预设方向一致。
解决建议：提高视觉定位精度，增加抓取后的力验证，针对不同物体设计夹具或吸盘，必要时在抓取动作后增加一个“托举”动作避免滑落。
5.3 双足导航偏移导致站位不正
现象：机器人到达目标点附近，但身体朝向与目标物方向偏差较大，导致机械臂无法直接执行操作。
可能原因：导航到达点与操作点分离；步态规划导致累计里程计误差；双足转弯半径过大；身体朝向没有在执行操作前调整。
排查方式：对比导航目标坐标和最终实际停靠坐标；检查状态机是否包含“到达后调姿”环节；查看步态控制器在转弯时的轨迹。
解决建议：把“导航到附近点后调姿”拆成两步，先粗定位再细调；在操作前通过视觉伺服修正身体朝向；如果双足转弯困难，可增加侧向移动和原地小步转向。
5.4 地图漂移导致路径异常
现象：机器人开始阶段导航正常，执行几次操作后，地图上的位置与真实位置越来越不匹配，路径规划出现穿墙或绕远。
可能原因：激光雷达或深度相机在大面积低纹理区域退化；长时间运行累计漂移；动态物体干扰点云匹配。
排查方式：查看地图与实时扫描点云的叠加效果；观察定位话题的协方差或评分；回看机器人长时间运行时的定位轨迹是否有突变。
解决建议：添加全局重定位机制；融合 IMU 和轮式里程计抑制短期漂移；在场地中预设视觉标签或二维码作为路标。
5.5 任务中断后无法恢复
现象：机器人在某个状态内卡住超过 30 秒，没有超时处理，整个任务被裁判判定为失败。
可能原因：状态机缺少超时字段；某个阻塞调用导致调度线程卡死；网络通信中断后感知数据停更但代码没有处理。
排查方式：查看状态机日志最后一条状态；检查是否有异常日志；确认各话题是否有超时检测机制。
解决建议：为每个状态增加超时和重试字段；所有外部数据订阅都设置超时判断；加入看门狗，长时间无心跳时自动进入安全状态。
下表汇总了这五类问题，方便比赛前逐项对照检查：
| 问题类型 | 典型现象 | 优先检查项 | 临时处理 |
|---|---|---|---|
| 检测抖动 | 目标反复丢失 | 曝光、置信度、帧平滑 | 降低置信度阈值并加帧间滤波 |
| 抓取失败 | 物体滑落或抓空 | grasp_point 精度、力反馈 | 增加抓取后验证和重试 |
| 导航偏移 | 停靠点方向不对 | 导航到达点、调姿环节 | 操作前增加视觉伺服调姿 |
| 地图漂移 | 路径逐渐异常 | 定位协方差、点云匹配 | 添加路标或全局重定位 |
| 任务卡死 | 状态长期不跳转 | 超时字段、阻塞调用 | 状态机加超时和看门狗 |
6. 从赛场走向生产：人形机器人落地前至少要补齐这些工程能力
比赛场景是真实世界的一个简化样本。赛场上的墙是平的、地面是硬的、灯光是固定的、任务动作是预先知道的。真实生产环境远比比赛复杂，如果团队目标是让人形机器人从实验室走向工厂、医院、仓库，还需要在赛事技术体系上补齐更多工程能力。
6.1 仿真先行，避免每次调试都依赖真机
人形机器人真机调试成本高、风险大，一套稳定的调试流程应该先跑仿真。在 Gazebo、MuJoCo 或 Isaac Sim 中搭建场景模型，验证状态机逻辑、感知算法和运动规划是否正常，确认无误后再部署到真机。
仿真不是可选项，而是必要步骤。尤其是测试异常恢复逻辑时，仿真可以快速构造“抓取失败、障碍物阻挡、定位漂移”等极端情况，而不必在真机上冒着损坏设备的风险反复尝试。仿真环境与真实环境之间总会存在差异，但至少可以把逻辑错误提前过滤掉。
6.2 构建数据闭环，让每一次现场运行都沉淀价值
赛事现场和真机测试会产生大量数据，包括图像、点云、状态日志、控制指令和最终结果。如果没有数据闭环，这些数据只会在硬盘里吃灰。
建议团队搭建一套数据采集和回放流程：
- 每次运行都自动保存 rosbag 或等效数据包。
- 记录任务最终结果，比如成功、失败、完成时间、干预次数。
- 失败样本单独标记，用于后续算法迭代。
- 定期用回放数据重放失败场景，检验新算法是否修复问题。
数据闭环的意义在于，机器人性能提升不是靠“感觉”，而是靠“用失败数据喂模型和优化规则”。
6.3 生产环境需要额外补齐部署、监控和安全机制
比赛环境里，一台机器人旁边通常有十几名工程师随时准备干预。生产环境没有这个条件，因此必须把“人肉保障”转化为系统能力。
部署方面，建议做到配置外置化。地图文件、模型权重、任务参数、场地标定参数都应该通过配置文件或参数服务器下发，而不是硬编码在代码里。这样换场地时不需要重新编译，只需更新配置。
监控方面，至少要有三条链路：日志系统、指标采集和远程看板。日志用于排错，指标用于趋势分析，看板用于发现异常。比如关节电流持续升高、CPU 使用率异常上涨、导航定位协方差变大，这些都应该能远程看到并触发告警。
安全方面，生产级人形机器人必须有多层保护：机械层的碰撞缓冲和力矩限制、控制层的安全急停、任务层的异常超时和权限控制。这些能力在比赛中可能只是加分项，在生产环境里是底线。
6.4 可复用检查清单：从比赛任务升级到生产部署前
下面的检查清单可以直接拿到项目周会上逐项核对：
| 类别 | 检查项 | 完成状态 |
|---|---|---|
| 软件架构 | 状态机是否包含超时、重试、失败处理 | 未开始 / 进行中 / 已完成 |
| 软件架构 | 感知、导航、控制之间的数据流是否可观测 | 未开始 / 进行中 / 已完成 |
| 感知 | 目标检测置信度阈值是否针对现场调优 | 未开始 / 进行中 / 已完成 |
| 感知 | 是否记录失败样本用于后续迭代 | 未开始 / 进行中 / 已完成 |
| 导航 | 是否验证长时间运行的定位漂移 | 未开始 / 进行中 / 已完成 |
| 操作 | 抓取后是否有力控验证和重试机制 | 未开始 / 进行中 / 已完成 |
| 稳定 | 是否连续测试 10 次以上并记录数据 | 未开始 / 进行中 / 已完成 |
| 安全 | 急停、碰撞检测、力矩限制是否有效 | 未开始 / 进行中 / 已完成 |
| 部署 | 参数和配置是否外置，换场地是否可快速更新 | 未开始 / 进行中 / 已完成 |
| 运维 | 日志、监控告警、远程访问是否可用 | 未开始 / 进行中 / 已完成 |
6.5 给团队的学习路径建议
如果你所在团队刚刚开始做人形机器人，不建议一上来就追求整机跑通完整任务。更稳妥的路径是按照“单模块、小系统、完整任务、多场景”四步推进。
第一步，先把感知、导航、机械臂控制三个模块各自跑通，确认每种传感器和控制器的数据能稳定获取。第二步，用一个简单任务把三个模块串起来，比如“走到指定桌子，抓一个固定位置的方块”。第三步，在任务中加入随机位置、动态障碍和失败重试，提升完整性。第四步，再切换到消防应急场景或图书场景，验证系统是否有跨场景泛化的能力。
智元精灵 G2 在第二届世界人形机器人运动会上拿到的两枚金牌，本质上就是这四个阶段都走完后的结果。赛事成绩可以当作研发进度的证明，但真正有价值的是支撑这两块金牌的技术积累：清晰的软硬件分层、可靠的状态机调度、稳定的感知定位与操作链路，以及对稳定性近乎苛刻的验证方法。
下一步，建议把比赛积累的仿真场景、失败数据集和调试工具沉淀成团队内部资产，并逐步引入更难的任务：开放场地、动态行人、多机协同。人形机器人的技术迭代不是一次演示就能完成的，而是靠每一次失败日志和每一轮可靠性提升堆出来的。
