天工机器人捂脸跑夺冠，团队：没找人教，它自己决定的

{"title_zh":"天工 Omni 的“捂脸跑”：强化学习如何把人形机器人训练成赛场选手","body_zh":"# 天工 Omni 的“捂脸跑”：强化学习如何把人形机器人训练成赛场选手\n\n在第二届世界人形机器人运动会 400 米小型组决赛中，天工 Omni 以 45.66 秒夺冠。比成绩更快传播的，是它捂着脸向前冲的跑姿：动作有点笨拙，却非常有辨识度。\n\n研发团队负责人、运动控制算法专家韩刚表示，这不是找人模仿出来的动作，而是强化学习在训练过程中自行迭代的结果。这个案例值得关注的地方，不是机器人“像不像人”，而是控制系统如何在明确目标下，找到工程师未必会手写出来的运动策略。\n\n## 从“写动作”转向“优化结果”\n\n传统机器人运动控制通常会把步态拆成许多可解释的规则：抬腿高度、落脚位置、躯干角度、摆臂幅度，以及不同速度下的动作切换。这样的方式便于调试，但也意味着工程师要提前猜出一套可行的跑步姿态。\n\n强化学习的思路不同。工程师提供环境、动作空间、观测数据和奖励函数，策略网络反复尝试；当机器人跑得更快、更稳、更接近终点时，获得更高奖励。最终形成的动作可能不符合人的审美，却可能更适合机器人的关节结构、重心分布和执行器限制。\n\n“捂脸”因此不应简单理解为一个被单独设计的表演动作。它可能是摆臂、平衡、躯干稳定和落脚策略共同优化后的结果。只要不影响速度和稳定性，策略就没有理由为了“看起来像人”而舍弃它。\n\n## 速度不是唯一目标：奖励函数决定跑姿\n\n对于 400 米比赛，单纯奖励前进速度可能诱导机器人采取危险策略，例如步幅过大、身体倾角过激，或者在短时间内消耗掉过多能量。实际训练通常需要把多个目标组合起来：\n\n- 沿赛道方向的位移或速度；\n- 跌倒、碰撞和越界惩罚；\n- 姿态稳定性与足底接触约束；\n- 能耗、关节冲击和动作平滑度；\n- 对比赛规则的遵守。\n\n可以把它抽象成一个简化的目标函数：\n\ntext\n总奖励 = 前进奖励\n - 跌倒惩罚\n - 越界惩罚\n - 能耗成本\n - 姿态抖动成本\n\n\n权重的选择会直接改变最终动作。如果把速度权重调得很高，机器人可能跑得激进；如果稳定性权重过高，它可能变成“走得很稳但跑不快”。所谓“自己决定的跑姿”，并不意味着没有人为设计，而是人把偏好写进了目标和约束，具体动作由训练过程搜索出来。\n\n## 一个可运行的奖励函数原型\n\n下面的 Python 示例不是天工 Omni 的实现，而是一个可以直接运行和改造的奖励计算原型。它展示了运动控制训练中如何把速度、稳定性、跌倒和能耗放进同一个评分函数。实际项目还需要物理仿真器、机器人状态估计、策略网络和安全控制层。\n\n运行前只需要安装 Python 3.9 或更高版本；示例本身不依赖第三方库。\n\npython\nfrom dataclasses import dataclass\n\n\n@dataclass\nclass StepState:\n forward_speed: float\n lateral_error: float\n torso_tilt_deg: float\n energy_cost: float\n fallen: bool\n\n\ndef reward(state: StepState) -> float:\n # 这些权重只是演示参数，真实训练需要通过实验和安全指标校准。\n score = 2.0 * state.forward_speed\n score -= 1.5 * abs(state.lateral_error)\n score -= 0.08 * abs(state.torso_tilt_deg)\n score -= 0.02 * state.energy_cost\n\n if state.fallen:\n score -= 100.0\n\n return score\n\n\nif __name__ == "__main__":\n candidates = {\n "aggressive": StepState(3.2, 0.10, 12.0, 80.0, False),\n "stable": StepState(2.4, 0.03, 4.0, 55.0, False),\n "failed": StepState(4.0, 0.30, 20.0, 90.0, True),\n }\n\n for name, state in candidates.items():\n print(f"{name:10s}: reward={reward(state):6.2f}")\n\n\n这个例子也说明了一个容易被忽略的边界：奖励函数并不能自动表达所有工程要求。比如“跑姿是否好看”通常不是必要目标，但“不能撞击关节限位”“不能进入观众区域”“急停后必须保持安全姿态”则应当进入约束、监控或独立的安全控制器。\n\n## 从仿真到赛场，真正困难的是迁移\n\n强化学习在仿真环境中找到有效策略，只完成了一部分工作。真实机器人还会面对模型误差、地面摩擦变化、传感器噪声、关节延迟、电池电量下降和硬件温升。一个在仿真里最快的动作，未必能在真实赛道上稳定复现。\n\n工程上通常需要几层保护：\n\n1. 在仿真中随机化质量、摩擦、延迟和外部扰动，让策略适应不确定性。\n2. 用真实数据校准动力学模型，并逐步扩大真实测试范围。\n3. 在策略输出之外增加关节限位、力矩限制、跌倒检测和急停机制。\n4. 用比赛规则和实际赛道条件验证，而不是只看仿真里的平均速度。\n\n因此，45.66 秒不只是一个策略网络的结果，也包含了机械设计、状态估计、低层控制、训练环境和现场调试的共同作用。强化学习负责探索复杂动作，但系统能否进入赛场，取决于整个控制栈是否可验证、可恢复。\n\n## 工程师可以从这个案例学到什么\n\n天工 Omni 的跑姿提供了一个很实用的判断标准：不要把“人形”误解为“必须复制人的动作”。如果目标是竞技，评价指标应当优先回答机器人是否更快、更稳、更省能、更安全。只要满足约束，非人类风格的动作可能正是机器人利用自身结构优势的方式。\n\n采用类似方法时，可以按这份清单检查：\n\n- 目标是否能被测量，而不是停留在“跑得像人”；\n- 奖励是否同时覆盖速度、稳定性、能耗和规则；\n- 失败状态是否有足够大的惩罚和安全终止条件；\n- 仿真与真实硬件之间的差异是否被显式测试；\n- 策略失效时，是否有独立的限幅、急停和恢复机制；\n- 最终指标是否来自真实赛道，而不是只来自训练曲线。\n\n“捂脸跑”真正有价值的地方，是它让人看到了一种控制范式：人负责定义目标、边界和安全条件，机器通过大量试错寻找动作。未来的人形机器人不一定会以最像人的方式奔跑，但它们可能会逐渐找到更适合自己身体的运动语言。","title_en":"Why Tiangong Omni’s Face-Covering Sprint Matters for Humanoid Robot Control","body_en":"# Why Tiangong Omni’s Face-Covering Sprint Matters for Humanoid Robot Control\n\nTiangong Omni won the small-size 400-meter final at the second World Humanoid Robot Games with a time of 45.66 seconds. The result was impressive, but its running style attracted even more attention: the robot charged forward with its hands covering its face, a motion viewers found oddly human and highly memorable.\n\nHan Gang, a motion-control algorithm expert and lead of the development team, said the team did not hire someone to imitate a young woman’s movement. The gait emerged through reinforcement-learning iterations. That distinction matters. The interesting question is not whether the robot looks human, but how an optimization system can discover a useful movement strategy that engineers might not have written by hand.\n\n## From Handwritten Motions to Optimized Outcomes\n\nConventional robot control often decomposes walking and running into explicit rules: foot clearance, landing position, torso angle, arm swing, and transitions between speeds. This approach is interpretable and practical, but it requires engineers to anticipate a workable gait in advance.\n\nReinforcement learning takes a different route. Engineers define the environment, action space, observations, rewards, and constraints. The policy then explores repeatedly. Faster progress, better balance, and successful completion produce higher rewards. The resulting motion may look unusual, yet still be well suited to the robot’s joint arrangement, center of mass, and actuator limits.\n\nThe face-covering motion should therefore not automatically be treated as a separately scripted performance. It may be the combined result of optimizing arm movement, balance, torso stabilization, and foot placement. If that posture does not reduce speed or stability, the policy has little reason to discard it simply because it looks unlike a human runner.\n\n## Speed Is Only One Objective\n\nRewarding forward speed alone can encourage unsafe behavior: excessive stride length, aggressive body lean, or energy use that cannot be sustained for an entire race. A practical training objective may combine several signals:\n\n- Forward displacement or velocity along the track;\n- Penalties for falling, collisions, and leaving the lane;\n- Postural stability and foot-contact constraints;\n- Energy use, joint impact, and motion smoothness;\n- Compliance with competition rules.\n\nA simplified objective looks like this:\n\ntext\ntotal reward = progress reward\n - fall penalty\n - lane-deviation penalty\n - energy cost\n - posture-jitter cost\n\n\nThe weights directly shape the final gait. A very high speed weight can produce an aggressive runner. An excessive stability weight can produce a robot that is safe but slow. “The robot decided its own gait” does not mean humans had no influence. Human preferences are encoded in the objectives, weights, and constraints; the learning process searches for the concrete motion.\n\n## A Runnable Reward-Function Prototype\n\nThe following Python example is not Tiangong Omni’s implementation. It is a small, runnable prototype showing how speed, stability, falling, and energy can be combined into a training score. A real system would also need a physics simulator, state estimation, a policy network, and an independent safety layer.\n\nRun it with Python 3.9 or newer; it uses only the standard library.\n\npython\nfrom dataclasses import dataclass\n\n\n@dataclass\nclass StepState:\n forward_speed: float\n lateral_error: float\n torso_tilt_deg: float\n energy_cost: float\n fallen: bool\n\n\ndef reward(state: StepState) -> float:\n # Demonstration weights only; calibrate them against real safety metrics.\n score = 2.0 * state.forward_speed\n score -= 1.5 * abs(state.lateral_error)\n score -= 0.08 * abs(state.torso_tilt_deg)\n score -= 0.02 * state.energy_cost\n\n if state.fallen:\n score -= 100.0\n\n return score\n\n\nif __name__ == "__main__":\n candidates = {\n "aggressive": StepState(3.2, 0.10, 12.0, 80.0, False),\n "stable": StepState(2.4, 0.03, 4.0, 55.0, False),\n "failed": StepState(4.0, 0.30, 20.0, 90.0, True),\n }\n\n for name, state in candidates.items():\n print(f"{name:10s}: reward={reward(state):6.2f}")\n\n\nThe prototype also exposes an important boundary: a reward function cannot automatically express every engineering requirement. “Looks human” may be unnecessary for a race, while “never exceeds joint limits,” “does not enter the spectator area,” and “holds a safe posture after an emergency stop” should be implemented as hard constraints, monitors, or separate safety controllers.\n\n## The Hard Part Is Sim-to-Real Transfer\n\nFinding a successful policy in simulation is only part of the job. A physical robot must handle model error, changing ground friction, sensor noise, actuator delay, battery depletion, and thermal effects. The fastest simulated gait may not remain stable on a real track.\n\nA robust engineering process typically includes several layers:\n\n1. Randomize mass, friction, latency, and external disturbances in simulation.\n2. Calibrate the dynamics model with real data and expand physical tests gradually.\n3. Add joint limits, torque limits, fall detection, and emergency stops outside the policy output.\n4. Validate against race rules and real track conditions, rather than relying only on average simulated speed.\n\nThat makes the 45.66-second result more than a policy-network achievement. Mechanical design, state estimation, low-level control, training environments, and trackside debugging all contribute. Reinforcement learning explores complex motions, but the full control stack determines whether those motions are verifiable, recoverable, and safe enough for competition.\n\n## What Engineers Can Take Away\n\nTiangong Omni’s running style suggests a useful evaluation rule: do not confuse being humanoid with copying human movement. For an athletic task, the primary questions are whether the robot is faster, more stable, more energy-efficient, and safer. Within those constraints, an unconventional gait may be exactly how the robot exploits its own body.\n\nBefore adopting a similar approach, check that:\n\n- The objective is measurable rather than simply “run like a human.”\n- Rewards cover speed, stability, energy, and rule compliance.\n- Failure states have strong penalties and clear termination conditions.\n- Simulation-to-hardware differences are tested explicitly.\n- Independent limiting, emergency-stop, and recovery mechanisms exist.\n- Final performance is measured on the real track, not only in training curves.\n\nThe value of the face-covering sprint is that it makes a control paradigm visible: humans define the goals, boundaries, and safety conditions; the machine searches through repeated trials for a movement strategy. Future humanoid robots may not run in the most human-looking way. They may instead develop a motion language better suited to their own bodies.","seo_description_en":"Tiangong Omni’s unusual 400-meter sprint shows how reinforcement learning can discover fast, unconventional humanoid robot gaits under safety constraints."}