☰
双足机器人独立行走技术解析:从ZMP步态控制到工程化落地
2026/10/19 1:36:14 网站建设 项目流程

墨甲机器人这个名字进入公众视野时,通常和两个词绑在一起:奇瑞,以及“独立行走”。前者代表造车背景带来的供应链与工程协同,后者既是机器人产品层面的技术指标,也是公司从“背靠大树”走向“自主经营”的发展命题。双足或四足机器人能不能真正离开支持、依靠自身能力和环境感知完成稳定移动,是运动控制、硬件设计、状态估计和工程测试共同作用的结果。

这篇文章不讨论资本节奏,只讨论更值得工程师关心的部分:机器人“独立行走”背后到底需要哪些技术基础,从实验室样机到可交付产品需要补上哪些工程能力,以及一个机器人团队从依赖车企资源转向独立技术闭环时,最容易踩到哪些坑。内容会结合双足机器人通用技术路线展开,部分示例需要根据实际项目使用的硬件平台和软件栈调整。

1. 机器人“独立行走”到底难在哪:先理解平衡与步态控制的核心机制

1.1 从静态稳定到动态稳定:为什么轮式简单、双足难

轮式机器人稳定的原因很简单:重心始终位于支撑面的几何中心附近,轮子与地面接触点足够多,静止时不会倒。双足机器人在静止站立时只有两个脚掌作为支撑,重心稍微偏移就可能超出支撑多边形。更麻烦的是,行走过程中会存在单脚支撑阶段,此时有效支撑面只有一个脚掌,系统本质上是不稳定的倒立摆结构。

所以双足机器人不是靠“站直”保持平衡,而是靠连续调整脚掌位置、身体姿态和关节力矩,让实际受力状态始终处于安全区间。这个调整过程必须在线完成,并且要比步态周期快得多。控制周期通常需要达到 1ms 级别,也就是说每毫秒都要完成一次状态更新和力矩计算。

机器人对“稳定”的判断,通常采用 ZMP 理论。ZMP 是零力矩点,指的是地面反作用力合力在地面上的作用点。只要 ZMP 落在支撑多边形内部,机器人就不会绕脚掌边缘翻转。这个理论把复杂的多体动力学问题简化成对支撑区域的计算,也是很多双足机器人步态规划的基础。

1.2 ZMP 和倒立摆模型:理解平衡控制的两把钥匙

把双足机器人简化为一个集中在质心的质量块,腿部视为无质量连杆,就得到线性倒立摆模型。质心高度固定,地面反作用力沿质心指向 ZMP 方向运动。这个模型虽然简化了很多细节,却能准确描述行走时质心和 ZMP 的关系,是步态规划中最常用的近似。

ZMP 和质心的关系不是显式的正比关系,而是体现为微分方程。给定期望的 ZMP 轨迹,需要反推出质心轨迹;给定质心轨迹,又要验证 ZMP 是否稳定。工程上常用预览控制来解决这个问题:在计算当前期望轨迹时,同时参考未来若干步计划中的 ZMP 目标点,让质心轨迹提前响应,避免动作滞后导致失稳。

静态稳定和动态稳定是两种完全不同的设计思路。很多双足方案会采用“准静态行走”,也就是每一步都慢到近乎静止,重心始终位于支撑面内,这样控制难度低但对速度、能耗和姿态要求都很高。真正的高动态行走需要允许系统在局部时间段内处于不稳定状态,通过连续调节支撑点和关节力矩让系统保持在“可恢复”范围内。

类别稳定判断依据典型运动速度控制难度适用场景
静态稳定重心投影始终在支撑多边形内很慢,接近原地踏步低教学、简单演示、低速巡检
动态稳定ZMP 始终位于支撑多边形内,允许质心处于持续调整状态中高速,可连续行走高人形机器人、双足机器人、复杂地形移动

这里容易误解的一点是:动态稳定并不意味着“随时都不倒”,而是说系统每一时刻的状态都在控制器的可收敛范围内。一旦 ZMP 超出支撑多边形,机器人就会绕着脚掌边缘倾倒,此时仅靠关节力矩很难纠正,需要跨步或手臂摆动来恢复。

2. 支撑独立行走的传感器与执行器架构

2.1 感知与状态估计:IMU、编码器、力传感器各负责什么

机器人要知道自己当前处于什么姿态、重心在哪里、每个关节处于什么角度,才能决定下一步怎么走。这个“知道自己状态”的过程叫状态估计。双足机器人通常依赖三类传感器:

  • IMU 安装在机身处,提供三轴角速度和三轴加速度,用于估计机身姿态、角速度和位置变化。IMU 数据高频但有积分漂移,需要与其他传感器融合。
  • 关节编码器安装在每个关节电机输出端,提供各关节角度和角速度。编码器精度直接影响关节位置控制质量,但无法直接感知外力。
  • 足底六维力传感器测量足端受到的三个力和三个力矩。通过足底受力可以推算实际 ZMP,校验规划轨迹是否真的安全落地。

这些传感器数据不能直接使用。IMU 有噪声和温漂,编码器存在零点偏差,力传感器需要标定。常见做法是用扩展卡尔曼滤波或无迹卡尔曼滤波,把多源数据融合成一个一致性更好的状态估计结果。状态估计一旦发散,后面的步态规划和平衡控制都会失效,因此双足机器人最先调试的往往不是控制算法,而是状态估计的稳定性。

通常还需要建立机身坐标系和世界坐标系。IMU 安装方向、足底力传感器安装方向、关节零位这三个坐标系必须严格统一,否则会出现“传感器已经翻转但代码里没有感知”的隐蔽错误。调试初期建议在静止状态下验证姿态角是否与水平仪一致,再进入动态测试。

2.2 执行器:电机、减速器与关节控制

执行器决定了机器人能否迅速响应控制器给出的期望力矩。双足机器人对执行器的要求集中在三方面:

一是输出力矩密度要大。行走过程中膝关节和髋关节需要支撑整机重量,减速后关节峰值力矩通常要远超站立时的静态需求。二是响应速度要快。关节力矩延迟过高会导致质心轨迹跟踪滞后,进而破坏稳定性。三是机械刚度要适中。刚度过大容易把冲击直接传给控制器,刚度过低又会导致关节位置跟随误差过大。

常见配置包括伺服电机、无框力矩电机、行星减速器或谐波减速器,关节端还需要配套驱动器,支持位置、速度和力矩三种控制模式。行走控制中高频使用的是力矩模式,因为平衡控制器输出的往往是期望关节力矩,而不是简单的位置目标。位置模式在步态规划中可以用于离线生成关节角度轨迹,但在实时平衡控制中灵活性不够。

关节控制常采用级联 PID。以位置环、速度环、电流环三层结构为例,电流环频率最高,通常在 10kHz 以上;速度环其次;位置环最外层,和上层运动控制器周期对齐。上层控制器输出期望关节力矩后,经过驱动器最终转化为电机电流,这个链路里的每一环增益都需要整定。增益过小表现是动作偏软、跟踪滞后;增益过大会出现关节抖动和电机啸叫。

2.3 控制回路与实时性

双足机器人运行控制程序时,整个闭环可以拆成以下步骤:读取传感器数据、更新状态估计、根据步态规划得到期望质心和足迹、通过平衡控制器计算关节力矩、把力矩指令发送到关节驱动器。每一步都必须在固定周期内完成。

控制主循环的一个典型伪代码如下,用于说明各模块之间的调用顺序,实际工程中还需要加入看门狗和日志记录。

// 双足机器人实时控制主循环,周期 1ms void RealTimeControlLoop() { // 1. 采集传感器数据 ImuData imu = imuDriver.Read(); JointState joints = jointDriver.Read(); FootForce leftForce = forceSensor.ReadLeft(); FootForce rightForce = forceSensor.ReadRight(); // 2. 状态估计融合 RobotState state = stateEstimator.Update(imu, joints, leftForce, rightForce); // 3. 步态规划:根据当前步数生成 ZMP 参考和足迹计划 FootPlan footPlan = gaitPlanner.GetFootPlan(stepCount); Eigen::VectorXd zmpRef = gaitPlanner.GetZmpReference(stepCount); // 4. 质心轨迹生成 Eigen::VectorXd comRef = previewController.ComputeComTrajectory(zmpRef); // 5. 全身动力学控制,求解关节力矩 Eigen::VectorXd jointTorque = wholeBodyController.Solve(state, comRef, footPlan); // 6. 下发力矩指令 jointDriver.SetJointTorque(jointTorque); }

这段伪代码里的重点是分层结构:规划层负责“想走哪”,控制层负责“如何用力”。两个模块之间的通信要使用固定时延的缓存,不能在实时控制循环里做动态内存分配或等待磁盘写入,否则会造成循环抖动。

实时性要求操作系统或中间件具备实时调度能力。学习环境里可以在普通 Linux 下跑,但生产样机会面临调度延迟、缓存抖动等问题,这时要考虑使用实时内核补丁或 RTOS,并把日志、图形界面、远程调试放到非实时线程中。判断系统是否满足实时性要求,可以统计控制循环周期的最大误差和抖动分布,而不仅是平均周期。

3. 步态规划与平衡控制:让机器人走出第一步

3.1 步态周期和足迹规划的基本概念

步态规划要回答三个问题:脚落在哪里、脚何时抬起、质心如何跟随。双足行走是一个周期性过程,通常分为单脚支撑相和双脚支撑相。单脚支撑相里一只脚在空中摆动,另一只脚支撑全身;双脚支撑相里两只脚同时接触地面,稳定性更高。

工程上会先用足迹规划确定每一步脚的落点,再在脚底落地时留出足够的缓冲。步长和步频是最基础的两个参数:步长增加会扩大行走速度范围,但也带来更大的 ZMP 偏移量;步频提高会减少单步周期,要求控制器响应更快。

以一组常见步态参数为例,可以用 YAML 格式集中管理,方便不同实验环境切换:

gait: step_length: 0.30 # 步长,单位米 step_height: 0.05 # 抬脚高度,单位米 step_duration: 0.80 # 单步周期,单位秒 double_support_duration: 0.20 # 双脚支撑时间,单位秒 com_height: 0.85 # 质心目标高度,单位米 controller: frequency: 1000 # 控制频率,单位 Hz preview_steps: 200 # 预览控制参考的未来步数 dt: 0.001 # 控制周期,单位秒

其中preview_steps非常关键。如果预览步数太少,质心轨迹会滞后于 ZMP 预期,机器人容易产生走走停停的僵硬感;如果预览步数太多,计算量增加,而且过于依赖远期规划,遇到临时地形改变时反应变慢。实际调试时可以从 50 到 300 之间扫描,观察 ZMP 跟踪误差和质心加速度波动。

3.2 预览控制:让质心跟在期望 ZMP 后面

线性倒立摆模型给出的是质心与 ZMP 之间的微分关系。给定未来一组 ZMP 参考点,可以通过优化方法求解出一条平滑的质心轨迹。预览控制的核心思想是:控制器不只是看当前误差,还要看未来一段时间的目标变化,提前调整质心运动,这样行走才连贯。

把这个思想落到代码里,就是维护一个未来 ZMP 参考队列,每来一个控制周期,就把最新一步的 ZMP 目标加入队列,同时丢弃最旧的目标,再基于整个队列求解当前需要施加的质心加速度。

预览控制在仿真环境里调通后,要重点关注真实环境中 ZMP 参考与实测 ZMP 的偏差。实测 ZMP 由足底力传感器推算,如果机器人在硬地面上行走,ZMP 落在脚底边缘时状态会突变,需要加低通滤波;如果地面有坡度或软垫,状态突变更明显,控制参数需要重新调整。

3.3 从仿真到样机的最小闭环

学习阶段强烈建议先在仿真环境里跑通完整闭环。常见选择包括 MuJoCo、Gazebo 或基于物理引擎的自研仿真平台。仿真可以快速验证步态规划、状态估计和平衡控制逻辑是否一致,也能安全地尝试激进的参数。

仿真环境里先做三步验证:第一步,机器人原地站立 30 秒,观察质心位置和 ZMP 是否收敛,姿态角是否保持在期望值附近。第二步,原地踏步,观察每次抬脚和落地是否稳定。第三步,直线行走,观察足迹偏差是否累积,10 米行走后是否明显偏离直线。

仿真里调好的参数不能直接搬到真机。真实环境存在传感器噪声、关节柔性、电机延迟、地面摩擦变化,这些差异会导致同样的仿真参数在真机上抖动或失稳。推荐做法是先用减速或缩幅模式跑慢速步态,逐步拉高步频和步长。真机测试必须使用安全绳或吊架,并在测试场周围保留缓冲空间。

4. 从实验室样机到产品化:工程化不是“能走就行”

4.1 稳定性与可重复性:从演示到可交付

实验室里做出一次 5 米连续行走,只能证明原理可行。产品化关心的是十次、百次、千次行走里失败率能低到什么水平,以及失败后能否安全恢复。这个差异是很多机器人团队从原型走向量产时最容易低估的部分。

可重复性建设要从测试指标定义开始。建议把“行走稳定性”拆成几个可量化指标:平均无故障行走距离、单次行走最大偏移、落地冲击峰值、足底打滑检测率。每个指标都要能通过日志自动统计,而不是靠肉眼评估。

指标学习方法产品化方法
稳定性验证观察机器人是否能走 5 米定义行走失败判据,统计 100 次连续行走成功率
定位偏差目测是否偏离直线运动捕捉系统或里程计测量终点误差,设定偏差阈值
控制质量看姿态是否平稳统计质心加速度方差和关节力矩超调量
故障恢复跌倒后手动起重设计倒地检测与自主起身策略,验证恢复成功率

更关键的是记录数据。每轮测试都应该同步保存传感器原始数据、状态估计结果、控制指令和日志事件。出现失稳时,能回放完整数据,定位是状态估计漂移、步态规划错误还是关节执行延迟。没有数据闭环的测试,做得再多也只能算试错,不能算工程验证。

4.2 电力、散热、结构强度与安全防护

机器人走出实验室后,面对的是长时间运行场景。当前轮式或人形机器人普遍依赖电池供电,功耗集中在关节电机、驱动器、计算平台和传感器。使用习惯是站立姿态或低速行走时功耗低,快速行走时功耗显著上升,电池容量和放电倍率都要按峰值场景设计。

散热问题是机器人持续行走的隐形瓶颈。关节电机和驱动器在反复加减速过程中会产生大量热量,如果温度持续升高,驱动器会降频保护,关节响应变慢,进而影响平衡控制。常见方案包括关节处增加散热片、驱动器位于通风较大区域、主控板使用主动风扇或水冷,在封闭外壳结构里尤其要预留风道。

结构强度则要考虑冲击载荷。机器人行走落地时的足底冲击力远超静载,如果结构件设计只校核了静态工况,连续行走后会出现疲劳裂缝或螺丝松动。验收结构件时,除了强度仿真,还要在样机阶段检查连接件是否松动、线缆是否有磨损。

安全防护不能只在演示前临时处理。生产环境应至少配备急停按钮、控制程序掉线自动锁存关节、机械限位、保护性外壳或泡沫缓冲。测试时还要界定人和机器人的安全距离,防止行走过程中发生碰撞。

4.3 学习环境与生产环境的关键差异

很多团队把仿真环境和真机环境混着配置,导致出了 bug 无法判断是环境差异还是代码问题。实际工程中要把环境分得很清楚:

环境目的验证内容额外关注点
仿真环境快速迭代算法规划、控制逻辑正确性物理引擎参数是否合理
硬件在环测试验证传感器和驱动器链路数据采集、指令下发是否正常通信异常、线缆断连、实时性抖动
样机测试验证真实地面和关节响应行走稳定性、可重复性安全绳、急停、地面摩擦、电池电量
小批量试产验证整机一致性和装配效率各台机器性能是否一致工艺公差、标定流程、出厂测试流程

仿真环境里跑通不代表真机能走,这个结论在双足机器人领域尤其明显。建议把硬件在环测试作为仿真和真机之间的衔接层:先把控制算法跑在真实主控板上,传感器数据用回放数据或仿真数据驱动,检查控制循环周期、任务调度和中断响应是否符合设计预期。

5. 从背靠车企到独立运营:机器人团队的技术底座建设

5.1 背靠场景下的技术协同:哪些资源可以直接复用

机器人团队如果依托车企背景起步,早期能获得的价值确实明显。汽车供应链里的电机、减速器供应商可以复用,车企的可靠性测试体系、零部件认证标准和量产工艺经验也能迁移到机器人整机开发中。尤其是汽车电子领域的线束标准、连接器选型和电磁兼容测试方法,对机器人整机稳定性有很大帮助。

但车企平台和机器人产品之间存在本质差异。汽车面向的是标准道路和确定性工况,机器人则要面对室内外开放环境、非结构化地形和不可预知的人机交互。早期可以把车企的很多基础设施“拿来即用”,比如结构件加工资源、测试场地、供应链询价能力,但算法能力、数据体系、产品定义和售后维护必须自己逐渐补齐。

5.2 独立运营需要的工程能力:从项目交付转向产品沉淀

依靠项目制交付时,团队通常在 demo 成功后就转向下一个项目,代码和知识没有沉淀。要支撑独立运营,技术底座至少包括四块:版本管理统一规范,所有算法、仿真环境、测试脚本都受控;模块化架构,步态规划、平衡控制、状态估计之间有清晰接口;持续集成,每次代码提交都自动跑仿真回归测试;数据管理,所有真机测试数据有统一格式和存储位置。

一个可执行的检查清单如下:

  • 代码仓库是否区分算法库、平台驱动库、应用层,编译是否互不依赖。
  • 所有传感器驱动是否提供统一对外接口,更换传感器型号不需要改上层算法。
  • 仿真环境和真机环境是否使用同一套配置格式,避免两边参数不一致。
  • 每次真机测试是否自动生成完整数据包,回放工具是否统一。
  • 远程诊断通道是否能在现场机器人上拉取日志和状态,而不影响实时控制。
  • 是否具备批量标定流程,保证多台机器人的关节零点和力传感器一致性。

这些清单听起来基础,但很多团队在快速迭代时会忽略,等到需要验证新算法或量产一致性时才回来补课,代价往往更高。

5.3 数据闭环与持续回归:独立发展的护城河

独立运营的关键不是“有没有自己的楼”,而是“有没有自己的数据闭环”。机器人在真实场景中的行走数据、故障数据、环境样本,比代码本身更能决定技术迭代速度。背靠车企期间积累的数据,往往是特定工厂或园区场景的有限样本,独立后必须主动扩大数据来源覆盖。

技术团队的研发循环应该始终围绕“试验设计、数据采集、问题定位、算法更新、回归验证”展开。每次算法改动都要求:在仿真库中跑一组回归测试,确认不会破坏已有能力;选择一组代表性场景做真机验证;如果验证失败,把失败数据回汇到训练集或测试集,防止相同问题再次出现。这个循环运转越快,团队对硬件和环境的适应能力就越强。

6. 常见问题排查:机器人起步、失稳、抖动怎么查

6.1 建议的排查链路

双足机器人出问题后,不建议直接修改控制器参数,先按顺序排查:

  1. 确认输入数据是否正常。检查 IMU 测量值在静止时是否稳定,关节编码器是否读数连续,足底力传感器是否标定正确。
  2. 确认数据流链路。从传感器原始值到状态估计输出,每一个中间量是否都有日志,是否可以回放。
  3. 确认规划是否合理。步长、步频、质心高度是否在硬件能力范围内,是否与当前地面条件匹配。
  4. 确认控制指令是否执行。关节力矩指令是否被驱动器正确接收,是否存在 CAN 或以太网通信丢包。
  5. 确认机械和装配状态。螺丝是否松动、关节是否有摩擦、线缆是否拉扯电机轴。
  6. 确认参数是否超出工作区间。控制增益、预览步数、滤波器截止频率是否被调到了不合理范围。

这六步里,前两步最容易被忽略。很多“控制器参数问题”本质上都是传感器数据在某个环节已经失真。

6.2 常见故障现象与处理方案

下面整理了几类在双足机器人调试中出现频率较高的问题。这些问题不是只靠改代码就能解决,需要结合现象逐层排查。

问题现象可能原因检查方式处理建议
上电后机器人站立姿态正常,但迈腿时倾斜失控支撑相 ZMP 规划偏移,或实际 ZMP 未落在支撑面内打印 ZMP 参考曲线和足底力实测曲线,查看落地阶段力分布降低步长,增加双脚支撑时间,调整质心目标高度
行走时膝关节或脚踝持续抖动关节控制增益过高,编码器噪声放大观察关节角速度纹波和力矩指令波动降低速度环和位置环增益,增加编码器滤波
机器人行走越走越偏,无法保持直线左右腿机械公差不同,或足底打滑检查静态姿态是否水平,录制足迹图,查看左右脚落地力差异重新标定关节零点和足底力传感器,检测地面打滑
原地踏步 5 步后姿态漂移IMU 积分漂移明显,或状态估计融合权重不当静止状态观察姿态角是否缓慢变化重新合入力传感器数据权重,检查 IMU 温度漂移
机器人启动瞬间电流过大,驱动器报警控制指令初始值与实际关节位置不一致检查启动时关节位置命令和编码器反馈差值加入轨迹平滑和控制器切换逻辑,启动时先切到位置保持模式
动态行走时后面脚拖地、步态不连贯抬脚高度不足,摆动相轨迹不合理查看摆动腿足端实际轨迹与期望轨迹增加抬脚高度,降低步频,延长双脚支撑时间

6.3 真机测试中的三个高频坑

第一个坑是只在仿真环境中整定参数,忽略真实传感器噪声。仿真中的传感器数据是理想输出的加噪版本,但真实环境中的噪声分布、偶发丢包和地面冲击远比仿真复杂。解决方案是给仿真加入更真实的噪声模型,并在真机测试中做参数鲁棒性测试,而不是只跑一组固定参数。

第二个坑是忽略 IMU 安装位置与机身坐标系的标定。IMU 一旦安装有微小偏转,姿态估计就会出现系统性误差,步态规划基于错误姿态计算,最终表现为“行走中机身缓慢向一侧偏”。标定完成后要在静态和动态两个状态下验证姿态估计与真实姿态一致。

第三个坑是缺少安全丢失时的降级策略。网络断开、主控程序崩溃或 CAN 通信中断时,驱动器如果继续沿用最后一条指令,机器人可能继续输出大力矩。此类问题应在设计初期就实现:驱动器在收不到心跳或指令超时时自动进入锁存或放低姿态模式,主控程序在检测到通信异常时主动停机并记录现场数据。

7. 最佳实践与扩展方向

7.1 从能走、走稳到走得久:建议的分阶段路径

双足机器人的“独立行走”应该拆成由浅入深的三层能力:能走、走稳、走得久。能走代表基本步态周期成立,机器人在平整地面可以连续行走;走稳代表在各种扰动和中等坡度下能保持平衡,具备恢复能力;走得久代表功耗、散热、机械疲劳和算法退化都在可控范围内,能够支持长时间运行。

建议按以下学习路径推进:

  • 第一阶段:在仿真环境中理解 ZMP 和倒立摆模型,调通预览控制。
  • 第二阶段:搭建或使用已有双足平台,跑通固定步态的原地踏步和短距离直线行走。
  • 第三阶段:加入状态估计与力传感器融合,比较仿真和真机的数据差异。
  • 第四阶段:引入扰动测试、斜坡和窄通道场景,提升平衡控制鲁棒性。
  • 第五阶段:建立数据记录和回放机制,开始统计行走成功率和失败原因。
  • 第六阶段:转向强化学习或其他学习类控制方法,在成熟控制框架基础上做策略迁移。

每一阶段都要保留可复现的实验记录,避免出现“这次行走成功,但不知道为什么成功”的情况。

7.2 下一步扩展方向:从步态控制走向完整移动智能

基础步态跑通之后,机器人要进入真实场景,还需要把感知、定位、导航和决策串起来。双足机器人的价值在于通过腿部越过台阶、门槛和复杂地形,这要求步态规划能接收实时地形信息。常见扩展方向包括:基于视觉的足迹规划,利用深度相机或激光雷达估计地面高度图;基于强化学习的步态策略生成,直接从仿真中学习落脚策略并迁移到真机;加入手臂摆动和躯干姿态协调,在负重或推拉物体时维持平衡。

对团队和组织而言,“独立行走”也是一个长期命题。背靠车企可以获得制造与供应链支持,但独立的代价是必须建立自己的算法、数据、测试和售后闭环。机器人产品最终能否走得远,看的不是一次演示有多惊艳,而是同一个动作能否可靠地重复一万次,以及出现问题后能否在最短时间内定位根因并修复。

如果只练一件事,建议练好数据闭环。把每次失稳、抖动、打滑都当成可回放的数据样本,而不是单纯的失败,整个机器人团队的技术积累速度会明显不一样。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询