人形机器人关节力控测试：一次力矩震荡的排查实录

XiuSLjie

90人浏览 · 2026-07-14 21:51:13

XiuSLjie · 2026-07-14 21:51:13 发布

面向人形机器人 / 关节模组研发与测试工程师

本文首发于 ATEMall 技术社区，转载请注明出处。

1. 搞过人形关节的，都怕这个“力控震荡”

干人形机器人关节测试的兄弟，多半都被“力控不稳”折磨过。

模型在 MuJoCo / Simulink 里跑得漂漂亮亮，一上实体台架，关节力矩就开始抖——目标力矩明明给的是平滑曲线，实测反馈却像心电图。轻则柔顺抓取抓不稳，重则整条腿在支撑相突然发软。

更难受的是定位：你不知道这抖是电机的事、减速器的事、力矩传感器的事，还是总线通信的事。四个嫌疑人，没有证据，只能挨个换件试——一个关节调一周，28 个关节调到天荒地老。

这篇就用一次真实的排查过程，讲清楚怎么把“力控震荡”从玄学变成可定位的工程问题。

2. 先认清现状：人形关节到底怎么通信

要排查，先得知道数据从哪来。当下人形机器人的关节驱动，通信基本是两条路线（这是行业共识，不是我编的）：

● EtherCAT：实时性最强，特斯拉 Optimus、多数高动态整机走这条；据行业统计（ETG 口径，2024）EtherCAT 占工业机器人通信协议约 39.2% 份额。

● CAN / CANopen：成本低、生态成熟、多轴组网稳，大量模组化关节执行器（电机+谐波减速器+FOC 驱动+力矩传感器+绝对编码器一体）用 CANopen 对外通信。

EtherCAT 和 CAN 是机器人行业公认的两大协议。本文的排查针对 CAN/CANopen 关节——如果你的关节走 EtherCAT，那是另一套分析工具链，思路相通但工具不同，后文会说明。

3. 传统排查为什么慢

力矩抖了，老办法无非这几种，都不太好用：

● 示波器看模拟量：只能看到电流/电压波形，看不到总线上力矩反馈帧的真实时序，定位不到是哪一帧出的问题。

● 厂商上位机：每家执行器的上位机都不一样，导出格式五花八门，跨关节对比靠人眼。

● 手撸脚本：python-can 抓帧，自己按 CANopen 对象字典解力矩、位置、状态字……每换一款电机就改一遍脚本，造轮子造到吐。

● 直接换件：传感器、减速器、驱动板挨个换，最费时间，还经常换完发现根本不是硬件的事。

核心痛点就一个：你看不清那一帧总线数据里，力矩反馈到底发生了什么。

4. 实战：一次膝关节力控震荡的定位（CANopen）

U000026a0 以下案例中的 DBC 定义、信号数据和时间戳均为演示性构造，用于说明分析方法，不代表任何真实产品的测试数据。

下面是一个具有代表性的排查案例。工具用开源的 can-log-analyzer（github.com/ATEMall/can-log-analyzer），它干的事很纯粹：把 CAN/CAN-FD 日志按 DBC 解成物理量曲线。

4.1 测试背景

某模组化膝关节，CANopen 通信，做力控柔顺测试：给定恒定目标力矩 8 N·m 保持，要求实测力矩波动不超过 ±5%。结果实测力矩在保持段周期性跳到 0 又弹回，肉眼看台架就是“一抽一抽”地抖。

4.2 Step 1：导入日志，按对象字典建 DBC

把台架采集的关节 CAN 日志（.asc）拖进工具，加载这款电机的 DBC（CANopen 的 TPDO 映射，本质也是“起始位/长度/字节序/scale”那套）：

BO_ 385 Joint_TPDO1: 8 JointMotor SG_ TorqueActual : 0|16@1- (0.01,0) [-50|50] "Nm" Master SG_ PositionActual : 16|32@1- (0.0001,0) [-180|180] "deg" Master SG_ MotorCurrent : 48|16@1- (0.01,0) [-30|30] "A" Master BO_ 641 Joint_TPDO2: 8 JointMotor SG_ StatusWord : 0|16@1+ (1,0) [0|65535] "" Master SG_ MotorTemp : 16|8@1+ (1,-40) [-40|150] "degC" Master

报文 ID 说明：按 CANopen 标准 COB-ID 约定，节点 NodeID=1 时 TPDO1 = 0x180+1 = 0x181（385），TPDO2 = 0x280+1 = 0x281（641）。

4.3 Step 2：先看力矩和电流的时序

勾选 TorqueActual、MotorCurrent 出曲线，问题立刻显形：

时间(s) TorqueActual(Nm) MotorCurrent(A) 现象 0.000 8.02 3.1 正常保持 0.020 7.98 3.0 正常 0.040 0.00 0.0 ← 力矩、电流同时归零（见下方说明） 0.052 8.05 3.2 弹回 0.080 0.00 0.0 ← 又归零，周期约 40ms

这里要先说清楚“0.00”是怎么来的：这一列不是 can-log-analyzer 直接从总线上读到的原始帧值——工具在帧缺失时会显示为空隙、不会替你补 0。表里的 0.00 是力控上位机在这一拍没收到反馈帧时的默认处理：把力矩/电流反馈判为 0，于是输出抽搐。也就是说，界面上“归零”是上层软件的行为，而底层原始 CAN 数据在该时刻究竟是“真的 0”还是“帧丢了”，得靠下一步看总线原始帧才能区分（见 Step 3）。

力矩和电流同时归零再弹回，而且是周期性的。这是个重要线索：如果是力矩传感器漂移，电流不会跟着一起归零；力矩和电流一起掉，说明这一刻要么电机根本没在出力，要么这一帧反馈数据压根没送到。到底是哪种，看状态字和原始帧就知道。

4.4 Step 3：看状态字，区分“没出力”还是“丢帧”

加上 StatusWord 和 MotorTemp 继续看：

时间(s) StatusWord MotorTemp(degC) 分析 0.020 0x0637 72 运行使能 0.040 (无该帧) -- ← TPDO 在这个周期缺失 0.052 0x0637 73 恢复

关键发现：归零的时刻，TPDO 帧本身缺失了——不是电机报故障（StatusWord 一直是正常的 0x0637），而是那一帧周期性丢了。工具里用“按时间窗口 + 报文 ID 过滤”一卡，能看到 385/641 这两个 TPDO 在固定相位上周期性丢帧。

4.5 Step 4：定位根因

丢帧 + 周期性 + 温度还在缓慢上升，几条线索拼起来，方向就清楚了：

● 不是力矩传感器问题（电流同步掉，排除）；

● 不是电机故障（StatusWord 正常，排除）；

● 是总线负载/节点发送问题——这条 CAN 上挂了多个关节，高负载下该节点 TPDO 周期性丢帧，上位机拿不到反馈，力控环这一拍直接判成 0，于是输出抽搐。

后续方向：降低该段总线负载（调 TPDO 周期/改用 CAN-FD/拆总线），或把力控环对“丢帧”做保持-插值兜底。从导入日志到锁定“周期性丢帧”，前后不到十分钟，比挨个换件快太多。

顺带说一句方法论：排查时我把不确定的 CANopen 对象字典含义、信号字节序怎么对，直接丢给 ATEMall 的 AI 问答查（覆盖 CAN/HIL/UDS 这些），比翻 PDF 手册快。

5. vs 商业工具 / 传统方式：补充，不是替代

维度	can-log-analyzer	商业总线工具	示波器/上位机
已有，但看不到帧	CAN 日志按 DBC 解	支持	不支持
成本	开源免费	License 数万/年	多信号时序对比
丢帧/负载定位	过滤+时序一眼看出	支持	难
上手	解压即用	配置重	—
EtherCAT 关节	不支持（用分析仪）	部分支持	—