如果你正在做人形机器人的双足行走，这篇文章想解决的不是“怎么把 walking 调得更漂亮”，而是当它一迈步就飘、切支撑就乱、走几分钟后突然崩时，你应该先看什么、按什么顺序测、哪些地方先怀疑、哪些地方先不要乱改。对实机来说，walking 更像一次整机压力测试。真正放大问题的，通常不是少了某个更聪明的步态算法，而是接触切换、状态估计、执行器带宽、热降额、电源波动和保护逻辑在同一个闭环里一起出错。
这篇适合谁
- 你已经有下肢平台或整机样机，站立和基础关节控制没问题，但一进入迈步就不稳定。
- 你想把“能走几步的视频”推进到“能重复、能排错、能回归”的工程状态。
- 你现在最需要的不是完整 walking 教程，而是一条更稳的排障入口。
先别急着改的几件事
先别急着调步态，先确认接触信号是不是可信
很多人看到迈步不稳，第一反应就是改步长、步频、摆脚高度。但只要支撑脚判断本身不稳，后面所有参数都可能是在追着假问题跑。脚跟先落、脚尖轻扫地、落脚后几帧抖动，都会把“现在到底谁在支撑”这件事搞错。
先别把仿真当实机等价，先核对模型、rigging、时钟和接触观测
仿真能走，只能说明你在那套模型假设里能走。像 MuJoCo Menagerie 的 Unitree H1 模型更适合做结构和接口基线，不适合直接当动力学真值。Isaac Lab 也反复强调，joint order、初始姿态、action scale、decimation、contact sensor schema 只要有一项没对齐，行为就会异常。
先别追花哨全身动作，先把支撑相判断和恢复链路跑通
早期 walking 调试里，上半身更像扰动源，不像能力源。手臂摆动、躯干大幅补偿、头部动作这些东西都可能把本来就脆弱的下半身闭环拖乱。先把支撑相切换、提前落脚、补一步、减速和保护停机这些链路跑顺，再谈更自然的全身动作。
先别把摔倒都归给控制器，先看热、电、延迟和饱和
很多摔倒和“控制器不够先进”关系不大，而是母线电压下滑、关节温度上来后降额、驱动延迟变大、关节接近饱和、保护位频繁触发。要是不把这些信号一起看，你很容易把硬件退化误诊成步态策略错误。
测试梯子才是 walking 的主线
更稳的 walking 不是一上来整机全开，而是沿着一架测试梯子往上爬。前面的每一级都在回答一个更具体的问题：你的状态读得准不准，支撑脚判断稳不稳，摆脚能不能按时抬起来，低速短步能不能重复，退化时能不能可预测地收住。后面所有内容，包括信号检查、故障判断、恢复策略和验收，都应该服务于这条主线。
第 1 级：先把任务边界写死，别空谈“稳定走路”
先把地面、速度、转向范围、连续运行时间、允许扰动和失败后的保护动作写清楚。比如“环氧地坪，0.25 到 0.45 m/s，允许原地转向，不追楼梯，连续运行 6 分钟，轻微侧推后允许补一步恢复，失败后进入保护停机”。这一级的目标不是让机器人走起来，而是把后面所有测试限制在一个可解释的边界里。边界没写死，后面每一次失败都可能变成无穷无尽的口头争论。
第 2 级：把传感、执行器和时钟基线打牢
开始迈步前，先单独确认 IMU 偏置和姿态变化是否稳定，关键关节编码器零位能否重复复现，足底接触信号会不会受轻碰和线缆拖拽干扰，驱动器在低电量和热机状态下的带宽与扭矩上限变化有多大，控制线程、IMU、编码器和接触判断是不是共用同一时间基准。像 Unitree SDK2 这种底层接口包的价值，不只是能发命令，而是能提醒你先把 low-level 状态读全、把 high-level motion service 关干净、把控制回路边界说清楚。第 2 级没打牢，后面所有 walking 调试都会掺着基础设施噪声。
walking 先看哪些信号
别一出问题就先盯着某个步态参数。更有用的第一屏日志，应该至少同时包含这些量：IMU 姿态和角速度，用来判断机体有没有提前失衡；base velocity，用来看速度估计是不是在切支撑时突然跳；joint position 和 velocity，用来看零位、跟踪和相位是否一致；foot contact force，用来确认落脚时序和支撑切换；target vs actual，用来看命令和执行之间有没有明显脱节；母线电压和温度，用来判断是不是低电或热机退化；保护位、限流状态和饱和标志，用来看控制器是不是已经在“带病运行”。没有这组信号，walking 排障基本只能靠猜。
第 3 级：先把“支撑脚是谁”判断稳
这一级的目标不是迈出多漂亮的一步，而是让支撑相切换变得可解释。常见现象是脚刚碰地就突然重心飘掉，或者单脚支撑时 base velocity 和姿态误差一起跳。日志里要重点看 foot contact force、落脚前后几十毫秒的 target vs actual、IMU 角速度、base velocity，以及接触置信度有没有在几个周期里来回翻转。第一反应不要去改全局增益，也不要马上重写整套步态参数，先确认是不是脚跟先触地、接触迟滞太弱、时钟不同步，或者估计器还把失效的脚当可信支撑脚。
先怀疑什么，先不改什么
walking 一出问题，最该先怀疑的通常不是“这套步态思路不行”，而是更基础的五件事。第一，接触误判，尤其是脚尖扫地、脚跟先落或轻微打滑时的假切换。第二，时钟不同步，IMU、编码器、接触判断和控制线程只要错几毫秒，切支撑附近的日志就会看起来像随机故障。第三，零位或 rigging 错，Isaac Lab 文档反复强调 joint mismatch 会直接带来异常行为。第四，执行器限流或热降额，走一会儿才崩往往先查这里。第五，地面摩擦估计偏差，仿真里能过的动作到了实机可能立刻变成打滑。对应地，第一轮排障时先不改全局增益，先不大幅重写整套步态参数，也先不要急着加更复杂的上半身补偿。先把问题压回到可观测、可复现、可定位的层面。
第 4 级：哪一层出问题先查哪一层
当第 3 级能把支撑相切换跑得相对稳定后，再往上看分层问题。上层异常，先看速度和转向输入是不是过激，尤其是停走切换和指令阶跃。中层异常，先看步长、步宽、相位和落脚点是不是超出当前平台的安全窗口。下层异常，先看躯干姿态、摆脚轨迹和关节跟踪有没有饱和或明显滞后。BLF 这类框架把 contacts、estimators、IK、floating base estimator 分开，不是为了显得模块多，而是为了让你失败时能知道先去查哪一层，而不是把所有问题都扔给 walking controller。
第 5 级：把仿真当成暴露假设破裂点的地方
仿真不是用来证明“已经会走”，而是用来暴露“哪些假设一破就走不了”。第一类对照是模型和 rigging 对齐，确认关节表、初始姿态、限位和执行器映射是不是和实机一致。第二类对照是摩擦、延迟和接触误判敏感性，看摩擦下调、延迟上升、接触噪声增加后，最先坏掉的是切支撑、摆脚还是姿态环。第三类对照是扰动、热和电带来的退化，看轻推、低电、热机后的行为是平滑降级还是突然模式崩溃。MuJoCo Menagerie 适合做模型和接口基线，Isaac Lab 更适合做 contact sensor、扰动和部署链路对照，但两者都不能替代实机日志。
第 6 级：恢复策略先求可预测退化
先别急着改复杂恢复策略，先确认系统能不能可预测地退化。恢复优先级最好写死。第一优先级是先找支撑面，比如提前落脚、缩步、把支撑面积找回来。第二优先级是允许补一步，不要死守原参考轨迹。第三优先级是主动降速，尤其在接触可疑、母线电压下滑、温度过高或关节开始限流时。第四优先级才是保护停机、保护下蹲或人工接管。真正有工程价值的 walking，不是“永远不失误”，而是失误后能按同一套顺序收住，而不是每次倒法都不一样。
第 7 级：按梯子式测试，不要一上来整机全开
- 单关节和关节组跟踪，目标是确认限流、延迟、零位和温升基线。主要看 joint pos/vel、target vs actual、保护位和温度。没过这一关，不要碰整机步态。
- 吊架或减重下的原地重心转移和单脚承重，目标是确认支撑相切换和 base 姿态是否可解释。主要看 IMU、base velocity、foot contact force。没过这一关，不要碰连续迈步。
- 固定频率原地踏步，目标是确认摆脚抬起、落脚时序和接触迟滞。主要看 foot contact force、摆脚 target vs actual、IMU 角速度。没过这一关，不要碰速度提升。
- 低速短步直行，目标是验证短时间重复性。主要看 base velocity、姿态误差、关节饱和和母线电压。没过这一关，不要碰转向和扰动恢复。
- 停走切换、原地转向、轻推恢复，目标是看上层命令变化和恢复链路会不会打架。没过这一关，不要碰复杂场景。
- 低电量与热机测试，目标是确认系统只是性能退化，而不是模式崩溃。没过这一关，不要宣称 walking 已经稳定。
- 最后再上更复杂地面和视觉引导，把它们当附加变量，而不是基础 walking 的替代品。
测试梯子每一级的过关标准
每一级都要有明确的 pass / fail、观察窗口、停机条件和进入下一步的前提。单关节和关节组跟踪，至少在完整观察窗口内没有异常限流、没有明显 target vs actual 漂移、温升可解释，才算 pass。吊架或减重的重心转移和单脚承重，要求支撑相切换重复可复现，IMU 和 base velocity 在切换时不出现不可解释的尖峰，否则 fail。原地踏步阶段，要能连续若干周期不出现脚尖连续扫地、接触抖动或姿态误差累积，且停机条件要写死，比如接触连续翻转、角速度超阈值、单关节饱和持续超过设定窗口就停。低速短步直行阶段，进入下一步的前提不是“看起来像走起来了”，而是同一套参数重复多次结果一致。停走切换、转向和轻推恢复阶段，要求失败模式可预测，恢复优先级按预设触发，而不是每次靠运气。低电和热机阶段，如果表现从“能走”变成“直接崩”，就说明前面的梯子其实没真的爬稳。
最容易翻车的地方，改成 4 张 failure signature 卡片
卡 1：足底接触误判
先看到什么： 机器人刚落脚就突然重心飞掉，或者明明没绊到也像被抽走支撑一样侧倒。
日志怎么确认： 重点看 foot contact force、IMU 角速度、base velocity，以及落脚前后几十毫秒的接触置信度有没有连续翻转。常见确认方式是看到脚跟先触地或脚尖轻扫地，但接触状态被过早切成“稳定支撑”。
第一动作不要改什么： 先不要改全局增益，也不要马上放大步宽或重写落脚规划。先查接触迟滞、时间同步、估计器是否还在信错脚。
卡 2：脚尖扫地 / 抬脚失败
先看到什么： 机器人迈步时像轻轻绊了一下，摆脚抬不起来，或者抬起来了但明显慢半拍。
日志怎么确认： 看摆脚 target vs actual、joint vel、膝踝关节有没有接近饱和，结合母线电压、温度和限流状态看是不是低电或热机后响应变慢。如果 base 姿态本身已经先漂了，也要回头看是不是支撑相错误把摆脚预算吃掉。
第一动作不要改什么： 先不要直接把摆脚高度和步长一把拉大，也不要急着加复杂地形感知。先确认执行器余量、抬脚时序和零位有没有问题。
卡 3：走一会儿才崩
先看到什么： 冷机前几十秒没事，过一会儿开始拖步、切支撑变慢、姿态误差变大，最后突然倒。
日志怎么确认： 把温度、母线电压、限流状态、关节饱和和 target vs actual 叠在一起看。常见模式是温度上来后带宽下降，或电压掉下去后同样命令再也抬不起脚。第 1 分钟和第 8 分钟看起来像两台不同的机器人。
第一动作不要改什么： 先不要把这类问题直接归给 walking controller，也不要只在冷机状态继续调参数。先把热机和低电回归纳入固定流程。
卡 4：上半身动作拖死下半身
先看到什么： 下半身单独测试还行，一加手臂摆动、躯干补偿或头部动作，步态就开始飘，转向和恢复尤其容易失控。
日志怎么确认： 看上半身动作引入后，IMU 姿态误差、base velocity 波动和下肢 target vs actual 是否同步恶化。如果下肢接触和执行器本来稳定，问题多半是额外自由度把原本脆弱的闭环推过了边界。
第一动作不要改什么： 先不要为了“更像人”继续叠更复杂的全身控制。先冻结部分上肢自由度，把 walking 基线重新压回简单场景。
工程验收 / 回归检查清单
- 同一套参数，冷启动连续 10 次，行为是否基本一致，而不是一次成功一次失败。
- 满电和低电时，系统是否只是性能退化，而不是直接从“能走”掉到“完全失稳”。
- 连续运行 5 到 10 分钟后，关键关节温度、限流状态、姿态误差和接触切换是否仍然可解释。
- 轻推、轻微打滑和不同地面摩擦下，系统是否进入预设恢复顺序，而不是随机倒法。
- 失败时，日志能不能明确指向接触误判、姿态误差累积、关节饱和、母线波动或保护触发点，而不是只留下“又摔了”。
- 测试梯子里每一级的 pass / fail 记录、观察窗口和停机条件是否真的被执行，而不是凭感觉跳级。
执行建议
- 先把 IMU、base velocity、joint pos/vel、foot contact force、target vs actual、母线电压、温度、保护位和限流状态统一进同一套日志。
- 把低电量 walking 和热机后的 walking 固定纳入回归，不要只测冷机理想状态。
- 如果现在还在频繁摔，先降复杂度，再提速度。先收住接触切换、恢复优先级和测试梯子，再谈更自然的全身动作和更快的 walking。
延伸阅读与参考来源
- Bipedal Locomotion Framework，适合参考 contacts、estimators、floating base estimator、IK 等模块拆分思路，以及近版本对运行时日志与可观测性的强化。
- MuJoCo Menagerie: Unitree H1，适合拿来做仿真模型、关节和场景假设的基线整理，但不应直接当最终动力学真值。
- Isaac Lab Showroom / H1 locomotion demo，适合做扰动、contact sensor、policy deployment 和场景化测试参照，尤其适合核对 rigging 与 observation schema。
- Unitree SDK2，适合参考实机接口、low-level / high-level 边界、状态读取链路和底层控制接入方式。