在北京世界人形机器人运动会上除了那些走得稳、跑得快的“优等生”机器人之外一个“醉酒机器人”的片段反而在网络上引起了不少讨论。从现场流传的短视频可以看到它的步态摇摇晃晃脚底像踩在棉花上甚至需要工作人员在旁边随时候命防止它摔出赛道。很多读者看到这类画面第一反应是“这机器人是不是坏了”或者“它是不是被远程操作失误了”。实际上在机器人运动控制领域这种“醉酒”一般的表现并不是纯粹的故障它背后反映的是人形机器人平衡控制中一个极其核心的问题双足步态稳定。对于从事机器人开发、嵌入式控制或者刚入行做算法仿真的工程师来说这个现象其实是一个非常好的研究切片。本文就从“醉酒机器人”这个现象出发拆解以下内容人形机器人为什么会“醉酒”是硬件问题还是算法问题。双足平衡控制的核心原理包括零力矩点ZMP、质心CoM、步态规划等概念。一个人形机器人步态控制的基础 Python 仿真示例。从工程角度总结让机器人“站得稳、走得直”的改善方向和排查清单。无论你是机器人爱好者还是正在入门 ROS、运动控制的开发者这篇文章都会提供一套可以复用、可以继续深入的控制思路。1. 背景人形机器人运动会为什么需要关注“步态稳定”1.1 运动会里的两只队伍稳定 vs 失衡先来还原一下这个现象产生的背景。北京世界人形机器人运动会是一次集中展示双足机器人运动能力的场合赛项包括短跑、长跑、足球、障碍等。参加这类比赛的人形机器人通常采用双足结构高度在 1.2 米到 1.8 米之间重量从几十公斤到上百公斤不等。当机器人处于理想工况时它能完成规定的起步、加速、转向和急停动作。但实际落地时真正考验机器人水平的不是“能不能走”而是“在扰动面前能不能不摔倒”。网上的“醉酒机器人”恰恰暴露了这一点它并非不能迈步而是每一步都处于随时可能失控的边缘状态。1.2 “醉酒”现象的本质是什么所谓“醉酒”通常表现为以下几类运动异常步态频率不稳定忽快忽慢。踝关节和髋关节呈现过大的摆动角度。躯干出现明显的前倾或后仰。双脚触地时间不对称甚至出现拖脚、蹭地。需要外部扶持才能维持稳定。这些现象在人形机器人控制中本质上是实时反馈系统对期望轨迹的跟踪能力不足或者规划轨迹本身已经超出了机器人实际能稳定执行的物理范围。换句话说不是机器人“醉了”而是它的控制器在应对自身动力学和外部环境时没能维持住平衡条件。从动态系统角度看双足步行本质上是一个反复“失去平衡”又“恢复平衡”的过程。单脚支撑期里机器人是典型的倒立摆系统如果地面反作用力GRF的作用点不在脚掌支撑多边形内系统就会翻倒。这个“作用点”就是我们常说的 ZMPZero Moment Point零力矩点。2. 核心技术概念拆解要真正理解“醉酒机器人”为什么出现需要先建立三个基础概念质心、支撑多边形、零力矩点。2.1 质心CoM人形机器人的质心是全身质量分布的加权中心常简写为 CoMCenter of Mass。控制双足平衡最终目标就是让质心的水平投影保持在一个可控范围内。单脚站立时机器人质心的水平位置如果投影在脚掌范围内系统处于静态稳定状态一旦投影超出脚尖或脚跟重力力矩就会使机器人绕踝关节翻转。在动态步行中质心还会因加速产生惯性力因此单纯看静态投影并不足够需要引入 ZMP 的概念。2.2 支撑多边形支撑多边形是由所有触地脚掌或手、拐杖构成的凸多边形。比如双脚站立时支撑多边形通常是两只脚掌加中间区域的凸包。ZMP 一旦离开支撑多边形机器人就会失去平衡。这是双足稳定问题里一条最核心的边界条件。机器人的控制器实际上一直在计算当前状态下的 ZMP 在哪下一步能否让 ZMP 回到一个安全位置2.3 零力矩点ZMP零力矩点ZMP是地面反作用力合力的作用点。它与陀螺仪测得的重力矩、惯性力相关在实际系统中可以通过六维力/力矩传感器或者状态估计器近似推导。可以这样直观理解人站立时如果身体不动ZMP 约等于质心投影点如果身体前倾ZMP 会向脚尖方向移动前倾过度ZMP 移出脚掌人就摔出去了。在简化控制模型中我们可以把双足机器人近似为线性倒立摆LIPM然后通过调节质心加速度来控制 ZMP 位置ZMP_x CoM_x - (CoM_z / g) * CoM_ax其中CoM_x是质心在 x 方向的水平位置CoM_z是质心高度CoM_ax是质心水平加速度g是重力加速度这个公式说明了一个关键点当质心加速时ZMP 会反向移动。当机器人要加速前进时必须先向后蹬地让 ZMP 先落在脚掌后部然后质心向前加速。2.4 为什么会“酒后失态”回到比赛现场如果一个机器人的控制器出现了以下任一问题都会表现出醉酒式的步态第一状态估计不准。陀螺仪和加速度计的数据存在漂移或者滤波算法延迟太大机器人对自身倾斜角度的感知滞后控制指令就始终慢半拍。第二执行器响应延迟。髋关节或踝关节的电机扭矩不足、减速器间隙过大导致控制指令发出后关节无法立即响应。这一延迟在高速行走时会被放大。第三步态规划过于激进。规划器给出了大步长、高速度的轨迹但实际电机无法满足相应的加速度需求ZMP 自然就不在安全区域内。第四地面工况变化。比赛场地可能有微小坡度或者材质不均摩擦力变化会让原本设计的步态失效。所以网络热词里“醉酒机器人”其实不是一种故障类型而是上述若干控制问题的综合外在表现。3. 步态控制的基本思路要解决“醉酒”问题先得知道正确的控制管道是什么。一个典型的双足步行控制框架可以拆成三层规划层 → 控制层 → 执行层规划层负责生成目标步态轨迹控制层根据当前状态修正轨迹执行层把修正后的角度发给关节电机。3.1 规划层步态周期与脚掌轨迹步态规划的基本输入是步长、步频、支撑周期、双脚切换时序。输出是每个控制周期内质心的水平位置、脚掌的摆高曲线和踝关节角度。最简单的规划方式是先预设 ZMP 轨迹再反解质心轨迹。由于人形机器人步行是一个周期性过程通常用线性倒立摆模型求出解析解。3.2 控制层位置环 姿态环实际中光有规划轨迹还不够必须加入反馈控制。最常用的是两层反馈踝关节策略当机器人躯干出现微小倾斜时通过踝关节力矩调整 ZMP 位置把倾斜修正回来。适合小扰动。髋关节策略当扰动较大单纯依赖踝关节会触发脚掌离地此时通过髋关节摆动质心位置把 ZMP 拉回脚掌内侧。两个策略可以组合使用分别应对中低频和高频扰动。3.3 执行层关节位置/力矩伺服控制层计算出期望关节角后执行层还要考虑电机速度极限和力矩极限。执行时如果直接给位置指令可能因为加速度过大激发机械振动更好的做法是采用力矩控制模式由上层计算期望力矩。这也是很多比赛机器人“醉酒”的原因执行层只做了位置跟踪却没有考虑力矩饱和边界。一旦电机达到堵转区域关节角度就滞后整个姿态反馈就乱了。4. 完整实战用 Python 仿真一次“醉酒式”失衡为了让大家直观地看到「ZMP 超出支撑脚范围 → 机器人失衡」的过程我写了一个基于线性倒立摆模型的简化仿真。这个仿真只保留质心和 ZMP 的核心关系适合用来理解平衡控制的最小闭环。4.1 项目结构代码可以放在一个独立目录下文件结构如下robot_balance_demo/ ├── balance_sim.py └── requirements.txtrequirements.txt 内容numpy matplotlib4.2 核心思路我们把人形机器人的单足支撑过程简化为一个二维平面上的线性倒立摆机器人的质心高度恒定。踝关节输出一个水平加速度从而改变质心速度。每次仿真周期里通过 ZMP 公式计算 ZMP 位置。如果 ZMP 落在脚掌边界之外判定失衡。控制策略用最简单的 P 控制器根据质心位置误差调整水平加速度。也就是让质心位置尽量跟踪一个目标轨迹同时保持 ZMP 不要出边界。4.3 完整代码# 文件路径robot_balance_demo/balance_sim.py import numpy as np import matplotlib.pyplot as plt # 物理参数 G 9.8 # 重力加速度 COM_HEIGHT 0.8 # 质心高度单位 m FOOT_LENGTH 0.2 # 单脚长度单位 m # 控制参数 CTRL_GAIN 4.0 # P 控制增益 DT 0.01 # 仿真步长单位 s SIM_TIME 3.0 # 总仿真时间单位 s # 初始状态 # 质心位置初始设置为 0.03m相当于初始倾斜 x 0.03 v 0.0 foot_center 0.0 # 脚掌中心位置 def compute_zmp(pos_x, acc_x): 根据线性倒立摆公式计算 ZMP return pos_x - (COM_HEIGHT / G) * acc_x def p_control(pos_x, target_x): P 控制器返回水平加速度指令 return CTRL_GAIN * (target_x - pos_x) def run_simulation(): time_steps int(SIM_TIME / DT) times [] positions [] velocities [] zmps [] balance_flag True # 目标质心位置始终保持在脚掌中心 target_x 0.0 foot_bound FOOT_LENGTH / 2 for i in range(time_steps): t i * DT acc p_control(x, target_x) zmp compute_zmp(x, acc) # 判断是否失衡 if abs(zmp - foot_center) foot_bound: balance_flag False # 失衡后我们仍然记录数据但停止继续控制让状态自由演化 acc 0.0 # 状态更新半隐式欧拉积分 v acc * DT x v * DT times.append(t) positions.append(x) velocities.append(v) zmps.append(zmp) # 如果完全失衡提前终止 if not balance_flag and abs(x - foot_center) 0.3: break return times, positions, velocities, zmps, balance_flag def plot_results(times, positions, zmps, balance_flag): plt.figure(figsize(10, 5)) plt.subplot(2, 1, 1) plt.plot(times, positions, labelCoM Position (m)) plt.axhline(y0.1, colorr, linestyle--, labelFoot Edge) plt.axhline(y-0.1, colorr, linestyle--) plt.ylabel(CoM Position (m)) plt.legend() plt.subplot(2, 1, 2) plt.plot(times, zmps, labelZMP Position (m), colororange) plt.axhline(y0.1, colorr, linestyle--, labelFoot Boundary) plt.axhline(y-0.1, colorr, linestyle--) plt.ylabel(ZMP Position (m)) plt.xlabel(Time (s)) plt.legend() title fRobot Balance Simulation | Balance Flag: {balance_flag} plt.suptitle(title) plt.tight_layout() plt.show() if __name__ __main__: times, positions, velocities, zmps, balance_flag run_simulation() plot_results(times, positions, zmps, balance_flag)4.4 运行与观察在命令行执行cd robot_balance_demo python balance_sim.py运行后你会看到两张曲线图第一张图是质心位置随时间的变化。初始时刻质心在 0.03m控制器会尝试把它拉回 0。第二张图是 ZMP 位置。如果 ZMP 超出 ±0.1m 的脚掌边界平衡标志位就会变成False。在默认参数下由于初始偏移量较小P 控制器能够把机器人拉回稳定区域平衡标志为True。这说明一个基础的位置反馈已经能够处理小幅扰动。4.5 复现“醉酒式”失衡为了让这个仿真更贴近“醉酒机器人”我们可以做两个修改修改一增大初始偏移量把x 0.03改为x 0.15意味着机器人一开始就有一个很大的倾斜角。运行后会看到 ZMP 很快超出脚掌边界平衡标志变为False质心位置逐渐发散。这说明控制增益不足以应对大幅偏移。修改二增大控制增益但限制加速度把CTRL_GAIN 4.0改成CTRL_GAIN 20.0模仿“反馈很强但执行器响应有限”的场景。你可以再加一个加速度限幅MAX_ACC 1.5 # 最大允许加速度 def p_control(pos_x, target_x): acc CTRL_GAIN * (target_x - pos_x) acc np.clip(acc, -MAX_ACC, MAX_ACC) return acc加上限幅后如果初始偏移还是取较大值控制器实际输出的加速度达不到理想值ZMP 输出会被持续压在一个危险位置附近仿真表现就会出现“抖振”和“间歇性失衡”这就是醉酒步态的一种简化形式。通过这个仿真可以直观验证一个结论只提高反馈增益并不能解决失衡真正的瓶颈在于执行器的加速度饱和边界。这也是我们为什么总强调控制算法必须和硬件执行力共同设计。5. 现实中如何让机器人“醒酒”工程改善方向如果我们在真实机器人上遇到了类似“醉酒”的问题排查顺序和改善方向通常是下面的路径。5.1 检查状态估计先确保“感知准确”姿态传感器数据必须经过滤波和融合。实践中最常见的问题有两个陀螺仪数据没有去除零漂。加速度计噪声过大导致滤波后的角度延迟严重。建议先用离线数据回放画出原始姿态角和滤波后姿态角的对比确认延迟是否在可接受范围内。通常控制频率在 500Hz-1kHz 时姿态估计延迟应控制在 10ms 以内。5.2 调整步态参数降低动态复杂度在控制器没变的前提下把步长调小、步频调低、质心高度略微抬高都能明显减轻失衡。对于比赛或演示环境优先让机器人“走稳”再追求步速。另外要注意双脚支撑期的设置增加双脚同时触地的时间比例可以显著提高抗扰动能力但代价是行走速度下降。5.3 引入踝关节策略与髋关节策略的分工实际控制中不能只有一个位置 P 控制器建议加入 PD 控制甚至更高级的控制策略踝关节负责高频、小幅姿态修正。髋关节负责低频、大幅质心调整。必要时加入上身配重块的反向摆动用于吸收冲击。在代码层面可以把姿态误差分为比例部分和微分部分并在踝关节期望力矩中加入基于 ZMP 误差的修正项。5.4 提高执行层力矩响应除了算法硬件的力矩饱和曲线也要纳入规划。比如在步态规划阶段就通过逆动力学计算每个关节的期望力矩并与电机最大输出力矩比较自动降低步态参数。这样可以避免实际运行时出现“规划得很好但执行不了”的尴尬。5.5 合理选用计算芯片人形机器人运动控制对计算实时性的要求很高。步态周期通常在 0.8s-1.5s但控制周期需要达到毫秒级。单个周期内要完成状态估计、轨迹规划、逆运动学计算和力矩分配普通 MCU 往往吃不消。这也是现场很多机器人采用高性能嵌入式主板或者搭配专门运动控制芯片的原因。例如网络热词里提到的“全志科技 人形机器人芯片”方向本质上就是针对这类边缘计算需求把多核 CPU、GPU/NPU 单元和丰富的外设接口集成在一起让机器人本体能够低延迟地运行视觉、状态估计与控制算法。需要说明的是具体选型要看运动控制算法是跑在传统 MCU 上还是 Linux 系统上一般来说带有硬件浮点单元和多核处理器的方案会更适合跑复杂控制。6. 常见问题与排查清单下面整理一张实际问题排查表方便你在调试机器人时对照使用。问题现象常见原因解决思路机器人站立时轻微左右摇晃姿态估计噪声大控制增益过低调高踝关节 PD 增益增加滤波器带宽起步瞬间往后仰质心初始位置偏后步态规划起步阶段加速过快调整起步时的 ZMP 轨迹增加预备动作行走中突然“跪倒”踝关节扭矩不足或者速度环饱和检查电机最大扭矩降低步频或步长转弯时重心不稳转向步态规划的角速度过快增加转弯步数降低角速度遇到轻微推力就倒髋关节补偿力度不足ZMP 被推出脚掌边界引入髋关节策略提高质心调节速度机器人有“醉酒”般的抖动执行周期不稳定或控制频率过低检查控制线程实时性提高关节指令频率排查时建议按固定顺序走一遍先看传感器原始数据是否能正常采集。再看机器人在静态站立时是否稳定。然后测试原地踏步。再进行直行步态测试。最后做转弯和受扰测试。从简单到复杂逐步验证能快速定位到底哪一层出了问题。7. 最佳实践与工程建议结合近年人形机器人比赛和实际项目经验下面几条建议属于通用性较强、值得反复强调的内容。第一控制框架一开始就要预留接口。很多团队最开始只写了简单的关节位置跟踪后面想加 ZMP 修正就非常痛苦。建议规划层、控制层、执行层之间使用标准格式的数据流比如把期望姿态、期望角速度、期望力矩统一为接口方便后续替换算法。第二所有参数都要支持在线调试。比赛现场不可能频繁重新编译固件。步长、步频、PD 增益、质心高度这些关键参数应该做成可以通过上位机实时修改的配置项。推荐保留一个简单的调试面板或者接入 ROS 动态参数配置工具。第三安全问题必须优先设计。机器人一旦失控几百牛顿的力矩对人体是很危险的。现场实验时要设置急停开关和软限位。运动控制代码里应该有独立的看门狗任务一旦发现控制线程失步或者姿态角超限立即强制进入安全停靠状态。第四记录数据和回放数据同样重要。至少把关节角、关节速度、姿态角、ZMP估算值、参考轨迹以固定周期记录到 SD 卡或本地文件。失衡往往发生在毫秒级的时间窗口里如果没有数据回放排错就像盲人摸象。第五仿真不能代替真机验证。很多团队在仿真环境里跑得很好一到真实机器人就翻车。因为仿真通常忽略了电机延时、摩擦、齿轮间隙和地面接触变化。除非使用包含完整摩擦模型和电机动力学的高保真仿真平台否则仿真结果只能作为一种参考。第六要重视整机重量分布。质心高度和重量分布直接决定了平衡控制的难度。如果条件允许把较重的电池和计算单元尽量放在髋关节附近降低质心高度。这不仅能提升稳定性也能降低对踝关节力矩的要求。8. 动手玩一玩从仿真到真机如果你是一名初学者看完本文后不必马上去买一台昂贵的双足机器人。可以先做三件事把上面的 Python 仿真代码跑起来手动调整初始偏移和加速度限幅参数观察 ZMP 出边界的过程。用树莓派或者任何一块 Linux 开发板接一个 MPU6050 姿态传感器写一个简单的姿态估计程序体会“感知”与“控制”之间的延迟问题。找一个低成本的两轮自平衡小车项目把 PD 控制跑通。两轮车虽然结构简单但已经包含倒立摆控制和传感器反馈的核心问题。从二维到三维从固定底盘到双足控制理论是相通的。你在两轮小车上积累的对滤波、控制增益、稳定性边界的理解完全可以迁移到人形机器人上。网络热词里提到“人形机器人”和“全志科技 人形机器人芯片”等相关方向也说明一个问题人形机器人正从实验室走向比赛场和行业应用底层控制依然是决定产品能否落地的关键瓶颈之一。芯片算力提升、电机性能改善都能提供更好的执行基础但最终稳定行走还是要靠扎实的运动控制算法。希望这篇围绕“醉酒机器人”展开的文章能帮你建立关于双足步态稳定的完整思维框架。下次再看到某个机器人在视频里走得不稳你能一眼看出它背后的控制问题到底是什么而不是简单地用“坏了”来概括。 从“醉酒机器人”看双足步态稳定：ZMP与平衡控制原理
在北京世界人形机器人运动会上除了那些走得稳、跑得快的“优等生”机器人之外一个“醉酒机器人”的片段反而在网络上引起了不少讨论。从现场流传的短视频可以看到它的步态摇摇晃晃脚底像踩在棉花上甚至需要工作人员在旁边随时候命防止它摔出赛道。很多读者看到这类画面第一反应是“这机器人是不是坏了”或者“它是不是被远程操作失误了”。实际上在机器人运动控制领域这种“醉酒”一般的表现并不是纯粹的故障它背后反映的是人形机器人平衡控制中一个极其核心的问题双足步态稳定。对于从事机器人开发、嵌入式控制或者刚入行做算法仿真的工程师来说这个现象其实是一个非常好的研究切片。本文就从“醉酒机器人”这个现象出发拆解以下内容人形机器人为什么会“醉酒”是硬件问题还是算法问题。双足平衡控制的核心原理包括零力矩点ZMP、质心CoM、步态规划等概念。一个人形机器人步态控制的基础 Python 仿真示例。从工程角度总结让机器人“站得稳、走得直”的改善方向和排查清单。无论你是机器人爱好者还是正在入门 ROS、运动控制的开发者这篇文章都会提供一套可以复用、可以继续深入的控制思路。1. 背景人形机器人运动会为什么需要关注“步态稳定”1.1 运动会里的两只队伍稳定 vs 失衡先来还原一下这个现象产生的背景。北京世界人形机器人运动会是一次集中展示双足机器人运动能力的场合赛项包括短跑、长跑、足球、障碍等。参加这类比赛的人形机器人通常采用双足结构高度在 1.2 米到 1.8 米之间重量从几十公斤到上百公斤不等。当机器人处于理想工况时它能完成规定的起步、加速、转向和急停动作。但实际落地时真正考验机器人水平的不是“能不能走”而是“在扰动面前能不能不摔倒”。网上的“醉酒机器人”恰恰暴露了这一点它并非不能迈步而是每一步都处于随时可能失控的边缘状态。1.2 “醉酒”现象的本质是什么所谓“醉酒”通常表现为以下几类运动异常步态频率不稳定忽快忽慢。踝关节和髋关节呈现过大的摆动角度。躯干出现明显的前倾或后仰。双脚触地时间不对称甚至出现拖脚、蹭地。需要外部扶持才能维持稳定。这些现象在人形机器人控制中本质上是实时反馈系统对期望轨迹的跟踪能力不足或者规划轨迹本身已经超出了机器人实际能稳定执行的物理范围。换句话说不是机器人“醉了”而是它的控制器在应对自身动力学和外部环境时没能维持住平衡条件。从动态系统角度看双足步行本质上是一个反复“失去平衡”又“恢复平衡”的过程。单脚支撑期里机器人是典型的倒立摆系统如果地面反作用力GRF的作用点不在脚掌支撑多边形内系统就会翻倒。这个“作用点”就是我们常说的 ZMPZero Moment Point零力矩点。2. 核心技术概念拆解要真正理解“醉酒机器人”为什么出现需要先建立三个基础概念质心、支撑多边形、零力矩点。2.1 质心CoM人形机器人的质心是全身质量分布的加权中心常简写为 CoMCenter of Mass。控制双足平衡最终目标就是让质心的水平投影保持在一个可控范围内。单脚站立时机器人质心的水平位置如果投影在脚掌范围内系统处于静态稳定状态一旦投影超出脚尖或脚跟重力力矩就会使机器人绕踝关节翻转。在动态步行中质心还会因加速产生惯性力因此单纯看静态投影并不足够需要引入 ZMP 的概念。2.2 支撑多边形支撑多边形是由所有触地脚掌或手、拐杖构成的凸多边形。比如双脚站立时支撑多边形通常是两只脚掌加中间区域的凸包。ZMP 一旦离开支撑多边形机器人就会失去平衡。这是双足稳定问题里一条最核心的边界条件。机器人的控制器实际上一直在计算当前状态下的 ZMP 在哪下一步能否让 ZMP 回到一个安全位置2.3 零力矩点ZMP零力矩点ZMP是地面反作用力合力的作用点。它与陀螺仪测得的重力矩、惯性力相关在实际系统中可以通过六维力/力矩传感器或者状态估计器近似推导。可以这样直观理解人站立时如果身体不动ZMP 约等于质心投影点如果身体前倾ZMP 会向脚尖方向移动前倾过度ZMP 移出脚掌人就摔出去了。在简化控制模型中我们可以把双足机器人近似为线性倒立摆LIPM然后通过调节质心加速度来控制 ZMP 位置ZMP_x CoM_x - (CoM_z / g) * CoM_ax其中CoM_x是质心在 x 方向的水平位置CoM_z是质心高度CoM_ax是质心水平加速度g是重力加速度这个公式说明了一个关键点当质心加速时ZMP 会反向移动。当机器人要加速前进时必须先向后蹬地让 ZMP 先落在脚掌后部然后质心向前加速。2.4 为什么会“酒后失态”回到比赛现场如果一个机器人的控制器出现了以下任一问题都会表现出醉酒式的步态第一状态估计不准。陀螺仪和加速度计的数据存在漂移或者滤波算法延迟太大机器人对自身倾斜角度的感知滞后控制指令就始终慢半拍。第二执行器响应延迟。髋关节或踝关节的电机扭矩不足、减速器间隙过大导致控制指令发出后关节无法立即响应。这一延迟在高速行走时会被放大。第三步态规划过于激进。规划器给出了大步长、高速度的轨迹但实际电机无法满足相应的加速度需求ZMP 自然就不在安全区域内。第四地面工况变化。比赛场地可能有微小坡度或者材质不均摩擦力变化会让原本设计的步态失效。所以网络热词里“醉酒机器人”其实不是一种故障类型而是上述若干控制问题的综合外在表现。3. 步态控制的基本思路要解决“醉酒”问题先得知道正确的控制管道是什么。一个典型的双足步行控制框架可以拆成三层规划层 → 控制层 → 执行层规划层负责生成目标步态轨迹控制层根据当前状态修正轨迹执行层把修正后的角度发给关节电机。3.1 规划层步态周期与脚掌轨迹步态规划的基本输入是步长、步频、支撑周期、双脚切换时序。输出是每个控制周期内质心的水平位置、脚掌的摆高曲线和踝关节角度。最简单的规划方式是先预设 ZMP 轨迹再反解质心轨迹。由于人形机器人步行是一个周期性过程通常用线性倒立摆模型求出解析解。3.2 控制层位置环 姿态环实际中光有规划轨迹还不够必须加入反馈控制。最常用的是两层反馈踝关节策略当机器人躯干出现微小倾斜时通过踝关节力矩调整 ZMP 位置把倾斜修正回来。适合小扰动。髋关节策略当扰动较大单纯依赖踝关节会触发脚掌离地此时通过髋关节摆动质心位置把 ZMP 拉回脚掌内侧。两个策略可以组合使用分别应对中低频和高频扰动。3.3 执行层关节位置/力矩伺服控制层计算出期望关节角后执行层还要考虑电机速度极限和力矩极限。执行时如果直接给位置指令可能因为加速度过大激发机械振动更好的做法是采用力矩控制模式由上层计算期望力矩。这也是很多比赛机器人“醉酒”的原因执行层只做了位置跟踪却没有考虑力矩饱和边界。一旦电机达到堵转区域关节角度就滞后整个姿态反馈就乱了。4. 完整实战用 Python 仿真一次“醉酒式”失衡为了让大家直观地看到「ZMP 超出支撑脚范围 → 机器人失衡」的过程我写了一个基于线性倒立摆模型的简化仿真。这个仿真只保留质心和 ZMP 的核心关系适合用来理解平衡控制的最小闭环。4.1 项目结构代码可以放在一个独立目录下文件结构如下robot_balance_demo/ ├── balance_sim.py └── requirements.txtrequirements.txt 内容numpy matplotlib4.2 核心思路我们把人形机器人的单足支撑过程简化为一个二维平面上的线性倒立摆机器人的质心高度恒定。踝关节输出一个水平加速度从而改变质心速度。每次仿真周期里通过 ZMP 公式计算 ZMP 位置。如果 ZMP 落在脚掌边界之外判定失衡。控制策略用最简单的 P 控制器根据质心位置误差调整水平加速度。也就是让质心位置尽量跟踪一个目标轨迹同时保持 ZMP 不要出边界。4.3 完整代码# 文件路径robot_balance_demo/balance_sim.py import numpy as np import matplotlib.pyplot as plt # 物理参数 G 9.8 # 重力加速度 COM_HEIGHT 0.8 # 质心高度单位 m FOOT_LENGTH 0.2 # 单脚长度单位 m # 控制参数 CTRL_GAIN 4.0 # P 控制增益 DT 0.01 # 仿真步长单位 s SIM_TIME 3.0 # 总仿真时间单位 s # 初始状态 # 质心位置初始设置为 0.03m相当于初始倾斜 x 0.03 v 0.0 foot_center 0.0 # 脚掌中心位置 def compute_zmp(pos_x, acc_x): 根据线性倒立摆公式计算 ZMP return pos_x - (COM_HEIGHT / G) * acc_x def p_control(pos_x, target_x): P 控制器返回水平加速度指令 return CTRL_GAIN * (target_x - pos_x) def run_simulation(): time_steps int(SIM_TIME / DT) times [] positions [] velocities [] zmps [] balance_flag True # 目标质心位置始终保持在脚掌中心 target_x 0.0 foot_bound FOOT_LENGTH / 2 for i in range(time_steps): t i * DT acc p_control(x, target_x) zmp compute_zmp(x, acc) # 判断是否失衡 if abs(zmp - foot_center) foot_bound: balance_flag False # 失衡后我们仍然记录数据但停止继续控制让状态自由演化 acc 0.0 # 状态更新半隐式欧拉积分 v acc * DT x v * DT times.append(t) positions.append(x) velocities.append(v) zmps.append(zmp) # 如果完全失衡提前终止 if not balance_flag and abs(x - foot_center) 0.3: break return times, positions, velocities, zmps, balance_flag def plot_results(times, positions, zmps, balance_flag): plt.figure(figsize(10, 5)) plt.subplot(2, 1, 1) plt.plot(times, positions, labelCoM Position (m)) plt.axhline(y0.1, colorr, linestyle--, labelFoot Edge) plt.axhline(y-0.1, colorr, linestyle--) plt.ylabel(CoM Position (m)) plt.legend() plt.subplot(2, 1, 2) plt.plot(times, zmps, labelZMP Position (m), colororange) plt.axhline(y0.1, colorr, linestyle--, labelFoot Boundary) plt.axhline(y-0.1, colorr, linestyle--) plt.ylabel(ZMP Position (m)) plt.xlabel(Time (s)) plt.legend() title fRobot Balance Simulation | Balance Flag: {balance_flag} plt.suptitle(title) plt.tight_layout() plt.show() if __name__ __main__: times, positions, velocities, zmps, balance_flag run_simulation() plot_results(times, positions, zmps, balance_flag)4.4 运行与观察在命令行执行cd robot_balance_demo python balance_sim.py运行后你会看到两张曲线图第一张图是质心位置随时间的变化。初始时刻质心在 0.03m控制器会尝试把它拉回 0。第二张图是 ZMP 位置。如果 ZMP 超出 ±0.1m 的脚掌边界平衡标志位就会变成False。在默认参数下由于初始偏移量较小P 控制器能够把机器人拉回稳定区域平衡标志为True。这说明一个基础的位置反馈已经能够处理小幅扰动。4.5 复现“醉酒式”失衡为了让这个仿真更贴近“醉酒机器人”我们可以做两个修改修改一增大初始偏移量把x 0.03改为x 0.15意味着机器人一开始就有一个很大的倾斜角。运行后会看到 ZMP 很快超出脚掌边界平衡标志变为False质心位置逐渐发散。这说明控制增益不足以应对大幅偏移。修改二增大控制增益但限制加速度把CTRL_GAIN 4.0改成CTRL_GAIN 20.0模仿“反馈很强但执行器响应有限”的场景。你可以再加一个加速度限幅MAX_ACC 1.5 # 最大允许加速度 def p_control(pos_x, target_x): acc CTRL_GAIN * (target_x - pos_x) acc np.clip(acc, -MAX_ACC, MAX_ACC) return acc加上限幅后如果初始偏移还是取较大值控制器实际输出的加速度达不到理想值ZMP 输出会被持续压在一个危险位置附近仿真表现就会出现“抖振”和“间歇性失衡”这就是醉酒步态的一种简化形式。通过这个仿真可以直观验证一个结论只提高反馈增益并不能解决失衡真正的瓶颈在于执行器的加速度饱和边界。这也是我们为什么总强调控制算法必须和硬件执行力共同设计。5. 现实中如何让机器人“醒酒”工程改善方向如果我们在真实机器人上遇到了类似“醉酒”的问题排查顺序和改善方向通常是下面的路径。5.1 检查状态估计先确保“感知准确”姿态传感器数据必须经过滤波和融合。实践中最常见的问题有两个陀螺仪数据没有去除零漂。加速度计噪声过大导致滤波后的角度延迟严重。建议先用离线数据回放画出原始姿态角和滤波后姿态角的对比确认延迟是否在可接受范围内。通常控制频率在 500Hz-1kHz 时姿态估计延迟应控制在 10ms 以内。5.2 调整步态参数降低动态复杂度在控制器没变的前提下把步长调小、步频调低、质心高度略微抬高都能明显减轻失衡。对于比赛或演示环境优先让机器人“走稳”再追求步速。另外要注意双脚支撑期的设置增加双脚同时触地的时间比例可以显著提高抗扰动能力但代价是行走速度下降。5.3 引入踝关节策略与髋关节策略的分工实际控制中不能只有一个位置 P 控制器建议加入 PD 控制甚至更高级的控制策略踝关节负责高频、小幅姿态修正。髋关节负责低频、大幅质心调整。必要时加入上身配重块的反向摆动用于吸收冲击。在代码层面可以把姿态误差分为比例部分和微分部分并在踝关节期望力矩中加入基于 ZMP 误差的修正项。5.4 提高执行层力矩响应除了算法硬件的力矩饱和曲线也要纳入规划。比如在步态规划阶段就通过逆动力学计算每个关节的期望力矩并与电机最大输出力矩比较自动降低步态参数。这样可以避免实际运行时出现“规划得很好但执行不了”的尴尬。5.5 合理选用计算芯片人形机器人运动控制对计算实时性的要求很高。步态周期通常在 0.8s-1.5s但控制周期需要达到毫秒级。单个周期内要完成状态估计、轨迹规划、逆运动学计算和力矩分配普通 MCU 往往吃不消。这也是现场很多机器人采用高性能嵌入式主板或者搭配专门运动控制芯片的原因。例如网络热词里提到的“全志科技 人形机器人芯片”方向本质上就是针对这类边缘计算需求把多核 CPU、GPU/NPU 单元和丰富的外设接口集成在一起让机器人本体能够低延迟地运行视觉、状态估计与控制算法。需要说明的是具体选型要看运动控制算法是跑在传统 MCU 上还是 Linux 系统上一般来说带有硬件浮点单元和多核处理器的方案会更适合跑复杂控制。6. 常见问题与排查清单下面整理一张实际问题排查表方便你在调试机器人时对照使用。问题现象常见原因解决思路机器人站立时轻微左右摇晃姿态估计噪声大控制增益过低调高踝关节 PD 增益增加滤波器带宽起步瞬间往后仰质心初始位置偏后步态规划起步阶段加速过快调整起步时的 ZMP 轨迹增加预备动作行走中突然“跪倒”踝关节扭矩不足或者速度环饱和检查电机最大扭矩降低步频或步长转弯时重心不稳转向步态规划的角速度过快增加转弯步数降低角速度遇到轻微推力就倒髋关节补偿力度不足ZMP 被推出脚掌边界引入髋关节策略提高质心调节速度机器人有“醉酒”般的抖动执行周期不稳定或控制频率过低检查控制线程实时性提高关节指令频率排查时建议按固定顺序走一遍先看传感器原始数据是否能正常采集。再看机器人在静态站立时是否稳定。然后测试原地踏步。再进行直行步态测试。最后做转弯和受扰测试。从简单到复杂逐步验证能快速定位到底哪一层出了问题。7. 最佳实践与工程建议结合近年人形机器人比赛和实际项目经验下面几条建议属于通用性较强、值得反复强调的内容。第一控制框架一开始就要预留接口。很多团队最开始只写了简单的关节位置跟踪后面想加 ZMP 修正就非常痛苦。建议规划层、控制层、执行层之间使用标准格式的数据流比如把期望姿态、期望角速度、期望力矩统一为接口方便后续替换算法。第二所有参数都要支持在线调试。比赛现场不可能频繁重新编译固件。步长、步频、PD 增益、质心高度这些关键参数应该做成可以通过上位机实时修改的配置项。推荐保留一个简单的调试面板或者接入 ROS 动态参数配置工具。第三安全问题必须优先设计。机器人一旦失控几百牛顿的力矩对人体是很危险的。现场实验时要设置急停开关和软限位。运动控制代码里应该有独立的看门狗任务一旦发现控制线程失步或者姿态角超限立即强制进入安全停靠状态。第四记录数据和回放数据同样重要。至少把关节角、关节速度、姿态角、ZMP估算值、参考轨迹以固定周期记录到 SD 卡或本地文件。失衡往往发生在毫秒级的时间窗口里如果没有数据回放排错就像盲人摸象。第五仿真不能代替真机验证。很多团队在仿真环境里跑得很好一到真实机器人就翻车。因为仿真通常忽略了电机延时、摩擦、齿轮间隙和地面接触变化。除非使用包含完整摩擦模型和电机动力学的高保真仿真平台否则仿真结果只能作为一种参考。第六要重视整机重量分布。质心高度和重量分布直接决定了平衡控制的难度。如果条件允许把较重的电池和计算单元尽量放在髋关节附近降低质心高度。这不仅能提升稳定性也能降低对踝关节力矩的要求。8. 动手玩一玩从仿真到真机如果你是一名初学者看完本文后不必马上去买一台昂贵的双足机器人。可以先做三件事把上面的 Python 仿真代码跑起来手动调整初始偏移和加速度限幅参数观察 ZMP 出边界的过程。用树莓派或者任何一块 Linux 开发板接一个 MPU6050 姿态传感器写一个简单的姿态估计程序体会“感知”与“控制”之间的延迟问题。找一个低成本的两轮自平衡小车项目把 PD 控制跑通。两轮车虽然结构简单但已经包含倒立摆控制和传感器反馈的核心问题。从二维到三维从固定底盘到双足控制理论是相通的。你在两轮小车上积累的对滤波、控制增益、稳定性边界的理解完全可以迁移到人形机器人上。网络热词里提到“人形机器人”和“全志科技 人形机器人芯片”等相关方向也说明一个问题人形机器人正从实验室走向比赛场和行业应用底层控制依然是决定产品能否落地的关键瓶颈之一。芯片算力提升、电机性能改善都能提供更好的执行基础但最终稳定行走还是要靠扎实的运动控制算法。希望这篇围绕“醉酒机器人”展开的文章能帮你建立关于双足步态稳定的完整思维框架。下次再看到某个机器人在视频里走得不稳你能一眼看出它背后的控制问题到底是什么而不是简单地用“坏了”来概括。