双足机器人高速奔跑技术拆解：从运动模式到控制算法

最近不少朋友在转发一条消息：中国机器人在北京跑出了极为夸张的短跑速度，甚至被拿来和人类顶尖短跑运动员做对比。这类新闻很容易被归进“又一个机器人新突破”的标题党里，但站在开发者视角，真正值得关心的问题不是“它跑得有多快”，而是“一台双足机器人凭什么能跑得这么稳”。

双足机器人从“能走”到“能跑”，中间隔着的不是几行代码，而是执行器、实时控制、动力学建模、能源系统、结构轻量化等一系列工程问题的综合体。如果只看表面，很容易误以为速度突破是某个算法突然开窍，实际却是一整套系统在极限工况下协同工作的结果。

这篇文章不打算复述新闻细节，也不会去猜测所谓“纪录”的当前数值，而是想做一件更贴近技术本身的事：把机器人高速奔跑拆成运动模式、硬件、控制、测试和验证几个维度，说清楚每一环都发生了什么。无论你是刚接触机器人的学生，还是在工业机器人项目里想转运动控制的工程师，读完都能建立一套可复用的技术分析框架。

1. 机器人跑得快，真正难的不是“快”，而是“稳”

很多人第一次看到双足机器人跑步，都会有一个直觉疑问：让两个腿交替落地保持不倒，已经够难了，为什么还要往高速方向做？工业环境里难道不是慢速、平稳、可重复更重要吗？

这个疑问本身没有错，但它忽略了高速奔跑在机器人技术上的验证价值。高速奔跑意味着系统要在极短的触地时间内完成力控制、姿态估计和落地缓冲。触地时间越短，留给控制器的反应窗口就越少，机械结构受到的冲击就越大，对状态估计精度的要求也越高。换句话说：能把高速奔跑做好，说明这套系统的硬件余量和控制算法都足够强。

所以在机器人领域，速度一直被当作“极限工况下的稳定性测试”，而不是简单的炫技指标。如果一个双足机器人能以接近人类短跑运动员的速度完成 100 米冲刺，那它的关节执行器、惯性测量单元融合算法、模型预测控制器的计算延迟、结构件的刚度重量比，都必须达到相当高的水平。

更关键的一点是：奔跑过程中的稳定性已经不再依赖传统意义上的“静态平衡”。当机器人处于腾空相时，它没有任何地面反作用力可用来修正姿态，所有落地前的调整都必须提前计算。这已经不是“怎么站稳”的问题，而是“怎么在失控的边缘反复把自己拉回来”的问题。理解这一点，才能理解后续所有技术拆解的意义。

2. 从步行到奔跑：机器人运动模式的关键变化

2.1 奔跑的判定标准：必须有腾空相

人类和机器人运动学中，奔跑和步行的核心区别不在于速度，而在于是否存在“腾空相”。

• 步行：始终至少有至少一只脚与地面接触，身体重心基本沿一条平滑曲线前进。
• 奔跑：存在双脚同时离地的阶段，也就是人体或机器人在某一瞬间完全不受地面支撑，只受重力影响。

这段腾空相的存在，会彻底改变控制逻辑。步行时，机器人可以依靠支撑多边形内的重心投影来维持稳定；奔跑时，重心投影在大多数时间里都在支撑区域之外，系统始终处于“非稳态”状态，只能依赖主动控制来维持运动轨迹。

2.2 SLIP 模型：理解奔跑动力学的最小模型

要分析奔跑这类弹跳式运动，研究中最常用的基础模型是弹簧质量模型，也就是 SLIP。它把机器人简化成一个质点和一条无质量弹簧腿，质点在重力场中运动，腿在触地后压缩、储能，在蹬伸阶段释放能量，将质心重新推离地面。

SLIP 模型能够解释奔跑中两个重要现象：

• 触地时腿部不完全刚性，而是通过弹簧效应吸收冲击，减少对关节和结构的瞬时冲击力。
• 蹬伸阶段的推力方向与地面法向存在夹角，既提供垂直方向的高度恢复，也提供水平方向的加速度。

这也就是为什么高速奔跑机器人通常会在腿部加入弹性元件，而不是把关节做成纯刚性。刚性越低，冲击吸收越好，但能量回传效率也越低；刚性越高，速度越容易上来，但落地冲击也会让执行器难以承受。设计者必须在这两者之间寻找一个平衡点。

2.3 步行与奔跑的控制策略对比

从这张表能看出，奔跑不是步行的“加速版本”，而是控制逻辑完全不同的另一种运动模式。很多团队做行走控制很稳定，一旦尝试跑起来才发现，原来行走控制里的很多假设在腾空阶段并不成立。

3. 高速奔跑系统必须具备的三大硬件能力

如果把高速奔跑机器人比作一台方程式赛车，那么算法是车手，执行器是发动机，结构是车架和轮胎。三者缺一不可。下面拆开看每部分的工程约束。

3.1 执行器的功率密度决定速度上限

机器人关节执行器需要同时满足三个矛盾的需求：扭矩大、转速高、体积小。扭矩决定机器人能否抵抗重力完成蹬伸，转速决定腿能否快速完成前后摆动，体积和重量则直接关系到机器人的整体能效。

实际项目中，常见的执行器方案有：

• 液压驱动：功率密度极高，适合暴力动态动作，但需要外接液压站，能耗高，小型化难度大。
• 行星减速电机：功率密度适中，控制简单，但高负载下的减速比会限制末端速度。
• 准直驱电机：电机直驱或近直驱，反驱性能好，能感知外力，是目前双足和四足动态控制中非常受关注的方向。
• 串联弹性执行器：在电机和关节之间加入弹性体，适合需要柔性交互的场景，但带宽会受到限制。

高速奔跑要求执行器具备低转动惯量和高峰值扭矩，让腿在极短的触地时间内完成从刹车到蹬伸的快速切换。准直驱方案之所以流行，正是因为在反驱能力上表现优秀，控制器可以通过电机的电流直接估算外部力矩，便于实现更精细的力控制。

3.2 轻量化机身与高刚度结构

同样速度下，机身重量越轻，触地冲击越小，所需扭矩也越小。高端双足机器人通常会在小腿、大腿、足底和腰关节大量使用碳纤维件和拓扑优化结构件，目的就是在保证结构刚度的前提下尽量降低末端惯量。

足底也是关键。高速奔跑时，机器人脚掌会因为冲击力产生微小的弹性形变。理想的脚底结构应该既能吸收高频冲击，又不会导致多余的振荡。这里经常出现的问题是：结构设计得过于轻，导致落地时发生可见的抖动；或为了追求强度把脚掌做得很重，又拖累了整体步频。

3.3 冷却与能源系统

一个容易被忽略的约束是散热。高速奔跑时，关节电机在短时间内的功率密度极高，如果散热不足，电机绕组温度会快速上升，导致输出扭矩下降，甚至烧毁。部分顶级机器人会引入液冷或独立的散热风道，把这个当作与电机同等重要的设计。

电池侧的挑战同样不小。奔跑阶段瞬时功率远高于平稳行走，电池必须能承受高倍率放电。如果电池管理系统不支持大电流输出，控制器一刹那就可能触发过流保护，表现为奔跑中突然断电或降功率。这个坑在实际测试中非常常见。

4. 运动控制方案：状态估计、MPC 与全身控制的配合

有了硬件基础，接下来要看控制软件如何把高速奔跑变成稳定动作。当前主流双足/四足机器人的运动控制系统通常分成三层：状态估计、模型预测控制、全身动力学控制。下面分别展开。

4.1 状态估计：先要知道自己在哪里

高速奔跑的前提，是控制器必须准确知道机器人当前的位置、速度、姿态角以及各关节角度和角速度。大多数机器人会使用以下传感器组合：

• IMU 提供三维加速度和角速度。
• 关节编码器提供各关节角度。
• 足底力传感器或关节电流估算地面反作用力。
• 视觉 / 激光雷达用于外部定位和地形感知。

所有传感器数据会进入扩展卡尔曼滤波或因子图优化，估算出当前身体的质心状态。奔跑时，由于存在腾空相，足底力传感器在腾空期间输出为零，状态估计器必须能正确处理这种“无外力”阶段，否则速度估算会出现明显漂移。

4.2 MPC 规划：面向未来的一段运动序列

MPC 的核心思想是：不只看当前一帧怎么控制，而是以一个预测窗口为单位，在满足动力学约束和摩擦锥约束的前提下，寻找一条最优的控制轨迹。每一步仅执行第一个控制量，然后重新规划，形成滚动优化。

对于一个奔跑机器人，MPC 的优化变量通常是未来 N 步内的接触力，约束条件包括：

• 底部反作用力不能为负（脚不能“拉”地）。
• 水平摩擦力不能超过摩擦系数乘以垂直力。
• 质心轨迹要在可达到范围内。

优化的目标一般是让机器人跟踪一个期望速度，同时尽量减小姿态偏差和控制能耗。下面是一个简化示意，用来模拟 MPC 中代价函数和动力学步进的思路：

# 文件路径：moc_simplified.py # 用简化质心模型展示 MPC 代价函数的基本结构 import numpy as np dt = 0.02 # 控制周期，单位秒 N = 20 # 预测步数 mass = 55.0 # 机器人总质量，单位 kg g = 9.81 def dynamics_step(state, force): p_x, p_z, v_x, v_z = state a_x = force[0] / mass a_z = force[1] / mass - g p_x_next = p_x + v_x * dt + 0.5 * a_x * dt * dt p_z_next = p_z + v_z * dt + 0.5 * a_z * dt * dt v_x_next = v_x + a_x * dt v_z_next = v_z + a_z * dt return np.array([p_x_next, p_z_next, v_x_next, v_z_next]) def evaluate_plan(state0, force_plan, v_target, w_vel=1.0, w_smooth=0.1): state = state0.copy() cost = 0.0 for k in range(N): # 这里使用预先给定的力序列来模拟一次候选解 state = dynamics_step(state, force_plan[k]) vel_err = state[2] - v_target cost += w_vel * (vel_err ** 2) if k > 0: cost += w_smooth * np.sum((force_plan[k] - force_plan[k - 1]) ** 2) return cost # 构造一个恒定向前的力序列作为候选解 force_plan = np.tile(np.array([80.0, 700.0]), (N, 1)) cost_value = evaluate_plan(np.array([0.0, 0.9, 0.0, 0.0]), force_plan, v_target=4.5) print("当前候选解代价:", cost_value)

实际工程中 MPC 通常会使用二次规划求解器，在毫秒级时间内完成优化。奔跑场景的特殊性在于，频率更高、触地时间更短，对求解器的实时性要求极其苛刻，稍一超时就会导致整段轨迹崩溃。

4.3 全身控制：把 MPC 规划的力分配到每个关节

MPC 输出的是期望的接触力或质心轨迹，真正驱动电机需要把这些“宏观力”分配到各个关节上。这是全身控制层的工作。

WBC 的输入是期望的质心加速度、足底接触力、姿态角加速度和末端位置约束，输出是各关节的期望力矩。它通常使用二次规划或任务优先级的方法，在多个任务之间做加权平衡，比如姿态保持、质心位置、脚底接触力的优先级最高，然后是上肢的辅助平衡。

在高速奔跑中，WBC 还要处理一个特殊问题：脚在触地和离地瞬间的接触状态切换。接触状态判断错误，可能导致机器人把地面视为无约束，然后在一个不合实际的关节角度上输出巨大力矩，造成结构损坏。

4.4 事件驱动与相位切换

奔跑按事件拆解为支撑相、前摆相、腾空相、落地缓冲相。表面上看这是一个周期序列，实际上每个相位的切换由物理事件触发，比如“脚底力传感器检测到离开地面”“关节角度达到预期着地角”。控制器必须能对这些事件快速响应，而不是单纯依赖固定的时间插值。

事件驱动也是高速奔跑和倒立摆平衡最大的区别之一。倒立摆平衡本质上是一个连续调节问题，奔跑则更像一个带冲击的混合动态系统，控制难度不在一个量级。

5. 可落地的测试流程：从跑台到赛道

很多开发者会把注意力全部放在仿真里跳来跑去的模型，却忽视了真实机器人的测试流程设计。高速奔跑测试不仅要验证控制算法，更要验证机械结构和安全保护。下面是一套相对通用的实测流程。

5.1 跑台测试：先用束缚系统跑起来

在开放场地做第一次高速奔跑测试的风险很高，一旦落地姿态失控，机器人可能直接损伤关节或外壳。更稳妥的做法是在高速跑台或配有安全绳的跑台上测试。

跑台的好处是可以把机器人的前进速度约束在指定速度，不需要担心机器人追不上标定线。安全绳的作用是防止跌倒时直接撞击地面。跑台测试时要注意记录一组基准数据，包括跑步速度、步频、实际触地时间、足底力峰值、关节扭矩曲线。

建议至少跑满 3 组，每组 30 秒以上，观察数据是否有明显漂移和偶发异常。如果机器人能在跑台上稳定跑完设定时间，再逐步进入开阔场地。

5.2 场地测试：用外部感知记录真实速度

跑台测试通过后，进场地的第一步不是直接全速冲刺，而是先跑 3 到 5 次 10 米短程，人工观察姿态是否稳定。场地测试需要同步采集两类数据：

• 机器人内部的 IMU、关节编码器、控制日志。
• 外部的高速相机或运动捕捉系统，用于计算真实位移和速度。

外部数据更适合作为“标准答案”，因为机器人内部传感器在高速奔跑时可能出现打滑或漂移。建议在场地两侧布置多个标定点，通过标记点识别或者视频后处理计算目标速度。

5.3 可靠性测试：不能只看一次最好成绩

新闻里展示的往往是“最高速度”，但工程上更重视“重复多少次还能稳定完成”。一次完美的奔跑可能是偶然，三次连续奔跑都稳定，才说明系统的鲁棒性够强。

一组建议的评估指标：

• 平均速度：多组跑动结果的中位数或平均值，避免被单次误差带偏。
• 步频：每分钟步数，反映执行器带宽和控制器频率。
• 步幅：每步前进距离，反映腿长和蹬伸效率。
• 腾空比：腾空时间占一个完整步态周期的比例，越接近奔跑，腾空相越明显。
• 落地冲击峰值：足底力在触地瞬间的峰值，过大会导致结构安全隐患。

6. 用 Python 快速分析一次奔跑记录示例

看完测试流程，这里给出一个最小可运行的数据分析示例，帮你把“奔跑数据”转换成“速度指标”。假设你已经通过运动捕捉或视觉定位获得了机器人腰部标记点的时间序列，文件格式是 CSV，包含时间、水平位置和垂直位置三列。

# 文件路径：run_speed_analysis.py import pandas as pd import numpy as np df = pd.read_csv("run_data.csv") # 假设字段: time, x_body, z_body # x_body 表示沿跑道方向的位置，单位米 # z_body 表示身体高度，单位米 df = df.sort_values("time").reset_index(drop=True) dt = df["time"].diff().fillna(0).to_numpy() dx = df["x_body"].diff().fillna(0).to_numpy() # 瞬时速度：用 5 帧平滑窗降低噪声 df["vx_raw"] = dx / np.where(dt > 0, dt, np.nan) window = 5 df["vx"] = df["vx_raw"].rolling(window, center=True).mean() # 平均速度 v_avg = (df["x_body"].iloc[-1] - df["x_body"].iloc[0]) / \ (df["time"].iloc[-1] - df["time"].iloc[0]) # 步频估算：计算身体高度 z_body 的峰值个数，一个峰值代表一次蹬伸 from scipy.signal import find_peaks peaks, _ = find_peaks(df["z_body"], distance=10) step_count = len(peaks) duration = df["time"].iloc[-1] - df["time"].iloc[0] cadence = step_count / duration * 60 print(f"平均速度: {v_avg:.2f} m/s") print(f"峰值次数: {step_count} 次") print(f"步频: {cadence:.1f} 步/分钟") print(f"平均步幅: {v_avg / max(step_count / duration, 1e-6):.2f} m/步")

运行方式：

python run_speed_analysis.py

如果数据正常，脚本会输出平均速度、峰值次数、步频和平均步幅。如果输出为空或出现 NaN，优先检查 CSV 中是否存在空行、时间戳是否严格递增、z_body 是否包含明显的传感器跳变。

一个需要特别提醒的细节：身体高度峰值的检测并不等于脚离地的判定。如果机器人身体在奔跑中因为前倾而持续下降，只用高度峰值判断步频可能不准，更严谨的做法是结合足底力传感器数据，把“足底力小于某个阈值”作为腾空相的判据。

7. 常见问题与排查思路

高速奔跑测试的失败原因通常并不神秘，下面整理一份高频问题清单，适合开始测试前对照检查。

实际排查时，一定要把日志保存成可回放的格式，包括时间、状态估计、MPC 输出、WBC 输出和关节实测力矩。没有日志，高速奔跑问题几乎无法定位，因为一次失败往往只发生在几百毫秒内。

8. 工程建议：把“破纪录”变成稳定可复现的能力

对大多数团队来说，高速奔跑的真正价值不是上头条，而是验证整套系统的能力边界。以下几条工程建议都来自常见的实践教训，建议直接纳入你的开发流程。

8.1 从“单步能力”开始，而不是直接追求连续速度

先验证机器人能否完成一次完整的单步奔跑：准确的落地、压缩、蹬伸、腾空。单独把这一帧调稳，再连续重复，比一上来就试连续冲刺更容易定位问题。很多团队热衷于在仿真中把速度调得很高，一旦上真机就发现落地冲击远超预期。

8.2 仿真和实机之间，必须保留同一个动力学接口

仿真里能跑通不代表实机能跑通，但仿真和实机之间至少要做到动力学计算接口一致。控制器的输入输出结构应该完全一致：输入是同样的状态量，输出是同样的关节力矩。这样在仿真中排除逻辑错误，到实机上只需要处理硬件差异和模型误差。

8.3 安全边界要设计成“低于物理极限”

跑得快并不难，难的是每次都安全。建议把控制器的力矩上限设置为电机峰值扭矩的 80%，把速度设定为设计极限速度的 70%。前期多留安全裕度，后续逐步提高，比一上来就压满物理极限更可持续。

8.4 数据记录必须加入跌倒保护

测试场地应预设两种情况：主动断电和主动制动。如果机器人跑出安全区域，或者姿态角超过安全阈值，控制程序应当触发原地制动或软断电。这个逻辑必须写在实时控制循环里，而不是依赖遥控器人工干预，因为人工反应时间远不够用。

8.5 团队协作时要做好版本管理

运动控制开发中，控制参数和模型文件经常被反复调整。建议把机器人型号、控制器代码、MPC 参数、标定文件统一纳入版本管理，并把每次测试的日志和参数版本关联起来。这样复盘测试数据时，才能快速定位“上一次能跑，这一次不能跑”的差异在哪里。

9. 总结与后续学习方向

机器人在北京高速奔跑这则消息，放到工程语境里看，本质上是一次对人形机器人核心系统的集中验证。奔跑比行走更大的意义在于，它迫使工程师在极短的控制周期内同时处理好状态估计、动力学预测、执行器响应和结构冲击。任何一环拖后腿，速度就上不去，或者姿态就会失控。

如果你对机器人运动控制感兴趣，下一步可以从两个方向入手：一是把本文提到的 SLIP 模型和 MPC 在仿真环境中跑通，理解奔跑的基本动力学；二是找一个开源的四足或双足仿真项目，尝试修改它的步频、目标速度和着地角，观察数据变化。等仿真中的控制逻辑足够稳定后，再考虑移植到实体机器人上测试。

“跑得快”这件事，最终一定会走向“跑得稳、跑得久、跑得可控”。这也正是机器人技术从实验室走向真实场景的关键一步。