如果你正在做人形机器人的双足行走，这篇文章想解决的不是“怎么把 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。原地踏步阶段，要能连续若干周期不出现脚尖连续扫地、接触抖动或姿态误差累积，且停机条件要写死，比如接触连续翻转、角速度超阈值、单关节饱和持续超过设定窗口就停。低速短步直行阶段，进入下一步的前提不是“看起来像走起来了”，而是同一套参数重复多次结果一致。停走切换、转向和轻推恢复阶段，要求失败模式可预测，恢复优先级按预设触发，而不是每次靠运气。低电和热机阶段，如果表现从“能走”变成“直接崩”，就说明前面的梯子其实没真的爬稳。
walking 测试梯子速查表
| 级别 | 测试内容 | 这一层主要回答什么 | 至少该盯的信号 | 没过时先别做什么 |
|---|---|---|---|---|
| 1 | 单关节和关节组跟踪 | 限流、延迟、零位、温升基线是否清楚 | joint pos/vel、target vs actual、保护位、温度 | 先别上整机 walking |
| 2 | 吊架或减重下的原地重心转移和单脚承重 | 支撑相切换和 base 姿态是否可解释 | IMU、base velocity、foot contact force | 先别上连续迈步 |
| 3 | 固定频率原地踏步 | 摆脚抬起、落脚时序和接触迟滞是否稳定 | foot contact force、摆脚 target vs actual、IMU 角速度 | 先别急着提速度 |
| 4 | 低速短步直行 | 同一套参数能不能短时间重复复现 | base velocity、姿态误差、关节饱和、母线电压 | 先别碰转向和扰动恢复 |
| 5 | 停走切换、原地转向、轻推恢复 | 上层命令变化和恢复链路会不会打架 | IMU、base velocity、target vs actual、恢复触发顺序 | 先别碰复杂场景演示 |
| 6 | 低电量与热机测试 | 系统是在平滑退化，还是直接模式崩溃 | 母线电压、温度、限流状态、target vs actual | 先别宣称 walking 已稳定 |
| 7 | 更复杂地面和视觉引导 | 附加变量会不会把基础 walking 再次拖垮 | 接触切换、姿态误差、恢复链、任务成功率 | 先别把高级场景当基础能力证明 |
如果你现在在现场排障，不知道今天该停在哪一级，这张表应该比继续改一轮 gait 参数更有用。先看你卡在哪一层，再决定日志该怎么补、测试该怎么收、下一篇文章该接哪篇。
最容易翻车的地方，改成 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 基线重新压回简单场景。
现场 first-look 决策表：看到哪种症状，先压回哪一层
| 现场先看到的症状 | 第一怀疑层 | 先拉哪几路信号确认 | 今天先别做什么 |
|---|---|---|---|
| 一落脚就飘，像突然被抽走支撑 | 接触层 / 时序层 | foot contact force、接触置信度翻转、IMU 角速度、落脚前后 target vs actual | 先别急着改步长、步频和全局增益 |
| 摆脚抬不起来，偶发轻绊或脚尖扫地 | 执行层 / 支撑相判断 | 摆脚 target vs actual、joint vel、膝踝关节饱和、母线电压、温度 | 先别一把把摆脚高度和步长同时拉大 |
| 冷机能走，几分钟后开始拖步、切支撑变慢 | 热 / 电退化层 | 温度、限流状态、母线电压、关节饱和、target vs actual | 先别只在冷机状态继续调 walking 参数 |
| 停走切换、原地转向或轻推后最容易崩 | 上层命令 / 恢复链 | 速度输入阶跃、恢复触发顺序、IMU、base velocity、提前落脚或补一步触发记录 | 先别继续往复杂场景和更快速度上压 |
| 一加手臂摆动或躯干补偿就明显变差 | 自由度耦合 / 余量边界 | IMU 姿态误差、base velocity 波动、上肢动作引入后的下肢 target vs actual | 先别为了“更像人”再叠更复杂的全身动作 |
这张表的作用不是替代完整日志复盘，而是帮你在现场先把问题压回正确层级。先抓对第一怀疑层，比再盲调一轮 gait 参数值钱得多。
仿真、吊架、台架、短步和连续行走，各自到底证明了什么
walking 现场最常见的误判之一，不是参数没调对，而是把上一阶段的通过，误当成了下一阶段已经被证明。仿真能走，不等于实机支撑切换可信；吊架下能迈，不等于自由站立的恢复链已经成立；低速短步重复得不错，也不等于连续运行、热机和低电下仍然稳。真正能帮团队少走弯路的，不是把阶段叫得更完整，而是把每一层到底只证明了什么、还没证明什么写死。
| 当前通过的是哪一层 | 它真正只证明了什么 | 它还没有证明什么 | 进下一层前至少先稳住哪些信号 | 今天先别急着宣称什么 |
|---|---|---|---|---|
| 仿真里能走 | 模型、关节表、基础 observation / action 链至少能闭起来，当前假设下策略或控制器不会立刻发散 | 实机 rigging、接触观测、时钟同步、摩擦偏差、热 / 电退化都还没被证明 | joint order、初始姿态、action scale、contact schema、target vs actual 的基本对齐关系 | 先别说“walking 已经跑通，只差上机” |
| 吊架 / 减重下能迈步 | 摆脚时序、基础相位推进、部分支撑切换在降风险条件下可工作 | 自由站立时的重心管理、真实恢复链、落脚失真后的收口能力还没被证明 | IMU、base velocity、foot contact force、摆脚 target vs actual 在切支撑附近不能乱跳 | 先别说“已经具备自由 walking 能力” |
| 台架 / 单关节 / 关节组跟踪稳定 | 执行器余量、零位、延迟、温升和限流基线至少可解释 | 接触切换、浮动基姿态稳定、整机耦合和落脚误差传播还没被证明 | joint pos/vel、target vs actual、温度、母线电压、保护位和限流状态 | 先别把“驱动没问题”说成“整机 walking 只差调 gait” |
| 低速短步能重复 | 同一套参数在简单边界内已有初步重复性，支撑切换和基础姿态环开始可复现 | 停走切换、原地转向、轻推恢复、热机 / 低电连续退化还没被证明 | IMU、base velocity、foot contact force、姿态误差、关节饱和、母线电压 | 先别说“复杂场景只要再调一点” |
| 连续行走 5–10 分钟也能收住 | 热 / 电退化、恢复顺序、固定回归序列和运行时日志开始形成工程闭环 | 更复杂地面、视觉引导、多自由度上半身动作、真实任务负载还没被证明 | 温度、限流状态、母线电压、恢复触发顺序、失败后定位是否仍可压回固定责任层 | 先别把“基础 walking 稳了”说成“整机动态能力成熟” |
这张表真正想压住的是阶段误报。团队只要把上一层的通过，过早包装成下一层的能力，后面的排障就会越来越像在追幻觉。更稳的做法是：每过一层，只拿到那一层该拿的结论，然后明确写出下一层前还没被证明的东西。
从短步到连续 walking，什么时候才允许升一级
walking 现场还有一种很隐蔽的假进展：不是某一层没过，而是团队把“这一层刚刚能复现”太快升级成“可以进下一层”。真正的升级条件不该靠当天手感，而应该靠同一套证据反复压住。下面这张表只做一件事：把每一层往上推之前，必须先证明什么写死。
| 当前想从哪一层升上去 | 允许升一级前必须先证明什么 | 如果没证明，先退回哪一层 | 今天先不要宣布什么 |
|---|---|---|---|
| 从仿真升到吊架 / 减重 | 同一动作在固定初始姿态、joint order、action scale 和接触 schema 下可重复，不靠随机 seed 碰运气 | 退回模型 / 接口 / 时钟对齐层，先把 target、actual、contact 和 base state 对上 | 先别宣布“策略已经能上机”，最多说“仿真假设下闭环没有立刻发散” |
| 从吊架 / 减重升到自由短步 | 支撑切换前后 IMU、base velocity、foot contact 和摆脚 target vs actual 不乱跳，保护停机能按预期触发 | 退回接触判断 / 状态估计 / 保护链层，先别继续放重心自由度 | 先别宣布“已经能自由 walking”，吊架下的稳定还不是自由站立的恢复能力 |
| 从自由短步升到连续 5–10 分钟 | 低速短步在固定地面、固定速度、固定参数下连续多轮复现，失败时能压回固定责任层 | 退回短步回归层，先固定观察窗口、变量族和失败归因 | 先别宣布“walking 基本稳了”，短步重复不等于热机、低电和连续退化已经过线 |
| 从连续 walking 升到转向 / 轻推 / 停走切换 | 热 / 电退化、限流、恢复触发顺序和停机边界在基础连续行走里已经可解释 | 退回连续行走耐久层，先把温度、母线、电流限制和恢复顺序写清楚 | 先别宣布“可以进复杂场景”，连续直走不等于模式切换和扰动恢复成立 |
| 从基础 walking 升到上半身动作 / 真实任务负载 | 加入上身自由度或任务负载前，已经知道下肢还剩多少姿态余量、执行器余量和恢复余量 | 退回自由度开放顺序 / 耦合预算层，先一项一项放开上身动作 | 先别宣布“整机动态能力成熟”，那可能只是下肢在无负载边界下暂时收住了 |
这张表的用法很简单：每次升级前，先写一句“这一级已经证明了什么”，再写一句“下一层还没证明什么”。如果第二句写不清，今天就不该升一级。walking 的成熟感不是来自更快往上推，而是来自每次升级都有证据、有退路、有明确不该宣称的边界。
工程验收 / 回归检查清单
- 同一套参数，冷启动连续 10 次，行为是否基本一致，而不是一次成功一次失败。
- 满电和低电时，系统是否只是性能退化，而不是直接从“能走”掉到“完全失稳”。
- 连续运行 5 到 10 分钟后，关键关节温度、限流状态、姿态误差和接触切换是否仍然可解释。
- 轻推、轻微打滑和不同地面摩擦下，系统是否进入预设恢复顺序，而不是随机倒法。
- 失败时，日志能不能明确指向接触误判、姿态误差累积、关节饱和、母线波动或保护触发点，而不是只留下“又摔了”。
- 测试梯子里每一级的 pass / fail 记录、观察窗口和停机条件是否真的被执行，而不是凭感觉跳级。
什么时候今天就不该继续测 walking
- 接触层还在乱翻： 如果同一只脚在落脚前后几十毫秒里反复从“可信支撑”跳回“可疑接触”，今天先别继续提速度，也别继续加步数。
- 状态层已经失真： 如果 base velocity、IMU 姿态或足底接触三者里有一项在切支撑附近经常突然跳变，而你还说不清是谁先坏，今天先停在日志和同步层，不要继续调 gait。
- 执行层开始退化： 如果 target vs actual 在热机或低电后明显拉开，或者关节已经频繁限流、饱和、降额，今天先别把问题继续推给控制器。
- 恢复链没有写死： 如果系统现在遇到失衡时到底是补一步、减速、提前落脚还是保护停机都还靠临场反应，今天先别继续做整机 walking 演示。
- 回归序列还不固定： 如果你每次测试都在换地面、换速度、换参数，结果又没有固定观察窗口，今天先别再追“这次看起来好一点”。
这 5 条里只要中了 2 条，今天更值得做的就不是“再试一次”，而是把 walking 压回接触、状态、执行或恢复链的更低一层。真正靠谱的 walking 进度，不是多跑了几趟，而是你知道今天为什么该停在这里。
最小 walking bring-up 验收清单
- 状态层： 你能说清楚 IMU、base velocity、足底接触和关节状态在切支撑前后各自由谁提供、延迟多大、失真时先坏哪一项。
- 执行层： 你已经在冷机、热机、低电三种状态下看过 target vs actual，不会只拿冷机理想状态当 walking 能力。
- 接触层： 你能复现并解释脚跟先落、脚尖轻扫、轻微打滑时的接触判断，不会把假接触直接喂给上层。
- 保护层： 你已经写死减速、补一步、提前落脚、保护停机的触发顺序，而不是摔了以后再猜系统刚才想做什么。
- 回归层： 你有固定的低速短步、停走切换、轻推恢复、低电和热机回归序列，不靠临场发挥选测试。
- 定位层： 每次失败后，你都能把问题先压回接触误判、状态跳变、执行器退化、母线波动或恢复链失序其中一类，而不是统一归因成“walking 还不稳”。
如果这 6 条里还有 2 条以上答不上来，就先别继续追速度、观感和复杂地形。那时候你缺的不是更大胆的步态参数，而是更硬的 bring-up 边界。
摔倒前 2 秒，先按时间顺序看，不要按模块吵
walking 复盘最容易跑偏的地方，是每个模块都拿出一条自己熟悉的曲线，然后会议很快变成“到底是控制器、硬件还是状态估计”的争论。更可靠的第一步不是按团队分工看日志，而是先把摔倒前 2 秒压成一条时间线：谁先偏、谁后跟、谁只是保护性反应。
| 时间窗 | 先看什么变化 | 如果这里先坏，第一怀疑是什么 | 今天先不要怎么解释 |
|---|---|---|---|
| T-2s 到 T-1s | base velocity、COM / ZMP 趋势、步长命令、支撑相切换是否已经慢慢漂 | 任务边界或状态估计已经把系统推到窄裕度区，不是最后一帧才突然坏 | 先别只看倒地瞬间，也别把早期漂移说成“正常波动” |
| T-1s 到 T-300ms | 足底接触置信度、IMU 角速度、摆脚 clearance、target vs actual 是否开始分叉 | 接触判断、摆脚轨迹或执行带宽先掉链子，控制器后面只是在追错误状态 | 先别急着调全局 gait 参数，也别先换策略结构 |
| T-300ms 到 T | 保护触发、力矩限幅、母线电压、温度降额、急停 / recovery 状态机 | 这里常常是后果层：保护逻辑或电热限制在收尾，不一定是第一责任层 | 先别把保护触发等同于根因，也别因为保护救了一次就宣布闭环稳定 |
| T 后 0–2s | 停机姿态、关节残余命令、错误码、人工介入点、是否保住可回放证据 | 恢复链路和证据链是否可靠，决定下一轮能不能复现同一个问题 | 先别立刻复跑冲掉现场状态，也别只靠视频口头复盘 |
这张表的判断重点是先后顺序。如果最早偏掉的是状态估计，最后触发的是力矩限幅，那第一轮应该先回到估计和接触层；如果最早出现的是母线电压下滑或温度降额，那再漂亮的 gait 参数也只是把硬件裕度榨得更干。把根因层和后果层拆开，walking 调试才不会每次都回到同一场争论。
每次摔倒后，最小回放包里必须先留住什么
walking 现场另一个高频假进展，是“又跑一遍看看能不能复现”，结果下一次测试把上一次真正值钱的证据冲没了。真正让团队进步更快的，不是当天多试几趟，而是每次失败后都能留下一份最小回放包，让后来的人不用靠口头回忆猜刚才到底发生了什么。
| 这次失败后最少先留什么 | 为什么现在就得留 | 不留最容易发生什么误判 | 今天先别怎么复盘 |
|---|---|---|---|
| 失败前后 10–15 秒的统一时间轴日志 | 先把接触翻转、姿态漂移、执行滞后和保护触发放回同一时间坐标里 | 大家各看各的曲线，最后谁也说不清是谁先坏 | 先别只截一张局部曲线就下结论 |
| 当次测试的速度、步长、转向和模式切换命令 | 很多“控制器突然不稳”其实只是输入边界和上一轮不一样 | 把输入阶跃错当底层故障，或者把模式切换错当接触问题 | 先别只说“参数差不多”和“就按平时那样测” |
| 母线电压、温度、限流和饱和状态 | 要先分清这是 walking 策略问题，还是热 / 电退化把平台拖垮 | 冷机调出来的结果被误当成全天都成立的能力 | 先别只看姿态和脚底，不看执行器现实约束 |
| 一段正侧后至少两视角视频，或屏幕录像 + 状态面板 | 很多脚尖扫地、落脚拖沓、上身补偿过猛，只看曲线不够直观 | 把可见的动作失真误讲成抽象“系统偶发不稳” | 先别只保留剪成 3 秒的成功片段 |
| 地面、鞋底 / 足底、负载、线缆拖拽和吊架条件记录 | 现场边界一变，接触和恢复链就可能完全换问题 | 把场地或挂载变化误判成算法随机性 | 先别把“今天场地也差不多”当作等价条件 |
| 本次改了哪 1–2 个变量，以及没改什么 | 只有这样，下次回放才知道失败是新变量带来的，还是旧问题没收住 | 一次改太多后，连偶然成功都无法复用 | 先别一口气同时改 gait、接触迟滞、保护阈值和上身补偿 |
这张表真正想压住的，不是“复盘不够认真”，而是证据蒸发。walking 调试最怕的不是一次摔，而是摔完以后只剩下印象，没有能复跑、能对照、能交接的最小证据包。
执行建议
- 先把 IMU、base velocity、joint pos/vel、foot contact force、target vs actual、母线电压、温度、保护位和限流状态统一进同一套日志。
- 把低电量 walking 和热机后的 walking 固定纳入回归，不要只测冷机理想状态。
- 如果现在还在频繁摔，先降复杂度，再提速度。先收住接触切换、恢复优先级和测试梯子，再谈更自然的全身动作和更快的 walking。
一轮 walking 调试里，今天到底只该改哪一层变量
walking 现场第三种高频假进展，不是没测，而是一次把 gait、接触迟滞、保护阈值、上身补偿和速度边界一起动了。这样哪怕偶尔走成一次，你也不知道到底是哪一刀起作用。更稳的做法是，每一轮只让一种变量族拥有解释权，其余层先冻结。
| 现场现在最像哪种问题 | 今天只放开哪一层变量 | 这轮先冻结什么 | 为什么先这么锁 |
|---|---|---|---|
| 切支撑一乱就飘，先分不清是谁在支撑 | 接触判定阈值、迟滞、去抖窗口、时序对齐 | 步长、步频、摆臂、上身补偿、恢复策略 | 这时最缺的不是更大的动作自由度，而是先把“支撑脚是谁”这件事判准 |
| 摆脚抬不起来、脚尖扫地、偶发轻绊 | 摆脚轨迹高度、抬脚时序、单步 clearance 预算 | 接触迟滞、全局速度、转向、上层模式切换 | 先确认摆脚本身是不是够用，别把上层切换噪声一起混进来 |
| 冷机能走，热机或低电后开始拖步 | 热 / 电边界、限流阈值、降级触发条件、测试电量窗口 | gait 主参数、步态风格、上肢动作复杂度 | 先证明这是退化边界问题，不要在退化平台上误调 walking 主环 |
| 停走切换、原地转向、轻推恢复时最容易崩 | 恢复触发顺序、速度命令斜坡、模式切换守门条件 | 接触参数、摆脚几何、全局增益大改 | 这里首先要收的是命令链和恢复链，不是把所有底层参数再洗一遍 |
| 一加手臂摆动或躯干补偿就明显变差 | 自由度开放顺序、上身动作幅度、耦合预算 | 基础 walking 节奏、速度上限、复杂地形测试 | 先证明下半身基线能带住额外自由度，再谈“更像人”的动作 |
如果一轮测试里同时动了 3 类以上变量，这轮结果更适合记成scouting，不适合记成 validation。偶尔跑成一次也不要急着收工；先把变量数压回去，再做能复现的那一轮。
连续 walking 过线后，先别把上半身、负载和任务一起接上
walking 最容易出现的第四种假进展，是连续 5–10 分钟已经能收住，于是团队马上把手臂摆动、搬运负载、视觉跟随、转向停走和更长任务链一次性接上。这样一崩，现场又会回到“到底是 walking、操作、视觉还是任务规划的问题”这类争论。更稳的升级顺序是：先给 walking 留出扰动预算，再逐层接任务。
| 接上任务后先看到什么 | 第一怀疑层 | 先看哪几路信号 | 今天先不要继续做什么 |
|---|---|---|---|
| 一开手臂摆动或躯干补偿，骨盆俯仰 / 横滚开始放大 | 上身耦合 / 姿态余量层 | trunk angular velocity、hip / ankle torque margin、foot contact confidence、上身动作相位 | 不要同时加快速度、加大摆臂、再切复杂地面；先把上身幅度压回一档 |
| 拿起轻负载后还能走，但步态越来越偏、落脚越来越保守 | 质心偏移 / 负载建模层 | COM / ZMP 趋势、左右足载荷、膝踝电流、负载位置与抓取姿态 | 不要先怪 manipulation 不稳，也不要直接扩大负载重量或任务长度 |
| 视觉跟随或看向目标后一切慢半拍，停走切换变脏 | 感知到 locomotion 的时延 / 命令接口层 | 视觉时间戳、目标更新频率、velocity command ramp、模式切换事件、base velocity actual | 不要先洗 gait 参数；先确认上层命令是不是把 walking 推进了旧世界 |
| 直线连续 walking 可以，任务里一转身、停下、再启动就崩 | 停走 / 转向 / restart 守门层 | 速度斜坡、yaw rate、support phase transition、恢复触发、最后 2 秒命令历史 | 不要继续把任务链写长；先把转向和停走做成独立回归项 |
| 短任务能跑，连续任务十几分钟后开始拖步、过热或保护触发 | 热 / 电 / 连续工况预算层 | 温度曲线、母线电压、限流状态、保护触发顺序、任务段落时间线 | 不要把一次完整 demo 当成可运营；先把热机后的同任务回归跑出来 |
这一步的判断标准很硬：如果基础 walking 一接任务就说不清第一责任层，今天就不该继续包装“能执行任务”。先把扰动来源拆开，让 walking 仍然有解释权，再谈操作、视觉和任务规划的联动。
读完这篇，下一步最该接哪几篇
- 先接《人形机器人状态估计怎么搭》，如果你现在最不确定的是 base velocity、姿态、接触和里程估计到底哪一层先漂。
- 再接《人形机器人全身控制系统怎么搭》，如果你已经能稳定读状态，但一到接触约束、任务优先级和力矩下发就开始打架。
- 补《人形机器人硬件瓶颈怎么定位》，如果你怀疑 walking 的根因根本不在 gait，而在执行器余量、母线压降、热降额和保护边界。
这三篇不是“延伸阅读凑链接”，而是 walking bring-up 最常见的三条真实分叉。先判断你卡在哪一层，再接下一篇，效率会高很多。
延伸阅读与参考来源
- 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 边界、状态读取链路和底层控制接入方式。