人形机器人不是一根总线跑到底：四层通信架构与选型账

人形机器人看起来是一个整机，跑起来却像一套联邦。头部相机把图像送主控，每个关节驱动器按固定节拍等位置或力矩指令，指尖传感器不停地往上传接触数据，云端还可能分担一部分推理。这几条链路想要的东西完全不一样，所以正经的人形机器人从来不用一种通信方式打天下。

先把结论放前面：带宽是选型里最不重要的那个数字。周期稳不稳、抖动量级、线束重量、故障怎么被发现、安全链路怎么独立、工具链养起来贵不贵，才是决定设计的东西。一条千兆链路如果每 40 毫秒卡一下，比一条每条报文都按时到达的兆比特总线要糟糕得多。

先分层，再谈协议

工程团队吵协议，多数时候是隔着层在吵。把层分开，一半的争论自动消失。

板级：一块板子内部，芯片到传感器、到执行器。SPI、I²C、UART。

设备级：驱动器之间、关节控制器之间、末端执行器与手臂之间。EtherCAT、CAN、RS-485。

控制器级：实时控制器、运动控制器和主控计算机之间的数据交换。工业以太网，有时是共享内存或 PCIe。

系统级：机器人到遥控终端、边缘服务器、集群管理、云。Wi-Fi、5G、普通以太网。

每一层对”快”的定义都不一样。板级说的是纳秒到微秒；设备级说的是 100 微秒到 1 毫秒的控制周期，而且抖动要小到位置环还能当线性系统来设计；系统级说的是几十毫秒完全可接受、500 毫秒才叫难受。

实际会出现的那些通信方式

EtherCAT：确定性是配出来的

EtherCAT 跑的是标准以太网帧，每个从站在帧经过时当场读写自己的数据再往下传，所以一个周期扫完所有节点靠的是”一帧穿过去”，而不是逐站存储转发。单站转发延迟在微秒量级或更低，这就是为什么 1 毫秒周期带几十个轴是常规操作，100 微秒周期认真调也能做到。

比周期数字更重要的是分布式时钟：从站把本地时钟同步到一个参考时钟，于是轴与轴之间的抖动能压到亚微秒级，哪怕帧本身带着传输延迟。对位置环来说抖动才是敌人——同样是 1 kHz，抖动 200 微秒和抖动 2 微秒，是两个完全不同的控制问题，而整定步骤默认的是后者。

有两件事 EtherCAT 不做，而团队经常默认它做了。第一，它不负责安全：急停、安全限速、安全扭矩关闭属于独立的安全架构，走 FSoE 还是硬线是另一个决定。第二，它不消除布线风险：菊花链少一个接头，下游全掉，所以正经机器要么分段，要么闭环做冗余。

CAN 与 CAN FD：便宜、结实，然后悄悄拥塞

CAN 是差分、多主、自带仲裁的。所有节点都听得到所有帧，ID 小的赢仲裁且不破坏当前帧，错误计数器累计到阈值就让坏节点自己退出而不是把总线拖死。这套机制让它活了四十年，也让它至今还留在人形机器人的关节、电池管理和末端执行器里。

经典 CAN 一帧 8 字节、最高 1 Mbit/s；CAN FD 保留仲裁段的经典速率，把数据段提到 2–8 Mbit/s、单帧 64 字节。这改变的是”每帧能装多少”，不是”每秒能发多少帧”。

决定之前先做一遍算术。经典 CAN 一帧 8 字节报文，算上填充位大约 110–130 位，那么 1 Mbit/s 下一秒钟理论上限接近 8,000 帧。二十个关节，每个关节每毫秒一帧指令加一帧状态，就是 40,000 帧每秒——已经是理论上限的五倍，而且还没算诊断、没算传感器，也没算”持续负载压在一半以下以便仲裁可预测”这条常规经验。这种情况不是靠调参解决的，是要改设计。

CAN FD 是通过”少发帧、每帧多装”把上限抬上去的：原来三帧才能描述一个关节状态，现在一帧够。这么用负载会降；如果把它当”更快的 CAN”、帧数不变，那你很快会发现仲裁段还是经典速率。

RS-485 与 Modbus RTU：两个层，一个名字

RS-485 是电气标准：差分、多点、共模范围够宽，能在车间地板上活着。Modbus RTU 是跑在它上面的协议。把两者混为一谈，就会出现一个工程师在说收发器、另一个在说轮询模型，而双方都没意识到。

真正在规模化时咬人的是轮询模型：一主一问一答，往返串行。加节点、加寄存器，延迟线性增长——对温度传感器无所谓，对关节环不可接受。两端 120 Ω 终端电阻、偏置电阻、共地参考、以及固件里要及时释放驱动器，少任何一条，故障都表现成”随机的协议错误”，改多少遍软件都还在。

工业以太网：TCP 与 UDP 之外，还有”确定性”这件事

TCP 保序、可靠、会重传。配置下发、日志、模型文件、任务数据都该用它。但重传意味着一个丢段就可能让流停上几百毫秒等重传定时器——对视频是可见的卡顿，对控制环是丢周期。

UDP 放弃重传，把”丢了怎么办”交给应用层，所以相机流、点云、状态广播用它。两种协议都不提供时延上界，也都不会因为链路是千兆或万兆就变成实时。

如果硬实时真的必须过以太网，答案是 TSN：交换机上的时间感知调度、gPTP 统一时基、以及给紧急流量做帧抢占。这是交换机、网卡和控制器的选型决定，不是一个软件开关；写架构文档之前，先把路径上每个设备是否支持核一遍。

ROS 2 / DDS：软件之间的公共语言，不是线缆

ROS 2 是框架不是总线，底下用 DDS，给出发布订阅、服务、动作，以及一套被严重低估的 QoS。QoS 可以让一个话题是 best-effort、历史深度浅——因为它传的是 30 Hz 相机流，晚了就没价值；也可以让另一个话题 reliable、历史深度深——因为它传的是标定参数，必须到。

老实说局限也在：普通 Linux 加普通调度器上，DDS 的抖动是毫秒级，负载高时更差，节点加入时的发现流量还会起尖峰。这对感知、规划、导航、任务协同完全够用，对内环不够。工程上能跑通的架构是：伺服环留在 EtherCAT 或 CAN，上面全交给 ROS 2，两层之间有一个显式的、被监控的边界。

Wi-Fi 与 5G：方便，但不进安全链

调试、遥控、视频回传、软件升级，Wi-Fi 是对的选择。任何”失效必须在毫秒内被发现”的场合，它都是错的选择——光是接入点之间漫游切换就可能上百毫秒，信道条件还会无预警变化。

5G 专网扩大了覆盖、改善了移动性，让车队管理、远程协助、云端推理在车间里变得可行。但它不改变安全论证：急停、关节限位、保护性停止留在本地、留在线上，同时必须定义无线链路消失那一刻机器人做什么——保持位置、收回、还是安全停止。”等网络恢复”不是一个行为。

选型前的四个判断

**周期是多少，抖动预算多少。**不是平均速率。1 kHz 带 20% 抖动，和 1 kHz 带 1% 抖动，是两个控制问题；而整定流程假设的是后者。

**每个周期多少字节，乘几个节点。**乘出来。机器人里的带宽事故，几乎都是没人做过的那道乘法。

**失效长什么样，谁会发现。**断线、丢帧、重复指令、节点掉电、总线拥塞，每一种都要有检测手段（超时、心跳、序号、错误计数）和响应动作。协议不给响应，架构给。

**养它多贵。**工具授权、分析仪、会用它的人、供应链，以及团队能不能在客户现场凌晨两点把它调通。一个略好但没人会诊断的协议，是个更差的协议。

一套能落地的组合

先写数据契约，再画总线图

可靠的团队先做那件无聊的事：把每一路信号列出来，填六列——是什么、必须多久到、多少字节、允许多晚、丢了怎么办、属于哪个安全等级。填完再画总线图。

这张表会把藏着的问题掀出来。看起来”锦上添花”的触觉流，因为要喂一个抓握反射，实际截止时间是 5 毫秒；大家都以为要实时的诊断通道，10 Hz 就够；有人想挂到控制总线上的视觉流，是任何现场总线都运不动的 400 Mbit/s。

边界就是设计

没有哪台人形机器人是靠”最好的协议”跑起来的。它靠的是一组写下来、被监控、被测过的边界：这一层是确定的、那一层不是；这个故障在这里被检出、在那里被处理；这条链路允许断，那条不允许。

能长期稳定跑的系统，往往不是通信栈最复杂的，而是边界定义得最清楚、故障处理做得最充分的——这是一个设计决定，不是一张采购单。

常见问题

EtherCAT 能承担安全功能吗？
它本身不能。EtherCAT 是通信与同步技术。安全扭矩关闭、安全限速、安全停止这类功能需要安全等级的那一层——同一物理网络上的 FSoE，或者独立的硬线安全回路——再加上安全控制器和经过验证的架构。

二十个以上关节的人形机器人，CAN FD 够用吗？
可以够，但要降频或减少每关节帧数。经典 CAN 在 1 kHz 下带二十个关节，远超理论帧率上限。CAN FD 的收益来自”每帧装更多、帧数更少”，因为仲裁段仍然按经典速率跑，它并不是单纯的”更快”。

为什么不干脆全上 ROS 2，省掉现场总线？
因为伺服环需要微秒量级的有界抖动，而通用操作系统加 DDS 通常是毫秒级抖动。ROS 2 非常适合感知、规划与协同；最内环应该待在有时序保证的总线上。

5G 够做遥操作吗？
做视频回传和监督控制，通常够；做双边力反馈或任何进入安全链的东西，不够——时延和抖动没有上界、覆盖没有保证、链路会消失。5G 遥操作必须预设链路会断，并定义断的那一刻机器人做什么。

RS-485 和 Modbus RTU 是一个东西吗？
不是。RS-485 描述的是电气层（差分、多点、共模范围），Modbus RTU 是跑在串行链路上的协议。两者常一起用，但混为一谈会导致布线做对了、协议却没按轮询模型规划。