1. 从“大脑”到“脊髓”：物理AI交互的下一道坎
这两年人形机器人和具身智能的热度，但凡在圈子里待过一阵的人都能感受到。各种演示视频里，机器人能走能跑、能抓杯子能叠衣服，评论区一片“科幻成真”的欢呼。但如果你真正上手过一台人形机器人，或者跟做全身控制的工程团队聊过，就会发现一个很尴尬的现实：大脑很聪明，身体却跟不上。
我这里说的“大脑”，指的是现在大家都在卷的基座模型、视觉语言模型、任务规划大模型。它们负责理解“把桌上的苹果拿给我”这句话，然后拆解成“走到桌边、伸出右手、张开手指、合拢、收回”这一串子任务。这部分在过去两年进步飞快，开源模型和商业API都能做到不错的水平。但“脊髓”呢？也就是从任务指令到关节电机之间那一层——全身协调控制、实时平衡、力位混合、接触响应——这一层反而成了整个系统里最脆弱、最容易被低估的环节。
标题里说的“大脑之外还要一套脊髓”，讲的就是这件事。物理AI要真正在物理世界里交互，光有一个会思考的脑子远远不够，你还得有一套能扛住实时性、能处理全身耦合、能在毫秒级做出反射的“脊髓系统”。这篇文章我就围绕这个核心判断，把物理AI交互具身的下一关拆开来讲。适合正在做人形机器人全身控制、具身智能系统集成、或者单纯想搞清楚这个领域到底卡在哪里的朋友。不管你是刚入门还是已经踩过一些坑，下面这些内容应该都能帮你少走一段弯路。
2. 为什么“大脑+脊髓”的分层架构是必然选择
2.1 基座模型再强，也管不了关节的毫秒级响应
先把这个逻辑说透。现在主流的具身智能方案，基本是“高层规划+底层执行”两层。高层跑在工控机或者云端，频率大概1到10赫兹，负责语义理解、任务分解、路径规划。底层跑在实时控制器上，频率至少500赫兹到1千赫兹，负责关节伺服、力矩分配、平衡补偿。这两层之间的时间尺度差了至少两个数量级。
你让一个跑在10赫兹的模型去直接控制关节，会发生什么？假设机器人正在走路，突然踩到一块松动的砖，脚底力传感器在2毫秒内检测到异常。如果这个信号要上传到高层模型，等模型推理完再下发指令，最快也是100毫秒之后了。这100毫秒里，机器人可能已经失去平衡摔倒了。所以脊髓层必须独立于大脑存在，它不负责“想”，只负责“反应”。
我见过一些团队一开始图省事，把所有控制逻辑都塞进一个Python进程里，用ROS 2做通信。结果就是走路像喝醉酒，稍微有点扰动就晃得厉害。后来他们把平衡控制拆出来，跑在一个独立的实时核上，用C++写，周期1毫秒，效果立刻不一样。这个教训很直接：该分层的时候不要偷懒。
2.2 全身控制不是“多个关节各自为战”
另一个常见的误解是：人形机器人的控制就是每个关节做一个PID，然后让它们各转各的。如果你这么干，机器人连站稳都难。为什么？因为人形机器人的动力学是高度耦合的。你抬左腿，重心会右移；你伸右手，左肩关节的力矩需求会变化。这些耦合关系在数学上体现为质量矩阵、科里奥利力项、重力项之间的相互影响。
脊髓层的核心任务之一，就是全身控制。它要同时解算所有关节的目标力矩，使得机器人作为一个整体满足平衡约束、接触约束、关节限位约束。这本质上是一个带约束的优化问题，常见做法是构造一个二次规划，目标函数里包含任务优先级（比如保持平衡的优先级高于跟踪手部轨迹），约束里包含摩擦锥、关节力矩上限、零力矩点范围等。
我自己的经验是，全身控制的QP问题规模不能太大。一个20自由度的人形机器人，如果考虑所有接触点和任务，QP的变量数很容易超过100。在1毫秒周期内解完这个QP，对求解器要求很高。实践中常用的做法是分层QP或者零空间投影，把任务按优先级拆开，高优先级任务先解，低优先级任务在高优先级任务的零空间里解。这样每层QP的规模可控，实时性有保障。
2.3 脊髓层的三个硬指标：实时、鲁棒、可扩展
判断一套脊髓系统好不好，我一般看三个指标。
第一是实时性。控制周期必须稳定，抖动要小。1毫秒周期下，抖动超过100微秒就可能引起关节啸叫。这要求操作系统用实时内核，代码里不能有动态内存分配，不能有阻塞调用。
第二是鲁棒性。传感器会有噪声，模型会有误差，地面会有扰动。脊髓层不能因为一个异常值就崩溃。常见的做法是加状态观测器，比如用卡尔曼滤波估计质心位置和速度，用动量观测器估计外部扰动力。这些观测器本身也要跑在实时周期里。
第三是可扩展性。今天机器人有20个关节，明天可能加到30个。脊髓层的代码结构要能方便地增加关节、增加传感器、增加任务。我倾向于用组件化的设计，每个关节一个驱动组件，每个传感器一个读取组件，任务层用插件方式加载。这样加一个新关节，只需要注册一个新的驱动组件，不用改核心控制循环。
3. 脊髓层的核心模块拆解与实操要点
3.1 状态估计：脊髓的“本体感觉”
脊髓层要做的第一件事，是搞清楚机器人现在处于什么状态。这包括关节角度、关节速度、质心位置、质心速度、身体姿态、接触状态。这些信息一部分来自编码器，一部分来自IMU，一部分来自力传感器。但原始数据不能直接用，必须经过状态估计。
关节角度和速度相对简单，编码器读数做差分和滤波就行。但质心位置和速度就麻烦一些。人形机器人的质心位置随姿态变化，不能简单用固定值。常见做法是用浮动基座动力学，把机器人看作一个在空间中自由漂浮的多体系统，用IMU和关节编码器做正向运动学，再结合接触力估计质心运动。
我踩过的一个坑是：IMU的安装位置和朝向必须精确标定。如果IMU装歪了1度，质心速度的估计误差会随着时间累积，几分钟后可能偏出几十厘米。标定方法不复杂，让机器人做几个已知动作，比如缓慢前倾后仰，用运动学计算的理论值去拟合IMU的偏差。但这一步很多团队会跳过，后面调试平衡时怎么调都调不好，回头才发现是IMU没标定。
注意：状态估计器的输出频率必须和控制周期一致。如果估计器跑在100赫兹，控制跑在1千赫兹，中间要做插值或者用估计器的预测值。我建议估计器至少跑500赫兹，最好和控制器同频。
3.2 全身控制器：从任务空间到关节力矩
全身控制器的输入是任务指令，比如“质心保持在支撑多边形中心”“右手沿直线运动到目标点”“身体姿态保持竖直”。输出是每个关节的目标力矩。中间要经过动力学解算和优化。
具体来说，控制器先根据当前状态和任务目标，计算期望的质心加速度、期望的角动量变化率、期望的手部加速度。然后把这些期望映射到关节空间，得到期望的关节加速度。最后用逆动力学算出关节力矩。
这个过程中，任务优先级很关键。平衡任务的优先级最高，因为摔倒了什么都做不了。其次是身体姿态，再次是手部或脚部的轨迹跟踪。优先级用零空间投影实现：高优先级任务的解算结果投影到低优先级任务的零空间里，保证低优先级任务不会破坏高优先级任务。
实操中，我建议把任务优先级做成可配置的。比如机器人站着不动时，手部轨迹跟踪的优先级可以高一些；机器人走路时，平衡的优先级必须绝对最高。这个配置可以在运行时动态调整，不用重新编译。
3.3 关节伺服：最后一毫米的精度
全身控制器算出关节力矩后，还要经过关节伺服层才能真正驱动电机。这一层包括力矩控制模式、电流环、摩擦补偿、间隙补偿。
现在很多关节电机支持力矩控制模式，你给一个目标力矩，驱动器内部做电流环。但实际力矩和指令力矩之间会有偏差，主要来自摩擦和传动间隙。摩擦补偿可以用Stribeck模型，低速时摩擦大，高速时摩擦小。间隙补偿需要知道传动链的间隙量，在换向时加一个补偿力矩。
我实测下来，摩擦补偿对低速运动的效果非常明显。没有补偿时，机器人手臂低速移动会一顿一顿的；加了补偿后，运动平滑很多。补偿参数需要实验辨识，让关节以不同速度正反转，记录力矩和速度的关系，拟合出摩擦模型参数。
提示：关节伺服的参数不要一次调太多。先调电流环，再调力矩环，最后加摩擦补偿。每一步都要单独验证，否则出了问题很难定位是哪一层引起的。
4. 从零搭建一套脊髓系统的实操流程
4.1 硬件选型与实时系统配置
搭建脊髓系统的第一步是选硬件。控制器我推荐用x86工控机加实时内核，或者用ARM加RTOS。x86的好处是生态好，ROS 2、Eigen、qpOASES这些库都支持；ARM的好处是功耗低，适合 onboard。如果机器人是电池供电，ARM方案更合适。
实时系统配置有几个关键点。BIOS里要关掉节能模式，CPU频率锁定在最高档。操作系统用PREEMPT_RT补丁，或者直接用Xenomai。中断亲和性要设置，把控制线程绑到独立的核心上，避免和其他任务抢CPU。网络中断也要绑核，最好和控制线程不在同一个核。
我自己的配置是：8核x86工控机，控制线程绑在核2，网络中断绑在核3，其他任务在核0和核1。用cyclictest测下来，最大抖动在30微秒左右，满足1毫秒周期的要求。
4.2 通信架构： EtherCAT与共享内存的取舍
脊髓层内部各模块之间要通信。关节驱动器、IMU、力传感器、控制器、状态估计器，这些模块的数据交换必须低延迟、低抖动。
常见方案有两种：EtherCAT总线和共享内存。EtherCAT的优点是布线简单，一个网线串起所有关节，同步性好，抖动可以做到微秒级。缺点是主站配置复杂，需要专门的EtherCAT主站协议栈。共享内存的优点是延迟极低，几乎零开销，适合同一台机器上的进程间通信。缺点是不能跨机器，扩展性差。
我的建议是：关节驱动器和传感器用EtherCAT，控制器和状态估计器之间用共享内存。这样既保证了硬件的同步性，又保证了核心控制循环的低延迟。共享内存用无锁队列实现，生产者写、消费者读，避免锁竞争。
4.3 控制循环的代码结构
控制循环的代码结构直接决定了系统的可维护性和实时性。我习惯用状态机+组件的模式。状态机管理机器人的运行状态，比如初始化、站立、行走、坐下、急停。每个状态下，激活不同的组件组合。
组件包括：传感器读取组件、状态估计组件、任务规划组件、全身控制组件、关节伺服组件。每个组件有固定的接口：初始化、周期执行、退出。周期执行函数里不能有动态内存分配，不能有阻塞调用，不能有异常抛出。
下面是一个简化的控制循环伪代码，展示结构：
while (running) { wait_for_next_cycle(); // 等待下一个1ms周期 sensor_reader.read(); // 读取EtherCAT数据 state_estimator.update(); // 更新状态估计 task_planner.update(); // 更新任务目标 whole_body_controller.solve(); // 解算全身控制 joint_servo.write(); // 写关节力矩指令 check_safety(); // 安全检查 }这个循环里，每一步的执行时间都要测量。如果某一步超时，要有降级策略。比如状态估计超时，就用上一周期的预测值；全身控制超时，就用上一周期的力矩指令。
4.4 参数辨识与整定
脊髓系统的参数很多：关节摩擦参数、传动间隙、IMU偏差、质心位置、连杆质量、惯量。这些参数不能靠猜，必须辨识。
关节摩擦辨识我前面提过，让关节正反转，记录力矩-速度曲线。质心位置辨识可以用静态平衡法：让机器人摆出多个姿态，每个姿态下测量关节力矩，用最小二乘拟合质心位置。连杆质量和惯量可以用CAD模型估算，但实际值和CAD会有偏差，最好用摆动实验辨识：让机器人手臂自由摆动，记录关节角度和力矩，用动力学方程拟合。
整定顺序我建议是：先辨识关节摩擦和间隙，再辨识质心和连杆参数，最后整定控制器增益。控制器增益从低往高调，先保证稳定，再追求响应速度。
注意：参数辨识要在机器人完全装配好的状态下做。如果换了关节电机或者改了连杆长度，参数要重新辨识。我见过一个团队换了电机没重新辨识摩擦参数，结果走路时关节发热严重，后来发现是摩擦补偿给反了。
5. 常见问题与排查技巧实录
5.1 机器人走路时高频抖动
这是最常见的问题。表现是关节发出啸叫，机器人整体高频晃动。原因通常有三个：控制周期抖动大、关节伺服增益过高、状态估计噪声大。
排查顺序：先用示波器或者实时日志看控制周期的抖动。如果抖动超过100微秒，检查CPU绑核和中断配置。如果周期稳定，降低关节伺服的力矩环增益，看抖动是否消失。如果还不行，检查状态估计的滤波器截止频率，适当降低。
我遇到过一次，周期稳定、增益也不高，但就是抖。后来发现是IMU的采样率是1千赫兹，但数据通过EtherCAT传输时没有做时间戳对齐，导致状态估计用了过时的数据。加上时间戳对齐后，抖动立刻消失。
5.2 机器人受到扰动后恢复慢
表现是被人推一下，机器人晃好几秒才站稳。原因是平衡恢复的增益太低，或者状态估计的延迟太大。
先检查状态估计的延迟。从传感器采样到估计值输出，总延迟应该控制在2毫秒以内。如果延迟大，优化代码或者提高估计器频率。如果延迟没问题，提高平衡任务的增益。但注意，增益太高会引起振荡，要慢慢加。
还有一个容易被忽略的点：接触力的估计。如果机器人脚底没有力传感器，只能用关节力矩估计接触力，精度会差很多。有条件的话，脚底装六维力传感器，平衡恢复会好很多。
5.3 全身控制QP求解失败
QP求解失败的表现是控制器输出异常，机器人突然软掉或者乱动。原因可能是约束冲突、初值太差、求解器迭代次数不够。
排查方法：在QP求解器里加日志，记录每次求解的迭代次数、残差、约束违反量。如果迭代次数经常打满，说明问题规模太大或者初值太差。可以尝试用上一周期的解作为初值，或者降低任务维度。
我自己的经验是，约束要留余量。比如关节力矩上限是100牛米，约束里写90牛米。摩擦锥约束也要留余量，避免求解器在边界上震荡。这样虽然牺牲了一点性能，但稳定性好很多。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| 高频抖动 | 周期抖动大 | 实时日志看周期 | 绑核、关节能、优化中断 |
| 高频抖动 | 伺服增益过高 | 降低增益看效果 | 重新整定力矩环 |
| 高频抖动 | 状态估计噪声大 | 看估计值频谱 | 降低滤波器截止频率 |
| 恢复慢 | 平衡增益低 | 逐步提高增益 | 加力传感器 |
| 恢复慢 | 状态估计延迟大 | 测量端到端延迟 | 优化代码、提高频率 |
| QP失败 | 约束冲突 | 看约束违反量 | 留约束余量 |
| QP失败 | 初值差 | 看迭代次数 | 用上周期解做初值 |
| 关节发热 | 摩擦补偿错误 | 看力矩-速度曲线 | 重新辨识摩擦参数 |
| 关节发热 | 间隙补偿过大 | 换向时看力矩 | 减小补偿量 |
5.5 几个独家避坑技巧
第一个技巧：控制循环里不要用printf。printf是阻塞调用，会破坏实时性。要打日志就用无锁环形缓冲区，把数据写进去，另一个非实时线程慢慢读出来写文件。
第二个技巧：EtherCAT从站的数量不要超过32个。从站太多，总线周期会变长，抖动也会变大。如果关节多，用多个EtherCAT主站，每个主站带一部分从站。
第三个技巧：急停逻辑要独立于控制循环。急停按钮直接切断电机使能，不要经过软件。软件急停作为第二层保护，检测到异常时把目标力矩设为零。
第四个技巧：定期检查关节编码器的零位。人形机器人摔过之后，编码器零位可能会偏。零位偏了，全身控制的运动学模型就错了，走路会歪。我建议每次开机先做一次零位校准，用机械限位或者外部标定工具。
6. 脊髓层与大脑层的接口设计
6.1 任务指令的格式与频率
大脑层给脊髓层发什么？最常见的是任务空间目标：质心目标位置、身体目标姿态、手部目标位姿、脚部目标位姿。这些目标用笛卡尔空间表示，脊髓层负责解算到关节空间。
指令频率不用太高，10到50赫兹就够了。因为大脑层的规划本身就不快，发太快也没意义。但指令里要带时间戳和有效期。如果脊髓层收到的指令超过有效期，就保持上一个指令或者进入安全状态。
我建议指令格式用结构化消息，比如用FlatBuffers或者Cap‘n Proto，序列化和反序列化开销小。不要用JSON，解析太慢。
6.2 状态反馈的内容与频率
脊髓层给大脑层反馈什么？至少包括：质心位置和速度、身体姿态、关节角度、接触状态、电池电量、故障码。频率可以低一些，50到100赫兹。
反馈里最重要的是接触状态。大脑层要知道机器人现在哪些脚着地、哪些手在接触物体。这决定了它能规划什么动作。如果接触状态估计错了，大脑层可能会规划一个物理上不可能的动作，比如让机器人用一只悬空的脚去支撑。
6.3 异常处理与降级策略
脊髓层检测到异常时，要通知大脑层，同时进入降级模式。异常包括：关节过温、力矩超限、状态估计发散、通信超时。
降级策略分几级：一级降级是降低运动速度，二级降级是停止手部任务只保持平衡，三级降级是坐下或者靠墙，四级降级是切断电机使能。每一级都要有明确的触发条件和恢复条件。
我自己的做法是，降级策略做成状态机，和主控制状态机分开。降级状态机优先级更高，一旦触发，主状态机暂停，降级状态机接管。恢复时，先回到主状态机的安全状态，再逐步恢复任务。
7. 关于这套脊髓系统，我的一些个人体会
做全身控制这些年，我最大的体会是：脊髓层的难度不在于算法有多新，而在于工程细节有多密。你可以在论文里找到很漂亮的全身控制算法，但把它变成1毫秒周期下稳定运行、摔了不坏、坏了能查的代码，中间隔着几百个细节。每一个细节单独看都不难，但合在一起就是一道很高的墙。
另一个体会是，不要迷信端到端。现在有一种声音说，基座模型足够强了，端到端直接从视觉到关节力矩，中间不需要脊髓层。我不同意。端到端在仿真里可以，在真机上，实时性和安全性这两关就过不去。脊髓层不是过渡方案，它是物理AI交互的必要基础设施。大脑可以换，脊髓不能没有。
最后分享一个小技巧：脊髓层的代码要写单元测试。全身控制的QP求解、状态估计的滤波、关节伺服的补偿，这些模块都可以单独测试。用录制的传感器数据回放，验证输出是否符合预期。这样改代码的时候，跑一遍测试就知道有没有破坏原有功能。我见过太多团队，脊髓层代码改一处崩三处，就是因为没有测试。
这个方向后续还可以这样扩展：把脊髓层的状态估计和全身控制做成可配置的模板，针对不同构型的机器人（双足、四足、轮足）快速适配。再进一步，把脊髓层的实时数据记录下来，用来训练大脑层的策略模型，形成闭环。这些都是值得投入的方向。
