机器人控制选型：走路用强化学习，干活用Transformer

1. 先分清：机器人控制里其实有两条完全不同的赛道

最近在调一台轮足机器人和一台桌面机械臂，我逐渐意识到一个挺有意思的现象：同属机器人控制，四足和轮足“走路”这块，大家基本默认上RL（强化学习），什么PPO、SAC一套流程跑下来，步态自然就出来了；而一到机械臂抓取、倒水、整理桌面这些“干活”任务，讨论的重点就变成了Transformer、VLA、动作token这些东西。

这不是跟风，而是两类任务在底层的物理特性和信息结构完完全全不一样。千万别看到一个机器人用了Transformer就觉得“高级”，或者看到RL就觉得“这个更智能”，选错方案是真的会把自己坑到怀疑人生。

先给结论：“走路”本质上是高频率、低维度、强稳定性的连续控制问题，奖励信号明确、试错成本低，RL天然擅长；“干活”本质上是低频率、高语义、强泛化性的序列决策问题，需要理解视觉、语言、物体关系，Transformer的注意力机制刚好能把这些异源模态揉在一起。

1.1 运动控制的本质：高频反馈下稳定动力学

机器人“走路”，不管四足、双足还是轮足，核心是实时把姿态稳住。你去看实物机器人的控制频率，通常在500Hz到1kHz甚至更高，每个控制周期只有几毫秒，控制器要在这几毫秒内根据imu的角速度、加速度、关节角度、足端触地信号，算出一组关节力矩或者关节目标角度。

以前做传统运动控制用的是模型预测控制加全身动力学控制，这方案本身没问题，而且在某些场景下比RL更稳。难点在于动力学模型得足够准。地面是硬的还是软的、摩擦系数多少、机器人负载变了多少，这些在真实世界里很难精确建出来。模型一偏差，MPC的预测就有偏差，最后表现就是“理论很稳，一跑就劈叉”。

RL走的是另一条路：不依赖精确模型，让策略神经网络在大量仿真和真机数据里自己摸规律。散步、爬坡、被人踹一脚还能稳住，本质是学出了一个“稳定吸引子”。对应到数学上，策略网络把当前状态映射到动作，这个映射在高维空间里被训练得足够平滑、足够鲁棒，所以干扰来了它能自己绕回去。

1.2 操作控制的本质：开放环境下的语义决策

再看“干活”。机械臂要抓一个杯子，这个任务表面上是轨迹规划问题，但真正难的是几个隐藏在背后的点：杯子的位置和姿态要通过视觉估计，不同杯子形状颜色千差万别，杯子旁边还有别的东西可能遮挡，语言指令可能是“把红色那个杯子放到托盘里”，怎么从图像里分清楚哪个是红色、哪个是目标托盘，这是感知理解问题。

操作任务的更新频率往往不高，视觉反馈能到30Hz已经不错了，机械臂末端轨迹插补在100Hz级别，但真正做决策判断的频率通常就是几个赫兹到30赫兹。换句话说，干活的重点不是“我每一毫秒怎么稳住姿态”，而是“我理解了当前场景之后，下一步该伸出哪只手、往哪个方向、抓哪里”。

传统工业机器人解决这个问题的办法是预设程序。比如有些工业场景用库卡机器人的外部控制模板，把每一段轨迹都事先测试好，夹具、工件、工位都是固定位置，换一个摆放角度就得重新示教。这套方案在批量生产里效率极高，但一旦环境开放一点、任务多变一点，就完全不够用。操作控制真正需要的不是精确到毫秒的稳定性，而是对环境的理解能力和泛化能力。

用一张表来看这两条赛道的差别会更直观：

2. “走路”用RL：为什么试错机制恰好匹配步态问题

我之前带过几个刚入门的同学做四足机器人，他们第一个问题几乎都是：“为什么不直接写一个正弦摆腿让四足走起来？”确实，简单步态可以手写，但赛道一加速、路面一开始不平整、遇到台阶或者被推一下，手写的规则就崩了。RL本质上是用一个通用优化过程替代人工设计所有边界情况。

2.1 RL解决问题的逻辑：给奖励，让它自己试

强化学习的基本框架是马尔可夫决策过程：智能体在每个时刻看到状态$s_t$，做出动作$a_t$，环境返回下一个状态$s_{t+1}$和即时奖励$r_t$。目标是把期望累计奖励最大化。

走路这个任务在RL框架下非常好描述：动作空间就是每条腿的关节目标角度或力矩，状态空间是机身的姿态、角速度、关节角度、足端触地状态，奖励函数可以设计成“走得快给正奖励，翻倒给负奖励，能耗高给负奖励”。四足机器人单步跌倒的成本在仿真里几乎为零，重启一次只需要零点几秒，所以RL的试错优势能完全发挥。

真正把RL做上线，算法选型通常是PPO或者SAC。我做四足和轮足都会优先试试PPO，原因是PPO的策略更新幅度受到裁剪限制，训练稳定、超参数容错度高；SAC在采样效率上有优势，但在高维连续控制里熵项调不好容易动作抖动，部署到真机上反而更折腾。

2.2 从仿真到真机：一个四足走路的训练实例

我自己的标准流程是这个：先用Isaac Gym这类GPU并行仿真环境搭建机器人模型和地形，开启上千个并行环境同时跑，然后用PPO训练策略网络。策略网络输入一个大概二十几个维度的状态向量，中间两三层MLP，输出每条腿关节的目标角度。

奖励函数是这类任务里最见功夫的地方。下面是一个简化版的例子，能看出基本组成：

def reward_function(obs, action, target_speed): vx = obs["base_lin_vel_x"] # 1. 速度跟踪：机器人速度越接近目标速度奖励越高 r_speed = torch.exp(-2.0 * (vx - target_speed) ** 2) # 2. 姿态惩罚：机身倾斜角越小越好 r_pose = torch.exp(-3.0 * obs["base_angle_z"] ** 2) # 3. 能耗惩罚：动作幅值不能太大，否则白费电还容易抖 r_energy = -0.02 * torch.sum(action ** 2) # 4. 触地惩罚：足端冲击力过大会损坏硬件 r_contact = -0.01 * torch.sum(contact_force ** 2) # 5. 存活奖励：没摔倒就有基本奖励 r_alive = 0.5 return r_speed + r_pose + r_energy + r_contact + r_alive

这个奖励组合看起来简单，实际调的时候每个权重背后都是血泪。速度跟踪权重给低了，机器人会站在原地不动；姿态惩罚给高了，机器人为了保持姿态会小碎步不敢走；能耗惩罚给太狠，动作幅度被压到走不出正常步态。我一般先让速度项主导跑出一个能走的策略，再加其他惩罚项微调，而不是一次把所有项全堆上去。

训练完成后往真机迁移，有几件事必须做扎实。第一是域随机化，仿真里要给质量、摩擦系数、电机强度、控制延迟随机加扰动，否则仿真策略到真机上会直接“水土不服”。第二是策略输出要经过低通滤波，否则策略网络输出的小抖动会放大成电机噪声。第三是控制频率要对齐，仿真里如果每20毫秒推理一次策略，真机也必须按这个频率来，突然把频率提到500Hz并不会让机器人更稳，反而放大噪声。

2.3 为什么让Transformer来“走路”通常不太对

很多论文和开源项目里其实也出现过用Transformer做足式机器人控制的研究，但你要讲落地效果，它并没有全面碾压MLP加循环网络。我理解背后的原因主要有三点。

Transformer的优势是长程依赖和跨模态关联，而步态控制本质上是一个极短时延的闭环反馈问题。决策延迟每增加几毫秒，姿态恢复的反应速度就慢一截。Transformer比MLP多了注意力计算，推理延迟更高，这对1kHz控制来说非常致命。

Transformer生成的动作往往偏“平滑平均”。我很早之前试过把Transformer当作策略网络接在四足仿真里，训练出来的步态动作虽然统计指标看着正常，但实机跑起来总感觉动作“软绵绵的”。接触切换这种锐利变化，需要策略精确地在支撑相和摆动相之间切换，而不是在一堆历史模式里求平均。

高频控制需要一个“低延迟的响应函数”，而不是一个“深度理解器”。可以说走路问题用RL是因为它把问题建模成奖励最大化的动态优化，而动态优化天然就该高频在线更新；Transformer更适合离线建模复杂分布，这一步在操作任务里反而是优势。

3. “干活”用Transformer：为什么序列建模恰好匹配操作问题

很多人对Transformer在机器人里面的作用有误解，以为它就是用来处理语言或者图像的。其实Transformer本质上是一个通用的序列建模工具，你给它一串带位置编码的token，它通过自注意力机制让每个token看全局，最终输出预测。热搜词里那些“transformer模型详解”“transformer预测正弦函数”“transformer的位置信息怎么计算”，本质都是在说同一件事：Transformer能把一个序列里的依赖关系学到足够深，从而预测序列的下一个合理内容。

放到机器人操作里，这个序列就是“视觉帧 + 语言指令 + 机器人历史状态/动作”。你让Transformer预测下一个动作token，本质上就是在预测“在当前的场景上下文里，机器人下一步要做什么”。你看，这就是干活的核心。

3.1 操作任务需要的是“理解”而不是“稳住”

机械臂抓取杯子这个场景，你拆一下输入输出就明白了。视觉输入是高清图片或视频，语言输入是一句指令：“把红色杯子放到托盘里”，状态输入是机械臂当前各个关节角度和夹爪开合。这几种输入的格式完全不一样：图像是像素矩阵，语言是离散符号，动作是连续向量。以前的做法是用好几个单独的模型分别处理，再手写规则拼起来，一旦环境一换，规则就崩。

Transformer的注意力机制最擅长干的事情，就是把这些异源模态放在同一个token序列里做交互。图像被切成patch编码成token，语言被分词编码成token，动作历史也被离散化编码成token。自注意力让视觉token和语言token之间互相“开会”：语言里的“红色杯子”会强相关地分配到图像里那些红色杯子对应的patch token上，模型于是知道“指令中的红色”对应“画面里的这一块区域”。

这种感觉很像人干活：“我看到了什么”和“我要做什么”在脑子里是对齐的。Transformer让机器人第一次能在统一框架里完成这个对齐。

3.2 VLA路线：从RT-1到π0，以及背后的设计取舍

Transformer干活的经典实现路线是VLA，也就是视觉-语言-动作模型。我从头梳理一下这个方向的关键节点，你会看到这个领域也在不断演进。

RT-1是比较早期的代表。它把一个预训练的视觉-语言模型作为骨架，把所有感知信息编码成token，然后输出动作token。这里的核心设计是动作离散化：连续动作空间被切割成256个离散token，模型不直接回归动作值，而是预测离散动作类别。好处是分类问题比回归问题好训练，缺点是离散化会损失一部分动作精度。RT-1决策频率只有3到5Hz，但实际部署时会配合底层的高速插补控制器，整体也能跑起来。

RT-2的改动更大，它直接把动作token当成文本生成任务来处理。输入图像和语言后，模型输出的候选token里包含动作token，训练时用大规模互联网数据先预训练，再用机器人数据微调。这条路证明了互联网级别的视觉语言预训练对机器人控制有很强的迁移价值。但也暴露出一个问题：通用模型参数量巨大，部署成本高，真机上推理延迟感人。

π0是我近期比较关注的方向。它的动作头改成了流匹配，流匹配可以理解为把连续动作分布建模成从噪声逐步去噪的过程，类似扩散模型的思路，能表达多峰动作分布。真实操任务里，同一个观察可能对应多个合理动作，比如抓杯子可以抓杯口也可以抓杯身，如果模型只预测一个平均动作，反而会得到一个两边都不挨着的“中间动作”。流匹配头缓解了这个问题。

我自己在桌面倒水、叠毛巾这类任务上用VLA做主控，整体流程大概是这样的：遥操作采集轨迹数据，每一帧保存图像、关节状态、动作指令，再把所有数据统一格式化成观测序列和动作序列；训练时序列长度控制在几十个token以内，因为机器人任务上下文不像长文本那么长；推理时模型每200毫秒左右产出一个目标末端位姿或者关节动作，再交给底层PD控制器执行。

3.3 做操作任务时需要注意的几个实际操作点

Transformer不是拿过来就能跑的，我自己踩过不少次坑，挑几个影响最大的说。

数据的一致性非常关键。同一套数据里，如果有的轨迹机械臂从左边抓，有的从右边抓，模型虽然理论上能拟合多峰，但训练收敛速度会变慢，而且容易在中间状态犹豫。我现在的做法是尽量控制数据采集时的执行方式，给任务加一点规范化指导，花在数据整理上的时间远多于模型调参。

位置编码的选择会影响泛化。热词里反复提到的“transformer的位置信息怎么计算”，在机器人场景同样存在。视觉帧里的物体位置会随相机视角变化，绝对位置编码对训练时见过的视角有记忆，换视角效果就下降；旋转位置编码RoPE对相对位置建模得更好，在处理机械臂多视角数据时泛化性更强。现在新的VLA模型基本都用RoPE这类相对位置编码。

决策频率和动作平滑之间的矛盾要处理好。Transformer推理天然带延迟，高频输出不现实，但机械臂又不能一个周期只跳一个大动作。我的办法是Transformer输出较长时间尺度的目标动作，比如未来半秒的期望末端位姿，然后底层用高速插补和PD控制去跟踪这一小段轨迹。这样既有语义级的决策能力，又有高频的平滑执行，两端都兼顾了。

4. 它们不是取代关系：生产中更常见的是分层配合

聊到这里有朋友会问：那不还是各干各的吗？现实确实如此。很多全自主机器人实际跑起来并不是一个大型模型包打天下，而是用Transformer干“理解与规划”，用RL干“稳定与执行”。

4.1 高层规划Transformer、低层运动RL的分层架构

拿轮足机器人举例。它的底盘控制频率要求极高，电机要实时响应，这一层通常是用RL或者传统控制做的，输入低维状态，输出关节力矩，保证机器人不摔。但轮足机器人接到“去厨房拿一瓶水”这种任务时，低层控制根本不知道“厨房”在哪，它只知道如何保持平衡。这时需要一个高层模型感知环境、理解指令、规划路径，输出一个个子目标点。这个角色由Transformer来做非常合适，因为它擅长视觉语言编码和长程推理。

这种分层思路在学术上叫“导航规划+运动控制”解耦。你可以把Transformer想象成公司老板，负责定方向和拆解任务；把RL想象成前线工人，负责把每一个动作做稳做扎实。老板不需要自己拧螺丝，工人也不需要研究公司战略。

家用机器人领域这个趋势更明显。机器人先在客厅里用视觉语言模型理解“玄关的钥匙”，然后规划一条路径，低层导航用RL避开沙发和茶几。到了目标位置，机械臂部分再用VLA模型做抓取，抓取过程中的关节插补和力矩保护又是低层控制的事。每一层都在做自己最擅长的事情。

4.2 机器人控制方案选型决策清单

我给项目做技术选型时基本按下面几个维度打分，分清楚之后方案自然就定了：

这张表不是绝对标准，但能覆盖绝大多数情况。看到新项目第一件事不是问“这个任务能不能用大模型”，而是问“这个任务核心是物理稳定性还是语义理解”。核心问题定了，算法路线基本就锁死了。

5. 常见误区与排查思路

作为一个既在仿真里调过RL、也被VLA数据折磨过的人，我把常遇到的问题和排查方法整理一下。这里面不少坑，我都是真金白银踩出来的。

5.1 “我的任务到底该用哪个”判断框架

第一个误区是“Transformer是新技术，所以所有任务都应该试试”。实际上，如果你的任务是高频、连续的稳定控制，用Transformer就是在给系统增加一个又重又慢的瓶颈。判断框架很简单：如果任务输入是向量、输出是向量、控制频率需求在几百赫兹以上，优先考虑RL或传统控制；如果任务输入是图像和语义、输出是稀疏决策点、控制频率需求不高，优先考虑Transformer。

第二个误区是“RL可以替代所有规划问题”。操作任务里如果奖励定义不出来，RL训练出来的策略往往严重退化。我有一次想让机械臂学“把积木叠起来”，奖励写了半天也找不到合适的稀疏奖励设计，最后转向行为克隆加VLA反而一周就有可接受的效果。不要盲目迷信算法，让任务特点决定算法。

5.2 典型翻车现场与紧急解决办法

5.3 关于数据与奖励的几条独家提醒

数据质量和奖励设计是整个控制方案里最耗时间的部分，模型本身反而不是瓶颈。操作任务里的Transformer模型，很多时候效果差不是模型不好，而是数据里存在大量不一致和冲突。比如同一个指令对应多种不同做法，模型学的就是一种平均行为，动作难免“犹豫”。

RL奖励权重也一样。早期我的做法是参考别人的开源配置直接跑，结果四足机器人要么原地转圈要么原地蹦，后来发现核心问题不是网络结构，而是奖励项之间的权重比例完全不适合我的机器人构型。调参没有捷径，只能一个一个消融验证，先跑通最简任务再往复杂里加。

一个小技巧是训练过程中把奖励曲线和机器人行为录像同步保存。看录像比看曲线直观得多，能快速定位问题在哪一步出现。很多朋友训练一晚上，第二天发现策略崩了，连崩溃前发生了什么都不知道，就是因为没有留录像。

我个人在实际操作中最深的体会是：算法的选择不是品味问题，是任务需求决定的。走路和干活是两类物理本质完全不同的控制问题，RL擅长在高速反馈中寻找稳定策略，Transformer擅长在复杂语义中寻找下一步动作。做项目时先蹲下来想清楚“这个任务的高频是什么、低频是什么、需要多快的响应”，比急着套一个大模型框架重要得多。最后分享一个小习惯：技术方案选型之前，先写一份两页纸的决策文档，把任务频率、反馈模态、试错成本、数据可获取性写清楚。这四样东西写明白了，你自然就知道该往哪个方向走了。