人形机器人混合总线控制网络：EtherCAT与冗余CAN/CANFD的工程实践

做机器人控制这些年我最大的感受是单一总线包打天下的时代早就过去了。尤其是人形机器人整机几十个关节要同步跑身上还挂满了IMU、力矩传感器、温感、电池管理、急停回路同时头顶的视觉、激光雷达还在不断往工控机灌数据——这种情况下如果只押注一种总线要么同步精度不够要么线束重到走不动路要么一旦主链路出点问题整机就瘫。所以我们在实际样机里采用了一套“冗余双CAN/CANFD CANWeb 千兆以太网 EtherCAT”的混合控制网络。听起来东西很多其实分工非常明确EtherCAT管关节的实时同步双CAN/CANFD管安全降级和慢速数据采集CANWeb把传统CAN节点接进以太网做运维监控千兆以太网作为整个系统的主干和管理面。这篇文章把每一层为什么这么选、具体怎么落地、联调时踩过哪些坑一次性讲清楚。适合正在做机器人控制器架构选型、EtherCAT主从站开发、或者想改造传统CAN设备的嵌入式工程师参考。1. 为什么人形机器人需要一张“混合总线”控制网络1.1 先看清人形机器人控制系统的真实负载人形机器人的控制需求粗略可以分成三类。第一类是关节驱动一条腿光髋、膝、踝就六七个自由度整机少说20到40个伺服关节控制周期通常要1kHz甚至更高而且关节之间需要严格同步否则走路的姿态就会抖。这类数据包不大一个关节周期可能就几十个字节但对实时性和同步精度极其敏感。第二类是慢速传感器和安全逻辑。身体各处的温度、电流、电压、按钮、限位开关、电子皮肤、电池管理这类数据采样周期往往只要10Hz到100Hz但节点数量非常多、分布分散。它们对实时性要求不高却要求布线简单、抗干扰强、成本低。第三类是感知数据。相机、激光雷达、麦克风阵列一路信号就是几十到几百Mbps的吞吐量对带宽要求高对实时同步的要求反而不像关节那么苛刻。这三类负载放到一起你会发现很难用一种总线同时满足CAN/CANFD带宽不够带不起视觉EtherCAT虽然实时性好但节点越多对线缆和连接器要求越高千兆以太网带宽大却缺乏硬实时同步机制。所以最合理的做法不是让一种总线包办一切而是让每种总线去做自己最擅长的事。1.2 三条链路各自擅长什么EtherCAT的核心优势是分布式时钟从站之间同步精度可以做到亚微秒级别。它采用“主站发帧、从站在报文飞过时原地读写”的方式一个以太网帧就能覆盖几十个从站非常适合关节这种“大量节点、小数据、高同步”的场景。CAN和CANFD则是工业现场的老牌选手。CAN的物理层是差分信号抗干扰能力强线缆要求低而且有成熟的仲裁机制天然支持多主通信。CANFD在CAN基础上把数据段波特率提升到5Mbps甚至更高单帧最多64字节正好覆盖那些“周期不快但点位多”的传感器。更重要的是CAN总线可以很自然地做成双套冗余这一点在安全链路上价值极高。千兆以太网在这里扮演的是“主干道”角色。它连接工控机、运动控制卡、视觉模块、网管交换机带宽充裕还能运行EtherCAT协议本身——EtherCAT本质上是跑在以太网帧里的所以千兆网口既能做普通TCP/IP通信也能被实时扩展层接管做EtherCAT主站。1.3 冗余双CAN/CANFD在这套体系里承担“第二道防线”有人会问既然EtherCAT这么强为什么还要保留CAN我的回答是EtherCAT链路一旦出问题主控和所有关节之间就完全失联了。实际样机调试时发生过一次很典型的故障EtherCAT主站所在进程因为某个驱动异常导致网卡中断处理不及时整条链路上的关节模组瞬间全部进入看门狗超时机械臂直接卸力。还好我们在关节之外单独拉了一条双CAN总线专门接急停回路、使能信号和电池管理系统。主链路挂了之后双CAN依然在工作至少能保证机器人进入安全停止状态而不是自由落体。这就是冗余双CAN/CANFD存在的意义它不负责跑高性能运动控制它负责在关键时刻给系统留一条“能救命的路”。2. 冗余双CAN/CANFD架构的工程细节2.1 双CAN冗余的两种实现思路双CAN冗余听起来简单实际上有两种完全不同的做法。一种是链路冗余即同一个节点同时挂在两根CAN总线上正常时两路都收发收到重复帧就丢弃当一路总线短路或断开时另一路自动接管。这种方案对单点故障的防护最好因为即使一根线被切断通信也不中断。代价是每个节点需要两颗CAN控制器或者一颗双CAN控制器比如STM32H7、F28P65都有双CAN/CANFD模块硬件成本略高。另一种是功能分区冗余即两块独立的MCU各带一条CAN总线分别负责不同类的功能比如A路负责关节传感器B路负责安全IO两者在逻辑上互为主备。这种方案更灵活适合复杂系统按功能隔离故障域。我在人形机器人样机里采用的是“分区冗余为主、链路冗余为辅”的混合方案动力关节的状态反馈走一条高速CANFD安全相关IO走独立的低速CAN两条总线分别由不同的MCU控制避免单点失效。同时关键节点比如电池管理、急停控制器双挂到两条总线上保证任何一路出问题都不影响这些设备被访问到。2.2 波特率、采样点和位定时的计算CANFD的波特率不是随便填的它分成仲裁段和数据段两个部分。仲裁段负责发送 arbitration 和大部分控制字段数据传输速率不能设置太高因为远距离传输时信号反射和线缆延迟都会影响仲裁可靠性一般取500kbps到1Mbps。数据段负责传输有效数据线缆质量好、节点距离近时可以跑到5Mbps甚至8Mbps。实际配置里我们仲裁段用的是1Mbps数据段用的是5Mbps。这里有一个容易犯的错数据段速率太高时每个节点的位定时参数如果没计算好就会出现偶发错误帧。CANFD的位时间由同步段、传播段和相位段组成。以数据段5Mbps、系统时钟40MHz为例每个位时间分配到8个TqTime Quantum同步段1个Tq传播段2个Tq相位段1和相位段2各2个Tq还剩1个Tq用于寄存器配置时余量。这样采样点大约在75%处处于比较安全的位置。如果用的是标准CAN2Mbps以上时建议把采样点调到80%附近能显著降低总线干扰导致的错帧率。2.3 冗余切换机制不能只是物理上“多一根线”双CAN冗余最容易踩的坑就是硬件上做了两路软件却不知道怎么切。我们最初的做法是主CAN正常工作从CAN始终处于静默监听状态当主CAN连续多个周期没有心跳时从CAN才接管。听起来没问题但实际测试时发现一个问题CAN是总线型拓扑如果主CAN的收发器本身出了问题不是“不发送”而是“持续拉低总线”那心跳信号会变得时好时坏超时判定就会误动作。后来改成双路心跳双路接收的机制每个节点周期性在两个CAN通道上都发送健康帧健康帧里包含节点自身状态字和当前工作模式。接收方只要任一路健康就认为节点正常只有当两路都超时才判定节点离线。同时发送方要实时检测总线错误计数器CAN控制器里的TX Error Counter和RX Error Counter一旦错误计数超过阈值就主动切换发送通道。这样切换是“有依据的切换”而不是“猜着切”。2.4 终端电阻、节点ID和帧ID规划经验CAN总线终端电阻必须放在物理总线的最远端而且必须是120欧姆左右不能省。很多人调试时图省事只在一端接终端电阻短距离测试看不出问题一旦线长超过1米波形反射就会导致偶发UDP这里口误应理解为偶发错误帧和位错误。节点ID规划上我习惯按照部位分区头部设备分配0x01到0x0F躯干分配0x10到0x1F左腿0x20到0x2F右腿0x30到0x3F臂部0x40到0x5F安全系统单独占用0x70到0x7F。这样在总线上看ID就能立刻判断是哪个部位的数据排障效率会高很多。帧ID的分配则要结合CAN的优先级仲裁机制。CAN的ID越小优先级越高所以急停帧、安全状态帧必须占据最低的ID段比如0x001、0x002绝对不能把普通传感器数据放在比急停还高的优先级上否则总线拥堵时急停信号反而发不出去这是安全设计里很基础但也很致命的一点。3. CANWeb让传统CAN设备“开口说”以太网3.1 CANWeb到底解决什么问题CANWeb不是一个全新的物理层协议它本质上是在CAN应用层和以太网之间加了一层“网关对象化数据模型”。你可以把它理解成给传统CAN总线配了一个翻译官CAN那一侧继续用标准CANFD收发数据以太网那一侧则向上提供统一的设备访问接口。在没有CANWeb之前调试一台人形机器人的传感器节点有多麻烦你得在工控机上插一个USB-CAN适配器打开专用的配置软件一台一台地扫描CAN节点手动设置波特率、节点ID、报文格式。节点多了以后每改一个参数都得重新接线下发效率很低。而CANWeb的思路是让每个CAN节点拥有一个类似“寄存器地址”的对象标识网关设备把整个CAN网络扫描到的所有节点、所有数据对象统一映射成一个可访问的数据列表。通过以太网工程师可以用网页、SNMP、Modbus TCP甚至OPC UA去读写这些对象不需要关心底层CAN报文怎么组织。3.2 在人形机器人里的组网位置我们在系统中加了一台CANWeb网关设备它的CAN口连接了双CAN总线的其中一路用于监测和维护以太网口则接到了千兆主干交换机上。这样带来几个直接的好处调试传感器节点时我可以在工控机上打开Web页面看到每一个CAN节点的在线状态、实时采样数据、固件版本甚至远程修改节点参数不需要拎着笔记本电脑钻到机器人底下找调试口。数据记录方便。CAN总线上的采样数据通过网关汇聚到以太网后可以直接用Wireshark或者普通的数据记录软件存成PCAP或CSV分析起来比传统CANalyzer脚本更顺手。和上层监控软件对接容易。机器人上层的状态监控界面通过Modbus TCP去读CANWeb网关里的对象就能把电池电压、关节温度这些数据实时显示出来不需要单独写一套CAN驱动。3.3 与EtherCAT、千兆以太网的分工很多人一开始会把CANWeb和EtherCAT搞混觉得都是“把设备接进以太网”。实际两者的侧重点完全不同。EtherCAT解决的是“实时控制面”的问题它要求控制周期确定、同步精度高、报文在设备间飞行时被硬件处理所有的努力都是为了“不丢帧、不抖动”。CANWeb解决的是“非实时管理面”的问题它更关心设备能不能被方便地发现、配置、监控、维护对实时性要求低很多但对灵活性、开放性要求高。在千兆以太网这个主干上这两者是可以共存的EtherCAT主站独占一个物理网口或VLAN保证实时性CANWeb网关通过普通TCP/IP栈接入另一个VLAN跑管理流量。两者互不干扰这也是我们实战中用得比较顺手的一套组合。4. EtherCAT从零到落地主站、从站与XML配置4.1 主站方案如何选免费开源与商业方案对比EtherCAT主站的选择直接决定了开发效率和后期维护成本。做了几轮对比之后我总结出三种典型路线。第一种是TwinCAT或CODESYS这类商业方案。它们开箱即用从站扫描、PDO映射、NC轴控制都是图形化界面调试效率极高。缺点是需要Windows环境或专用运行平台授权费用不低而且对于一些定制化的调度需求你很难深入底层控制。第二种是SOEMSimple Open EtherCAT Master。这是纯C语言实现的轻量级主站代码简单容易移植到嵌入式Linux或者裸机环境。我们的工控机主站就基于SOEM改造因为它够轻、够透明出了问题能直接跟到源码里查。第三种是IgH EtherCAT Master。它在Linux内核态运行实时性比SOEM的用户态方案更好适合需要硬实时控制周期的场景。代价是驱动开发复杂和发行版内核的耦合度高升级内核时经常要重新编译。如果只是做功能验证我个人建议先上SOEM理由很简单跑通流程最重要。等你把从站扫描、DC同步、PDO映射都理解透了再根据实时性需求决定要不要换IgH或者上商业方案。4.2 主站移植的实际步骤以SOEM为例在主控上移植EtherCAT主站的流程大致是这样第一步确认网卡。EtherCAT对网卡有要求尽量选择Intel I210、I350这类支持独立中断、驱动成熟、发送时间可控的千兆网卡。Realtek的网卡也能跑但延迟稳定性差一些高负载时容易出现周期抖动。第二步绑定网卡驱动。在Linux下让EtherCAT主站直接访问网卡设备而不是走标准网络协议栈。SOEM里会通过AF_PACKET或raw socket方式直接收发帧所以需要先把该网卡从系统网络管理里摘出来避免被NetworkManager等工具干扰。第三步扫描从站。主站启动后发送广播帧总线上的每个EtherCAT从站会返回自己的厂商ID、产品码、站点别名等信息。这一步能看到整条拓扑的基本结构。第四步配置PDO映射。从站默认的映射关系未必符合你的控制需求通常要在主站侧重新指定RxPDO和TxPDO。比如一个关节模组RxPDO里要放目标位置、速度和力矩前馈TxPDO里放当前位置、实际速度、电流和状态字。这个过程本质上是把应用层的数据结构对上从站内部的对象字典。第五步启动DC同步。分布式时钟是EtherCAT的杀手锏。主站会选择一个参考从站让所有从站对齐到同一个时间基准。SOEM中通过初始化DC参数完成对齐完成后从站的同步中断周期就会非常精确地触发。第六步跑通状态机。EtherCAT从站的状态机是INIT、PREOP、SAFEOP、OP四个状态必须依次切换。PREOP阶段可以访问对象字典但还不能执行运动控制SAFEOP阶段输入有效OP阶段所有IO和控制都启用。主站要周期性检查所有从站的状态码任何从站卡在某个状态都会导致整条链路无法进入OP。4.3 从站侧开发SSC与ESI/XML文件如果你的设备不是现成的EtherCAT从站而是要自己做一个那就绕不开EtherCAT Slave CodeSSC和ESI文件。SSC是倍福提供的一个从站代码生成工具可以根据你选的从站控制器芯片比如ET1100、ET1200或者FPGA里的ESC IP核自动生成一套从站固件框架。生成时你可以配置支持多少个FMMU、多少个SyncManager、是否支持DC、PDO的默认映射等内容。生成的代码里包括了EEPROM初始化、ESC寄存器读写、应用层接口等基础模块你要做的就是把关节控制算法或传感器采集逻辑挂进去。ESI文件也叫XML文件是EtherCAT从站的“身份证”。主站扫描到设备后会读取这个XML里面描述了厂商ID、产品码、对象字典、PDO映射、同步模式、看门狗参数等所有信息。很多从站调试问题都出在XML上比如PDO方向定义反了、长度字节数不对、SM通道没配对都会导致主站无法正确识别设备或使能后收发数据错乱。用STM32加ET1100这类独立ESC芯片做从站时STM32通过SPI或并行总线访问ESC内部的寄存器ESC负责所有EtherCAT实时通信STM32只需要响应SYNC0中断去读过程数据、做控制计算、写回输出即可。TI的F28P65这类带双CAN/CANFD、又能外扩并行接口的MCU也适合做多协议从站既能跑EtherCAT又能同步维护CAN总线数据。4.4 关节模组接入的常见坑现在市面上很多一体化关节模组自带EtherCAT从站接口接入起来相对省事但也不是插上就能用。我总结出几个高频坑XML配置信息不一致。关节模组默认的XML文件里描述的PDO顺序和模组固件实际发布的顺序一旦对不上主站配置时不会报错但运行起来数据全是乱的。所以拿到新模组的第一步是用主站工具扫描一次把扫描到的XML内容和厂家给的技术手册逐字段核对。DC模式没选对。有些模组同时支持DC同步和FreeRun模式如果主站没有给从站配置DC模式模组就会按照自己的本地时钟自由运行时间一长同步精度就会漂移。一定要在初始化时明确设置DC模式并把这个参数固化到从站EEPROM里。控制字和状态字的时序。EtherCAT的标准伺服控制流程要求先通过控制字让驱动器经历“伺服使能”的一系列状态变化从状态字中读回确认后才能下发运动指令。很多人直接在OP状态下发位置指令结果电机不动或者报跟随误差就是因为没有走完使能和状态确认的握手流程。看门狗超时设置太短。EtherCAT从站看门狗是防止主站掉线导致从站失控的机制但如果设置太短比如低于主站控制周期的2倍稍微发生一次调度抖动从站就会误判主站离线触发急停。5. 联调实战Wireshark抓包、故障排查与性能优化5.1 如何用Wireshark抓EtherCAT报文EtherCAT不是一个普通应用层协议它直接承载在以太网帧里EtherType是0x88A4。所以在Wireshark里你不需要对网卡抓包只需要在连接EtherCAT主站和从站的链路上做端口镜像或者在主站侧用tap方式抓包然后设置过滤条件eth.type 0x88a4就能看到所有的EtherCAT帧。抓包时重点看几个字段工作计数器WKC它表示这个帧里的命令被几个从站成功执行了如果WKC值和你预期的不一致说明有从站没有正确响应从站状态看它当前停在INIT、PREOP、SAFEOP还是OP以及是否有CRC错误CRC错误说明物理链路有干扰或者线缆品质不行。5.2 常见故障速查表现象可能原因排查顺序主站扫描不到从站网卡驱动问题、从站没上电、线缆接触不良先看网卡灯再测线缆再查从站供电从站卡在PREOP进不了OPPDO映射不对、DC初始化失败、从站看门狗超时检查XML和PDO配置看从站寄存器状态运行中从站频繁掉线网卡中断优先级不够、控制周期太紧、电源波动抓包看CRC错误检查电源纹波放宽周期测试CAN总线偶发错误帧终端电阻缺失、波特率不匹配、采样点设置不当示波器看波形逐个节点排除双CAN冗余切换误动作两路心跳不同步、错误计数器阈值太敏感调大超时冗余时间关闭误报检测5.3 一次真实的联调故障千兆主干上的“掉线迷案”我们曾经遇到过一个很难查的问题系统运行十几分钟后EtherCAT主站莫名其妙报从站丢失但过几秒又自动恢复。一开始怀疑是网卡过热或者线缆松动换了一堆硬件也没解决。最后用Wireshark抓了一段时间的包发现一个规律从站丢失发生的时刻正好和CANWeb网关上报数据的峰值时间重合。再往下查发现CANWeb网关和EtherCAT主站在同一台交换机上两者都跑在同一个VLAN里CANWeb网关的广播数据包虽然不大但在特定时刻会导致交换机缓冲区短暂拥塞EtherCAT的周期帧被延迟了一下从站看门狗就触发了。问题的根子不在EtherCAT本身而在网络规划。解决方案是把EtherCAT和CANWeb管理流量划分到不同VLAN同时给EtherCAT主站网卡配了单独的CPU中断亲和性。改完之后同样跑几小时都没有再出现过掉线。这个案例给我的教训很深刻混合总线架构里总线的物理隔离和逻辑隔离同样重要。不是接了线就能共享一条网线尤其是EtherCAT这种对实时性要求极高的协议必须保证它独占一条“快车道”。5.4 性能调优的正确顺序EtherCAT系统出问题很多人第一反应是改代码、调参数。我的建议是严格按照“物理层、链路层、应用层”的顺序来排查。第一步用示波器看EtherCAT物理层信号也就是以太网差分信号是否干净看有没有大幅度衰减、过冲、噪声。如果物理层都不稳定后面所有软件都是白调。第二步用Wireshark抓包看链路层确认帧有没有CRC错误、WKC是否正确、有没有丢帧重传。这能帮你快速定位问题到底出在主站网卡还是从站响应上。第三步才是看应用层PDO数据对不对、控制周期抖动大不大、DC同步误差有多少。我见过一个团队折腾了整整一周查应用层代码没查出来问题最后发现是网线用了太长的跳线而且线序不对导致信号反射严重。所以顺序很重要别跳步。6. 一点个人体会先做减法再做加法这套混合总线方案并不是一开始就规划得这么完整而是在样机迭代过程中一步步加出来的。最早我们也试过只用EtherCAT一种总线带所有设备结果发现传感器节点成本高得离谱而且安全逻辑和实时控制挤在同一条链路上测试起来提心吊胆。后来才把CAN/CANFD重新引入又因为调试维护太痛苦才加了CANWeb网关。如果你现在正在做人形机器人的控制系统选型我的建议是先把数据分类这件事做扎实——哪些数据必须高实时、哪些数据只是慢速状态、哪些数据只是调试参数然后针对每一类去选总线。不要因为EtherCAT火就把所有东西都往它上面塞也不要因为CAN传统就不愿意用它。冗余这条线一定要从一开始就考虑进去。等到机器人真跑起来再想加一套安全链路结构上会非常被动因为线束、供电、控制板都成型了改造代价远大于一开始的规划成本。最后分享一个小经验不管用哪种总线一定要保证每个节点都有唯一的标识和在线状态上报机制并且把这些状态汇总到一个统一的面板里。人形机器人跟普通设备最大的区别是节点数量多、状态维度杂你不可能靠一颗CPU轮询每一条总线去判断哪坏了。只有所有链路都能在网管层面被看透这个系统才算真正可控。