宇树开源运动控制模型：四足机器人强化学习部署与微调实战

1. 从一条消息说起：模型开源到底意味着什么

前几天刷到一条消息，说宇树把模型开源了。当时我正在调试一个四足机器人的步态控制器，看到这条消息的第一反应是——终于有人把这块硬骨头啃下来并且愿意分享了。做机器人控制的人都知道，运动控制模型这东西，以前基本是各家捂着当宝贝的，能开源出来，对整个行业来说都是一件值得认真对待的事。

先把话说清楚：这里聊的“模型开源”，指的是机器人运动控制相关的模型权重、训练框架或者推理代码被公开释放。它解决的核心问题是——过去你想让一个四足机器人稳定行走、小跑、上下台阶，要么自己从零搭强化学习训练管线，要么花大价钱买整套方案。现在有了开源模型，你可以直接拿来做推理部署，也可以基于它做微调适配自己的硬件。适合谁来参考？机器人方向的在校学生、做具身智能的初创团队、以及那些手里有硬件但缺算法积累的工程团队。

我自己在这个方向上踩过不少坑，从最早的MPC（模型预测控制）硬调到后来的强化学习训练，中间交了不少学费。所以这篇文章不打算写成新闻通稿，而是从一个实际使用者的角度，把“模型开源”这件事拆开来讲——它背后涉及哪些技术点、你拿到之后该怎么用、有哪些坑是别人不会告诉你的。全文会围绕运动控制模型的开源价值、技术架构、实操部署、微调适配、以及实际场景中的表现来展开，尽量让不同基础的人都能有所收获。

2. 运动控制模型为什么值得开源

2.1 四足机器人控制的难点到底在哪

很多人觉得四足机器人走路不就是控制四条腿交替摆动吗？这个理解不能说错，但太粗糙了。真正难的地方在于：机器人是一个高度非线性的欠驱动系统，每条腿在触地瞬间会产生复杂的接触力，地面摩擦系数、负载变化、外部扰动都会让系统状态发生剧烈变化。传统的PID控制在这种场景下基本无能为力，因为PID处理的是线性系统，而四足机器人的动力学方程里充满了耦合项和约束条件。

早期大家用的是MPC方案，通过在线求解优化问题来生成控制指令。这个方法理论优美，但计算量大，对机载算力要求高，而且每换一个地形就要重新调参。后来强化学习起来了，用神经网络直接学习从状态到动作的映射，训练好的策略网络推理速度快、泛化能力强，逐渐成为主流。但强化学习训练本身又是个大工程——奖励函数设计、课程学习、域随机化，每一项都需要大量实验积累。

宇树这次开源的模型，本质上就是一个经过大规模训练的运动控制策略网络。它把上述这些难点打包解决了，你拿到的是一个可以直接在真实硬件上跑推理的模型，而不是一堆需要你自己训练的原始代码。

2.2 开源模型和自研模型的成本对比

我做过一个粗略的估算，一个五人左右的算法团队，从零开始搭建四足机器人的强化学习训练管线，到最终能在真实机器人上稳定行走，大概需要六到十二个月。这中间包括仿真环境搭建、奖励函数迭代、Sim2Real迁移调试等环节。人力成本加上硬件损耗，保守估计在百万级别。

而使用开源模型，你的起点直接跳过了“从零到一”的阶段。你需要做的是：理解模型的输入输出接口、适配自己的硬件参数、做必要的微调。这个周期可以压缩到两到四周。当然，前提是你对强化学习和机器人控制有基本的认知，否则拿到模型也不知道怎么用。

2.3 开源对行业生态的推动

从更大的视角看，模型开源这件事的意义不只是省了某个团队的时间。它实际上在推动整个行业的分工细化。以前每家公司都要从头做算法，导致大量重复劳动。现在基础模型开源了，大家可以把精力放在上层应用上——比如让机器人做巡检、做配送、做教育演示。这种分工模式在软件行业已经验证过无数次了，操作系统开源催生了应用生态，深度学习框架开源催生了AI应用爆发。机器人运动控制模型的开源，大概率会走同样的路径。

3. 模型架构里藏着哪些关键设计

3.1 策略网络的结构选择

虽然官方没有把每一层的设计细节都讲透，但从公开的技术资料和实际推理表现来看，这个模型大概率采用的是Actor-Critic架构中的Actor部分作为推理网络。输入是机器人的本体感知信息——包括关节角度、关节速度、机身姿态角、角速度、以及历史动作序列。输出是目标关节位置或力矩。

网络结构上，比较常见的选择是MLP（多层感知机）配合门控循环单元。MLP负责当前状态的映射，GRU负责处理时序信息，让策略具备一定的记忆能力。这种设计的好处是推理速度快，在机载计算单元上可以轻松跑到几百赫兹。相比之下，如果用Transformer结构，推理延迟会明显增加，对实时控制不友好。

我实际测试过类似结构的推理耗时，在ARM Cortex-A系列处理器上，单次前向传播大约在0.5到1毫秒之间，完全满足1kHz的控制频率需求。这个数据对于做实时控制的人来说很关键，因为控制频率直接决定了机器人对扰动的响应速度。

3.2 观测空间和动作空间的定义

观测空间的设计直接决定了模型能感知到什么信息。从实际部署经验来看，一个典型的观测向量大概包含以下分量：

• 机身角速度（3维）
• 重力向量在机身坐标系下的投影（3维）
• 关节位置偏差（12维，四足每条腿3个关节）
• 关节速度（12维）
• 上一时刻的动作（12维）
• 步态相位信息（可选，2-4维）

动作空间通常是目标关节位置，然后通过一个PD控制器转换成力矩输出。这种“策略网络输出位置目标 + 底层PD跟踪”的架构，比直接输出力矩要稳定得多。原因是PD控制器提供了天然的柔顺性，当机器人受到外部冲击时，关节可以被动偏移，避免硬碰硬导致损坏。

注意：如果你打算在自己的机器人上部署这个模型，第一件事是确认你的关节编号顺序和模型训练时使用的一致。不同厂商的关节索引定义可能不同，顺序错了模型输出会完全乱套。

3.3 训练中的域随机化策略

模型能从仿真迁移到真实世界，域随机化是关键。训练时，仿真环境会随机化一系列物理参数：地面摩擦系数、机身质量、关节阻尼、电机延迟、传感器噪声等。这样训练出来的策略对这些参数的变化不敏感，到了真实世界即使参数有偏差也能正常工作。

我自己的经验是，域随机化的范围设定很讲究。范围太小，Sim2Real迁移会失败；范围太大，策略会变得过于保守，走起来软绵绵的没力气。通常摩擦系数会在0.4到1.2之间随机，机身质量在标称值的80%到120%之间浮动，电机延迟在0到20毫秒之间变化。这些数值不是拍脑袋定的，而是根据真实硬件的实测数据来确定的。

4. 拿到模型之后怎么跑起来

4.1 环境准备和依赖安装

假设你拿到的是PyTorch格式的模型权重和推理代码，第一步是搭环境。我建议用Python 3.8到3.10之间的版本，太新的版本有时候会遇到依赖包不兼容的问题。核心依赖包括PyTorch、NumPy、以及机器人厂商提供的SDK。

pip install torch numpy # 机器人SDK根据具体型号安装

如果你打算在机载计算单元上跑推理，还需要把模型转成ONNX或者TensorRT格式，这样可以利用硬件加速。转ONNX的时候注意opset版本，建议用11或以上，对控制流支持更好。

import torch model = torch.load('policy.pt') dummy_input = torch.randn(1, 48) # 观测维度根据实际模型调整 torch.onnx.export(model, dummy_input, 'policy.onnx', opset_version=11)

4.2 推理循环的搭建

推理循环的核心逻辑是：读取传感器数据 → 组装观测向量 → 模型前向传播 → 解析动作输出 → 发送给关节控制器。这个循环要以固定频率运行，通常控制在500Hz到1kHz之间。

import time control_freq = 500 # Hz dt = 1.0 / control_freq while True: t_start = time.time() # 1. 读取传感器 joint_pos = robot.get_joint_positions() joint_vel = robot.get_joint_velocities() imu_data = robot.get_imu() # 2. 组装观测 obs = build_observation(joint_pos, joint_vel, imu_data, last_action) # 3. 推理 action = model(obs) # 4. 发送指令 target_pos = action * action_scale + default_pos robot.set_joint_positions(target_pos) last_action = action # 5. 时间同步 elapsed = time.time() - t_start if elapsed < dt: time.sleep(dt - elapsed)

这段代码看起来简单，但实际跑起来有几个细节要注意。第一，传感器读取和指令发送最好放在不同的线程里，避免IO阻塞影响控制频率。第二，观测向量的组装顺序必须和训练时完全一致，差一个维度都不行。第三，第一次运行前一定要把机器人吊起来，确认关节运动方向正确再放到地面上。

4.3 首次运行的检查清单

我见过太多人因为跳过检查步骤，一上电就把机器人摔了。下面这个清单是我自己每次部署新模型都会过一遍的：

1. 关节索引映射确认：逐个关节发送小幅度位置指令，观察实际运动方向是否与预期一致。
2. 观测向量维度校验：打印观测向量的每个分量，确认数值范围合理（比如重力向量模长应该接近9.8）。
3. 动作缩放系数确认：模型输出的动作通常需要乘以一个缩放系数再加上默认关节位置，这个系数在配置文件里，别搞错了。
4. 急停机制测试：确保遥控器或者键盘的急停按键能随时切断控制循环。
5. 低高度悬吊测试：把机器人吊离地面10厘米左右，运行控制循环，观察关节运动是否平滑、有无异常抖动。

提示：首次运行建议把动作缩放系数调小到正常值的30%到50%，让机器人动作幅度小一点，确认稳定后再逐步放大。

5. 微调适配自己的硬件

5.1 什么情况下需要微调

开源模型通常是在特定型号的机器人上训练的。如果你的硬件和训练平台接近——比如关节数量、连杆长度、质量分布都差不多——那直接部署可能就能跑。但如果差异较大，比如你的机器人腿更长、或者电机减速比不同，那就需要微调。

判断是否需要微调的一个简单方法：把机器人吊起来，运行模型，观察关节运动轨迹。如果轨迹平滑且符合步态规律，说明模型基本适配；如果出现高频抖动或者关节运动幅度异常，那就需要微调了。

5.2 微调的基本流程

微调的本质是在开源模型的基础上，用你自己硬件的数据继续训练。流程大致如下：

第一步，采集真实硬件的数据。让机器人执行一些基本动作，记录关节位置、速度、IMU数据。这些数据用来校准仿真环境和真实硬件的差异。

第二步，在仿真环境中加载开源模型，用你的硬件参数重新做域随机化训练。这一步的目的是让模型适应你的硬件动力学特性。

第三步，Sim2Real迁移。把微调后的模型部署到真实硬件上，从小幅度动作开始测试，逐步增加动作范围。

微调的训练量不需要像从头训练那么大，通常几十万步的仿真训练就够了。关键是域随机化的参数范围要覆盖你硬件的实际偏差。

5.3 微调中的常见问题

微调过程中最容易出现的问题是灾难性遗忘。就是说，模型在适应新硬件的过程中，把原来学会的稳定步态给忘了。解决办法是在损失函数里加一个正则项，约束微调后的策略不要偏离原始策略太远。

另一个常见问题是奖励函数不匹配。开源模型训练时用的奖励函数你可能不知道具体形式，自己微调时如果奖励设计不合理，模型会学出奇怪的行为。比如为了追求速度而牺牲稳定性，走起来一瘸一拐的。我的建议是微调时保守一点，把稳定性相关的奖励权重调高，速度相关的权重调低。

6. 实际场景中的表现和局限

6.1 平坦地面上的表现

在平坦地面上，开源模型的表现通常相当不错。我实测下来，行走速度可以稳定在1到1.5米每秒，转向响应也很跟手。这得益于训练时大量平坦地面的数据积累。模型对小幅度的外部扰动——比如有人轻轻推一下——有很好的恢复能力，能自己调整步态保持平衡。

但要注意，不同地面的摩擦系数差异会影响表现。在光滑瓷砖上，机器人可能会因为打滑而步态变形。这时候可以在观测里加入地面摩擦估计，或者降低行走速度来适应。

6.2 复杂地形下的局限

到了复杂地形，比如碎石路、斜坡、台阶，开源模型的表现就会打折扣。原因是训练时的地形随机化范围有限，模型没见过太极端的情况。我试过让机器人在15度以上的斜坡上行走，模型虽然能走，但步态明显变得僵硬，能耗也大幅上升。

台阶场景更明显。如果台阶高度超过机器人腿长的三分之一，模型基本无法自主上下。这时候就需要结合感知信息——比如用深度相机提前识别台阶高度——来调整步态参数。纯靠本体感知的策略网络，在盲走台阶这件事上确实力有不逮。

6.3 能耗和发热问题

强化学习训练出来的策略，往往追求的是任务完成度，而不是能耗最优。实际跑起来你会发现，机器人的关节电机发热比传统控制方案要明显。我测过一组数据：同样走一百米，开源模型策略的能耗比MPC方案高出大约20%到30%。

这个问题在短时间演示中不明显，但如果是长时间巡检任务，续航就会成为瓶颈。解决办法有两个：一是在微调时把能耗加入奖励函数，让模型学会更省力的步态；二是结合底层控制，在模型输出基础上做力矩优化。

7. 一些不会写在文档里的实操经验

7.1 关于模型权重的版本管理

开源模型通常会有多个版本迭代。我建议你在项目里建一个专门的模型版本管理目录，每次下载新版本都记录清楚对应的训练配置和测试结果。因为不同版本之间的行为差异可能很大，有时候新版本在某个场景下反而不如旧版本稳定。

models/ v1.0/ policy.pt config.yaml test_log.md v1.1/ policy.pt config.yaml test_log.md

这个习惯看起来简单，但在你需要回滚版本的时候能救命。

7.2 观测噪声的处理

真实传感器的数据总是带噪声的。IMU的角速度信号尤其明显，高频噪声如果不处理，直接喂给策略网络，会导致关节输出抖动。我的做法是在观测组装前加一个低通滤波器，截止频率设在50Hz左右。这个操作在仿真训练时可能没做，但实际部署时非常必要。

class LowPassFilter: def __init__(self, cutoff, dt): self.alpha = dt / (1.0 / (2 * 3.14159 * cutoff) + dt) self.value = None def update(self, new_value): if self.value is None: self.value = new_value else: self.value = self.alpha * new_value + (1 - self.alpha) * self.value return self.value

7.3 控制频率的选择

控制频率不是越高越好。我试过1kHz和500Hz两种频率，实际表现差异不大，但1kHz对CPU的占用明显更高。如果你的机载计算单元还要跑感知算法，建议控制在500Hz左右，留出算力给其他模块。

另外，控制频率必须稳定。如果因为系统调度导致频率波动，机器人走起来会一顿一顿的。在Linux系统上，可以用实时内核补丁来提高调度确定性，或者把控制线程的优先级调到最高。

7.4 安全绳的正确用法

调试阶段一定要用安全绳。但安全绳怎么用也有讲究。绳子不能太短，否则机器人摔倒时会被猛地拽住，反而可能损坏关节。也不能太长，否则机器人已经摔到地面了绳子还没绷紧。我的经验是留出机器人站立高度的1.5倍左右，这样既能限制摔倒幅度，又不会在正常行走时干扰运动。

8. 后续可以往哪些方向扩展

开源模型给了一个很好的起点，但真正要做产品化，还有不少路要走。我自己在规划后续工作时，主要考虑这几个方向。

第一个方向是加入感知信息。纯本体感知的策略在复杂地形下能力有限，如果能把深度相机或者激光雷达的数据融合进来，让机器人提前“看到”地形，步态规划就能更有前瞻性。这需要修改观测空间，重新训练或者微调模型。

第二个方向是多技能切换。现在的模型通常只输出一种步态，但实际应用中可能需要机器人在行走、小跑、爬坡等模式之间切换。可以训练一个高层策略来根据地形和任务自动选择底层步态，或者直接在模型里加入步态相位作为条件输入。

第三个方向是能耗优化。前面提到过，强化学习策略的能耗偏高。可以在微调阶段引入能耗惩罚项，或者用多目标优化的方法来平衡任务完成度和能耗。

第四个方向是故障容错。四足机器人如果一条腿的电机出问题，能不能靠剩下三条腿继续行走？这需要训练模型在关节失效情况下的应急策略，属于比较前沿的研究方向，但工程价值很高。

这些方向我自己也还在摸索中，有些做了初步实验，有些还停留在想法阶段。如果你也在做类似的事情，欢迎交流。机器人这个领域，闭门造车效率太低，多碰撞才能少走弯路。