1. 人形机器人总线为什么“一条道走不通”通信拓扑的分层逻辑1.1 EtherCAT负责“快”CAN负责“多”千兆网负责“大”我在原型机联调阶段最深的体会是人形机器人控制系统对通信的需求不是“哪条总线更快”的问题而是“不同数据本来就该走不同管道”。传统工业机器人固定在一个工位六七个轴、一台控制器一条EtherCAT或者脉冲总线就能从头通到尾。但人形机器人结构完全不同全身几十个主动关节从髋到脚踝每个轴都要有位置、速度、力矩反馈手部腱绳电机和触觉阵列一加就是上百个小节点再加上头部两台双目相机、躯干激光雷达、脚底压力阵列通信对象从“几十个伺服”变成了“几十个伺服加上百个传感器加好几路大带宽视觉流”。如果迷信某一种总线后面一定会有痛点。我最终落地的方案是分层而不是替换EtherCAT负责关节级运动控制周期跑到1ms甚至0.5ms保证位置指令的同步性和确定延迟CANFD负责大量低速传感器、灵巧手腱绳反馈、安全心跳信号节点可以做得便宜、线束可以做得轻且天生支持总线仲裁CANWeb搭在CANFD上层负责设备参数读取、诊断和远程维护相当于让底层的CAN节点在上位机里“有名字、有状态、可访问”千兆以太网单独给视觉点云、状态估计这类大带宽数据使用不参与实时闭环。这三类数据在时间维度上天然就是分开的。关节力矩环需要数十微秒到几百微秒的更新率那是伺服驱动器内部自己完成的事情全局位置环给到EtherCAT主站之前往往已经经过滤波和运动学解算而IMU、压力传感器、急停回路不需要微秒级同步但需要大量节点廉价接入视觉点云一帧就是几百KB到几MB更是完全不适合塞进运动控制总线。把它们全压到一条总线上不是技术不行而是可靠性设计被砍掉一大截。通信一旦堵塞故障边界非常难隔离到底是运动数据超时引起了步态异常还是视觉数据挤占带宽导致指令迟到这个“案发现场”非常难还原。1.2 一张按通信周期归类的数据表在选型阶段我把整机要通信的数据分成下面几类再反推总线选型数据类型节点量级更新周期单次数据量关键诉求对应链路关节伺服指令/编码器反馈30-500.5-2ms每节点8-32字节确定延迟、多轴同步EtherCAT灵巧手/腱绳/触觉/IMU/足底压力30-802-10ms每节点8-64字节节点多、成本低、线束细CANFD急停、电池、关节超限安全信号10-205-20ms每节点几字节独立冗余、抗断线冗余双CAN视觉原始图像/点云压缩流2-6路10-33ms每路数十MB/s带宽大、可丢失重传千兆以太网参数读写、固件升级、日志全节点100ms以上不定可远程、不干扰实时数据CANWeb/维护网如果你把这张表排出来很自然地就不会选择“一条总线走到底”。EtherCAT确实快但每个从站都要ESC芯片和PHY做进掌骨和指尖这种空间紧张的位置成本和布线都是包袱CANFD便宜轻巧可在几十个高动态关节同步场景下带宽又不够而视觉点云无论如何都不能进控制总线否则一个网络风暴就可能让整机失稳。1.3 双CAN冗余到底在兜什么底我习惯把“冗余”放在最前面思考而不是最后补。人形机器人本身是不稳定系统通信断链超过几十毫秒姿态控制器就会拿到错误或者过期的反馈。一台几十公斤的机器人如果因为一条通信线松脱摔倒损失的不是一条线而是关节、外壳甚至周边设备。EtherCAT确实有环网冗余方案但代价是增加从站端口和拓扑复杂度而且无论Cable Redundancy怎么做EtherCAT域内发生物理断开的那一刻帧仍然要重传和切换存在毫秒级中断。对于关节电流环这个中断时间可能仍能接受对安全信号我不希望它和运动控制共用同一个“事故现场”。所以我在设计里把安全关键信号独立挂到双CAN/CANFD网络上。双CAN的物理层简单两路独立收发器每一路都是屏蔽双绞线一路断了另一路继续传而且总线上挂的设备是BMS、急停、安全PLC、关节超限检测这类安全节点和EtherCAT驱动域完全电气隔离。这个隔离本身就是冗余运动总线故障了安全网还知道机器人心跳还存在能执行安全停机策略反之安全网检修时也不会影响运动总线正常运行。2. 双CAN/CANFD通道的冗余机制与带宽边界2.1 用在CAN侧而不是EtherCAT侧的设备类型很多做伺服出身的人会质疑一条CAN的带宽才那么点为什么还要留给几十个节点这里要区分“设备需要的带宽”和“节点数量”。EtherCAT节点通常是伺服驱动器它们每周期要交换完整的控制字、状态字、目标位置、实际位置、力矩电流值单个节点数据量就大。而CAN侧的设备大多数是传感器和执行器中的“小角色”IMU的一次姿态解算结果可以压缩到36字节、每个脚底压力传感器用4字节、腱绳张力计报一个峰值加一个温度也就8字节、急停和电池状态更是几个bit就够。单个设备数据量不大但数量多。这些设备用CANFD还有一个隐藏好处物理层和连接器体积小、线缆轻、成本低。在手臂末端、手指关节这种需要反复弯折的位置轻量化双绞屏蔽线的弯曲疲劳寿命比粗壮工业以太网线好得多布线也灵活。2.2 双发选收与主备切换我建议选哪一种CAN冗余常见两种做法。第一种是主备切换。正常运行时只走CAN-ACAN-B空闲待命主站检测到A路总线上出现Bus-Off、错误被动或者连续收不到ACK立刻把所有报文切到B路。这种方案对总线负载影响小但是切换需要时间主站要通过错误计数或心跳超时判断链路失效再重新建立B路的发送时序收到切换指令的节点还要复位收发状态。整个过程往往需要几个毫秒到十几毫秒对安全信号可以容忍但对需要连续同步的数据不够友好。第二种是双发选收。每个CAN节点同时把同一帧报文发到A、B两条总线上接收节点对两路数据做校验和去重正常时取先到或同帧校验通过的数据某一路连续出错时自动忽略那一路实现无缝切换。代价是总线负载翻倍所以单路平均负载必须压到40%以下否则冗余反而成为不稳定来源。我在样机上用的是双发选收。理由很简单安全关键信号不允许出现“切换瞬间没有数据”的窗口期。双发选收本质是拿带宽换时间确定性而在人形机器人这种一旦摔倒损失巨大的场景里这个交换非常值得。配置上还有两个容易忽略的点。一是两条CAN总线的速率、终端电阻和线缆长度必须保持一致否则双发帧到达时刻差会超出接收缓冲设计窗口二是两边收发器必须独立供电终端电阻只在总线末端各放一个别把120欧姆电阻做到每个节点里。2.3 CANFD报文带宽的一个粗略算账CANFD相对经典CAN最大的提升在于数据段速率和单帧长度。经典CAN一帧最多8字节CANFD能到64字节数据段速率可以到5Mbps左右这就让“几十个传感器节点在5ms内完成一次全量上报”成为可能。我做一个简化估算假设总线上有30个节点每个节点每5ms上报32字节有效数据。如果每32字节打包成一帧CANFD扩展帧仲裁段用1Mbps数据段用5Mbps一帧在总线上的时间大约在110到120微秒量级具体和填充位、CRC段有关。30个节点依次上报总线占用约3.5ms在一个5ms周期里负载率已经到70%如果再加上心跳、CANWeb诊断报文单路平均负载会逼近甚至超过80%。这个结果说明了两件事一是CANFD 5Mbps也并不是无限带宽设计时单路负载率要压在50%以下才安全二是一旦采用双发选收同样的数据必须在A、B两路各发一份等效负载就要翻倍。所以30个节点每5ms上报32字节在该参数下不能全塞进一条5Mbps的CANFD双发链路需要拆分要么把周期放宽到10ms要么拆成两条CANFD冗余对要么压缩上报数据量。CANFD报文的更新率不是越高越好要根据真实传感器带宽去算我的习惯是给足余量让平均负载不超过40%这样双发后约80%总线仲裁冲突处于可控范围。关于CANFD本身还有几个细节使用FDF帧时需要开启BRS位数据段才会切到高速率不带BRS的FD帧实际只相当于放大版经典帧没有发挥速率优势。长线缆、高速率情况下如果发送节点距离接收节点太远信号回波可能导致数据段采样错误这时需要开启收发器的发送延迟补偿功能或者降低数据段速率。2.4 两条总线上的心跳与失联处理冗余CAN网络里除了业务数据还要设计心跳帧。每个安全节点按固定周期发送自己的状态心跳主站维护一个“存活表”连续两个或三个周期没收到某节点的心跳就判定该节点失联。这里有个经验值心跳周期一般设为业务数据周期的1到2倍超时阈值设为3个周期。太短容易因偶发错误误判太长又会让安全响应变慢。我在样机里把CANFD传感器业务周期设在5ms心跳2ms失联判定阈值10ms把急停类安全信号的业务周期设在5ms但心跳周期压到1ms失联判定2ms内立刻触发安全停机流程。心跳还有一个用途判断双发数据是否需要纠偏。如果A、B两路都正常接收节点对两帧数据做逐字节比较发现不一致时以A路为主并记录错误计数如果A路连续错误自动切到B路。在调试时我会把每一路CAN的错误计数、Bus-Off恢复次数都通过CANWeb上报这比事后查CANalyzer日志高效得多。3. CANWeb在管理系统里的位置让CAN总线“可被浏览器打开”3.1 通俗理解CANWebCANWeb不是替代CAN的另一种物理总线而是运行在CAN/CANFD之上的应用层协议和设备管理方案可以把它理解成“给CAN设备做的Web服务器框架”。传统CAN调试有多痛苦做过的人都知道你必须维护一张报文ID表和DBC文件每个字节代表什么全靠人工对照改了一个传感器量程所有排查工具都要跟着改。而CANWeb的思路是把每个设备、每个数据对象都抽象成类似网址或资源节点的形式通过网关把CAN报文翻译成HTTP/JSON之类的结构上位机打开网页就能看到“左肩IMU温度36.5摄氏度状态健康”这样的直观信息而不是十六进制字节流。这个定位正好补上传统CAN的短板物理层够简单可靠但应用层缺少设备模型、在线寻址和状态描述能力。CANWeb相当于给这套总线加了一层“可维护性”。3.2 冗余双CAN与CANWeb的调度共存在冗余双CAN系统里加CANWeb必须解决一个冲突CANWeb的诊断和请求报文如果太激进会抢占安全业务数据的总线时间。我把双CAN上的报文分成两类用不同优先级ID区间隔离。业务数据使用标准11位ID里的低段比如0x100到0x1FFCANWeb请求和响应放到高段0x700以上。CAN标准ID越低优先级越高所以业务数据永远能插队到管理报文前面。实际走下来这个方案比较稳。CANWeb网关在总线空闲期发起设备枚举和参数读取不会干扰固定周期上报的传感器数据。如果某段时间业务数据负载较高诊断报文会自然退避用户看到的只是网页刷新变慢不影响机器人本体运行。还有一点要强调的是CANWeb不建议直接控制关节或安全逻辑。它最适合做的是读取运行参数、设备健康状态、版本信息升级固件时也只下发到非安全节点。实时控制永远走EtherCAT和底层硬逻辑不让维护通道染指这是我一直坚持的架构边界。3.3 设备模型与参数映射表实战为了让CANWeb真正好用需要维护一张设备描述表类似CANopen里的对象字典概念。每个节点有唯一ID每个数据对象有名称、类型、单位、长度、偏移量、读写权限和报警上下限。我在样机里的做法是每个CANFD节点上电时先广播自己的设备类型和版本CANWeb网关根据设备描述文件自动生成节点树。比如足底压力节点会上报6个压力值、1个温度值网关自动形成页面关节超限监测节点上报一组布尔量和触发时刻网关直接把报警渲染成状态卡片。这套东西第一次联调时看不出来优势等到系统跑几个月、现场更换传感器或校准参数时就非常有用。不用拿CAN工具一帧一帧解析直接在网页上把对应通道的量程改掉写入后设备参数就更新了。设备失联时节点树上的状态也会直接标红定位问题从小时级缩短到分钟级。3.4 CANWeb最适合放监控而不是实时控制基于前面说的调度约束我最终把CANWeb定位成“带外管理网络”。它跑在CANFD之上通过一个独立的CANWeb网关接到千兆以太网维护口车间上位机或者远程运维平台通过网页访问。这样部署可以让调试人员在不拆机器人外壳、不接调试器的情况下完成设备枚举、参数检查、历史报警查询甚至可以批量刷新一批同型号传感器节点的固件。但因为CANWeb报文本身要等待总线空闲它的时延是不确定的所以绝对不能拿它做实时闭环。4. EtherCAT从站与主站常见坑从ESC寄存器到Wireshark4.1 选择主站方案的决策记录EtherCAT主站方案有很多常见的是这么几类主站方案上手难度实时性适合阶段PLC加自带上位软件如Easy521配AutoShop低好验证单个关节模组、小批量设备TwinCAT/CODESYS环境中很好原型机快速搭建、少量轴验证Linux IGH/SOEM自研主站高好需要调内核整机多轴、需要深度集成算法Easy521这类PLC自带EtherCAT主站用AutoShop组态后可以直接扫到关节模组配置PDO映射、对象字典都很快。我建议所有第一次接触EtherCAT的人先用PLC或者是TwinCAT把关节模组跑通确认从站的PDO、状态字和同步模式符合预期再考虑自己写主站。否则一上来就在Linux上移植IGH出了问题你根本分不清是主站的问题还是从站配置的问题。等到整机几十个轴联调时我改用Linux IGH因为我们需要把视觉状态估计、步态规划算法和EtherCAT主站跑在同一台机器上这对PLC方案来说很难灵活扩展。4.2 从站ESC、SSC工程与EEPROM信息EtherCAT从站的核心是ESC芯片常见的是LAN9252、AX58100这类。它们内部有协议状态机、SyncManager、FMMU和DPRAMMCU通过SPI或并行接口访问这些资源。很多从站硬件做出来却死活进不了OP状态问题往往不在主站而在ESC初始化。SSC是倍福提供的从站协议栈代码生成工具。生成工程时要重点确认三件事ESC的EEPROM是否烧录了正确的厂商信息、产品代码和站地址配置MCU侧的中断服务函数是否响应了ESC的同步事件PDI读写DPRAM的数据一致性是否锁好。站地址尤其容易踩坑。EtherCAT支持配置别名和动态站地址默认情况下主站会按拓扑顺序分配地址。如果多个从站的EEPROM里设置了相同的配置地址扫描阶段就会出现站地址冲突导致某一站始终切不到OP。4.3 SM/FMMU/DC这些寄存器到底挡在什么地方刚接触EtherCAT的人最容易卡在SM和FMMU。这里我用自己的理解说清楚SMSync Manager是ESC内部同步管理单元负责协调DPRAM里的数据交换。SM0/SM1通常用于邮箱通信SM2/SM3用于过程数据。每周期主站往SM2对应地址写输出数据从SM3对应地址读输入数据。FMMUFieldbus Memory Management Unit类似地址映射表它把主站逻辑数据地址映射到从站物理内存地址。多从站共用一个EtherCAT帧时每个从站的FMMU决定自己在帧里的哪一段插入或提取数据。DCDistributed Clock是分布时钟同步机制用于让所有从站的SYNC事件对齐到同一时间基准保证多轴指令同时输出。如果从站配置了DC但同步周期和主站不一致就会反复从OP掉回Safe-OP。联调时如果某从站卡在PRE-OP到SAFE-OP这一步优先检查SM2/SM3对应的起始地址、长度是否和PDO映射一致如果卡在SAFE-OP到OP优先检查DC周期、同步信号使能和看门狗配置。这些内容在SSC生成的代码中都有默认配置但每个项目改PDO后SM长度常常被忽略最容易出问题。寄存器层面可以看ESC的地址AL Control在0x0120AL Status在0x0130SM配置从0x0800开始每个SM占8个字节FMMU从0x0600开始每个占16个字节。调试早期可以直接读写这些寄存器验证状态机。4.4 单域多从的PDO布局人形机器人控制里我喜欢把绝大多数伺服轴放进同一个EtherCAT域。所谓一个域可以理解成一个EtherCAT帧里包含多个子报文依次和多个从站交换数据。这样做的最大好处是主站一个周期发一帧所有关节同步更新系统运行频率高而且逻辑简单。但PDO总长度有上限。EtherCAT标准帧最大约1500字节扣除以太网头帧头和各种子报文头能承载的有效从站数据在1480字节左右。如果每个关节需要32字节的输入和32字节的输出40个轴就是2560字节已经超过单帧限制。解决办法是拆成多个域或者使用更长的EtherCAT帧扩展。实际项目里我不会在每一个关节上塞满所有数据而是只让PDO包含控制器真正每周期需要的数据目标位置、目标速度、控制字和回读状态字、实际位置、实际速度、力矩电流值、错误代码。诊断类参数按需通过邮箱读取不放在过程数据里。这样单个轴通常能控制在24到40字节40轴左右仍能单域容纳。另外每个从站的PDO映射表需要和驱动器固件保持匹配。改驱动器端的对象字典时主站侧映射表
人形机器人通信架构：EtherCAT、CANFD与CANWeb分层冗余设计
1. 人形机器人总线为什么“一条道走不通”通信拓扑的分层逻辑1.1 EtherCAT负责“快”CAN负责“多”千兆网负责“大”我在原型机联调阶段最深的体会是人形机器人控制系统对通信的需求不是“哪条总线更快”的问题而是“不同数据本来就该走不同管道”。传统工业机器人固定在一个工位六七个轴、一台控制器一条EtherCAT或者脉冲总线就能从头通到尾。但人形机器人结构完全不同全身几十个主动关节从髋到脚踝每个轴都要有位置、速度、力矩反馈手部腱绳电机和触觉阵列一加就是上百个小节点再加上头部两台双目相机、躯干激光雷达、脚底压力阵列通信对象从“几十个伺服”变成了“几十个伺服加上百个传感器加好几路大带宽视觉流”。如果迷信某一种总线后面一定会有痛点。我最终落地的方案是分层而不是替换EtherCAT负责关节级运动控制周期跑到1ms甚至0.5ms保证位置指令的同步性和确定延迟CANFD负责大量低速传感器、灵巧手腱绳反馈、安全心跳信号节点可以做得便宜、线束可以做得轻且天生支持总线仲裁CANWeb搭在CANFD上层负责设备参数读取、诊断和远程维护相当于让底层的CAN节点在上位机里“有名字、有状态、可访问”千兆以太网单独给视觉点云、状态估计这类大带宽数据使用不参与实时闭环。这三类数据在时间维度上天然就是分开的。关节力矩环需要数十微秒到几百微秒的更新率那是伺服驱动器内部自己完成的事情全局位置环给到EtherCAT主站之前往往已经经过滤波和运动学解算而IMU、压力传感器、急停回路不需要微秒级同步但需要大量节点廉价接入视觉点云一帧就是几百KB到几MB更是完全不适合塞进运动控制总线。把它们全压到一条总线上不是技术不行而是可靠性设计被砍掉一大截。通信一旦堵塞故障边界非常难隔离到底是运动数据超时引起了步态异常还是视觉数据挤占带宽导致指令迟到这个“案发现场”非常难还原。1.2 一张按通信周期归类的数据表在选型阶段我把整机要通信的数据分成下面几类再反推总线选型数据类型节点量级更新周期单次数据量关键诉求对应链路关节伺服指令/编码器反馈30-500.5-2ms每节点8-32字节确定延迟、多轴同步EtherCAT灵巧手/腱绳/触觉/IMU/足底压力30-802-10ms每节点8-64字节节点多、成本低、线束细CANFD急停、电池、关节超限安全信号10-205-20ms每节点几字节独立冗余、抗断线冗余双CAN视觉原始图像/点云压缩流2-6路10-33ms每路数十MB/s带宽大、可丢失重传千兆以太网参数读写、固件升级、日志全节点100ms以上不定可远程、不干扰实时数据CANWeb/维护网如果你把这张表排出来很自然地就不会选择“一条总线走到底”。EtherCAT确实快但每个从站都要ESC芯片和PHY做进掌骨和指尖这种空间紧张的位置成本和布线都是包袱CANFD便宜轻巧可在几十个高动态关节同步场景下带宽又不够而视觉点云无论如何都不能进控制总线否则一个网络风暴就可能让整机失稳。1.3 双CAN冗余到底在兜什么底我习惯把“冗余”放在最前面思考而不是最后补。人形机器人本身是不稳定系统通信断链超过几十毫秒姿态控制器就会拿到错误或者过期的反馈。一台几十公斤的机器人如果因为一条通信线松脱摔倒损失的不是一条线而是关节、外壳甚至周边设备。EtherCAT确实有环网冗余方案但代价是增加从站端口和拓扑复杂度而且无论Cable Redundancy怎么做EtherCAT域内发生物理断开的那一刻帧仍然要重传和切换存在毫秒级中断。对于关节电流环这个中断时间可能仍能接受对安全信号我不希望它和运动控制共用同一个“事故现场”。所以我在设计里把安全关键信号独立挂到双CAN/CANFD网络上。双CAN的物理层简单两路独立收发器每一路都是屏蔽双绞线一路断了另一路继续传而且总线上挂的设备是BMS、急停、安全PLC、关节超限检测这类安全节点和EtherCAT驱动域完全电气隔离。这个隔离本身就是冗余运动总线故障了安全网还知道机器人心跳还存在能执行安全停机策略反之安全网检修时也不会影响运动总线正常运行。2. 双CAN/CANFD通道的冗余机制与带宽边界2.1 用在CAN侧而不是EtherCAT侧的设备类型很多做伺服出身的人会质疑一条CAN的带宽才那么点为什么还要留给几十个节点这里要区分“设备需要的带宽”和“节点数量”。EtherCAT节点通常是伺服驱动器它们每周期要交换完整的控制字、状态字、目标位置、实际位置、力矩电流值单个节点数据量就大。而CAN侧的设备大多数是传感器和执行器中的“小角色”IMU的一次姿态解算结果可以压缩到36字节、每个脚底压力传感器用4字节、腱绳张力计报一个峰值加一个温度也就8字节、急停和电池状态更是几个bit就够。单个设备数据量不大但数量多。这些设备用CANFD还有一个隐藏好处物理层和连接器体积小、线缆轻、成本低。在手臂末端、手指关节这种需要反复弯折的位置轻量化双绞屏蔽线的弯曲疲劳寿命比粗壮工业以太网线好得多布线也灵活。2.2 双发选收与主备切换我建议选哪一种CAN冗余常见两种做法。第一种是主备切换。正常运行时只走CAN-ACAN-B空闲待命主站检测到A路总线上出现Bus-Off、错误被动或者连续收不到ACK立刻把所有报文切到B路。这种方案对总线负载影响小但是切换需要时间主站要通过错误计数或心跳超时判断链路失效再重新建立B路的发送时序收到切换指令的节点还要复位收发状态。整个过程往往需要几个毫秒到十几毫秒对安全信号可以容忍但对需要连续同步的数据不够友好。第二种是双发选收。每个CAN节点同时把同一帧报文发到A、B两条总线上接收节点对两路数据做校验和去重正常时取先到或同帧校验通过的数据某一路连续出错时自动忽略那一路实现无缝切换。代价是总线负载翻倍所以单路平均负载必须压到40%以下否则冗余反而成为不稳定来源。我在样机上用的是双发选收。理由很简单安全关键信号不允许出现“切换瞬间没有数据”的窗口期。双发选收本质是拿带宽换时间确定性而在人形机器人这种一旦摔倒损失巨大的场景里这个交换非常值得。配置上还有两个容易忽略的点。一是两条CAN总线的速率、终端电阻和线缆长度必须保持一致否则双发帧到达时刻差会超出接收缓冲设计窗口二是两边收发器必须独立供电终端电阻只在总线末端各放一个别把120欧姆电阻做到每个节点里。2.3 CANFD报文带宽的一个粗略算账CANFD相对经典CAN最大的提升在于数据段速率和单帧长度。经典CAN一帧最多8字节CANFD能到64字节数据段速率可以到5Mbps左右这就让“几十个传感器节点在5ms内完成一次全量上报”成为可能。我做一个简化估算假设总线上有30个节点每个节点每5ms上报32字节有效数据。如果每32字节打包成一帧CANFD扩展帧仲裁段用1Mbps数据段用5Mbps一帧在总线上的时间大约在110到120微秒量级具体和填充位、CRC段有关。30个节点依次上报总线占用约3.5ms在一个5ms周期里负载率已经到70%如果再加上心跳、CANWeb诊断报文单路平均负载会逼近甚至超过80%。这个结果说明了两件事一是CANFD 5Mbps也并不是无限带宽设计时单路负载率要压在50%以下才安全二是一旦采用双发选收同样的数据必须在A、B两路各发一份等效负载就要翻倍。所以30个节点每5ms上报32字节在该参数下不能全塞进一条5Mbps的CANFD双发链路需要拆分要么把周期放宽到10ms要么拆成两条CANFD冗余对要么压缩上报数据量。CANFD报文的更新率不是越高越好要根据真实传感器带宽去算我的习惯是给足余量让平均负载不超过40%这样双发后约80%总线仲裁冲突处于可控范围。关于CANFD本身还有几个细节使用FDF帧时需要开启BRS位数据段才会切到高速率不带BRS的FD帧实际只相当于放大版经典帧没有发挥速率优势。长线缆、高速率情况下如果发送节点距离接收节点太远信号回波可能导致数据段采样错误这时需要开启收发器的发送延迟补偿功能或者降低数据段速率。2.4 两条总线上的心跳与失联处理冗余CAN网络里除了业务数据还要设计心跳帧。每个安全节点按固定周期发送自己的状态心跳主站维护一个“存活表”连续两个或三个周期没收到某节点的心跳就判定该节点失联。这里有个经验值心跳周期一般设为业务数据周期的1到2倍超时阈值设为3个周期。太短容易因偶发错误误判太长又会让安全响应变慢。我在样机里把CANFD传感器业务周期设在5ms心跳2ms失联判定阈值10ms把急停类安全信号的业务周期设在5ms但心跳周期压到1ms失联判定2ms内立刻触发安全停机流程。心跳还有一个用途判断双发数据是否需要纠偏。如果A、B两路都正常接收节点对两帧数据做逐字节比较发现不一致时以A路为主并记录错误计数如果A路连续错误自动切到B路。在调试时我会把每一路CAN的错误计数、Bus-Off恢复次数都通过CANWeb上报这比事后查CANalyzer日志高效得多。3. CANWeb在管理系统里的位置让CAN总线“可被浏览器打开”3.1 通俗理解CANWebCANWeb不是替代CAN的另一种物理总线而是运行在CAN/CANFD之上的应用层协议和设备管理方案可以把它理解成“给CAN设备做的Web服务器框架”。传统CAN调试有多痛苦做过的人都知道你必须维护一张报文ID表和DBC文件每个字节代表什么全靠人工对照改了一个传感器量程所有排查工具都要跟着改。而CANWeb的思路是把每个设备、每个数据对象都抽象成类似网址或资源节点的形式通过网关把CAN报文翻译成HTTP/JSON之类的结构上位机打开网页就能看到“左肩IMU温度36.5摄氏度状态健康”这样的直观信息而不是十六进制字节流。这个定位正好补上传统CAN的短板物理层够简单可靠但应用层缺少设备模型、在线寻址和状态描述能力。CANWeb相当于给这套总线加了一层“可维护性”。3.2 冗余双CAN与CANWeb的调度共存在冗余双CAN系统里加CANWeb必须解决一个冲突CANWeb的诊断和请求报文如果太激进会抢占安全业务数据的总线时间。我把双CAN上的报文分成两类用不同优先级ID区间隔离。业务数据使用标准11位ID里的低段比如0x100到0x1FFCANWeb请求和响应放到高段0x700以上。CAN标准ID越低优先级越高所以业务数据永远能插队到管理报文前面。实际走下来这个方案比较稳。CANWeb网关在总线空闲期发起设备枚举和参数读取不会干扰固定周期上报的传感器数据。如果某段时间业务数据负载较高诊断报文会自然退避用户看到的只是网页刷新变慢不影响机器人本体运行。还有一点要强调的是CANWeb不建议直接控制关节或安全逻辑。它最适合做的是读取运行参数、设备健康状态、版本信息升级固件时也只下发到非安全节点。实时控制永远走EtherCAT和底层硬逻辑不让维护通道染指这是我一直坚持的架构边界。3.3 设备模型与参数映射表实战为了让CANWeb真正好用需要维护一张设备描述表类似CANopen里的对象字典概念。每个节点有唯一ID每个数据对象有名称、类型、单位、长度、偏移量、读写权限和报警上下限。我在样机里的做法是每个CANFD节点上电时先广播自己的设备类型和版本CANWeb网关根据设备描述文件自动生成节点树。比如足底压力节点会上报6个压力值、1个温度值网关自动形成页面关节超限监测节点上报一组布尔量和触发时刻网关直接把报警渲染成状态卡片。这套东西第一次联调时看不出来优势等到系统跑几个月、现场更换传感器或校准参数时就非常有用。不用拿CAN工具一帧一帧解析直接在网页上把对应通道的量程改掉写入后设备参数就更新了。设备失联时节点树上的状态也会直接标红定位问题从小时级缩短到分钟级。3.4 CANWeb最适合放监控而不是实时控制基于前面说的调度约束我最终把CANWeb定位成“带外管理网络”。它跑在CANFD之上通过一个独立的CANWeb网关接到千兆以太网维护口车间上位机或者远程运维平台通过网页访问。这样部署可以让调试人员在不拆机器人外壳、不接调试器的情况下完成设备枚举、参数检查、历史报警查询甚至可以批量刷新一批同型号传感器节点的固件。但因为CANWeb报文本身要等待总线空闲它的时延是不确定的所以绝对不能拿它做实时闭环。4. EtherCAT从站与主站常见坑从ESC寄存器到Wireshark4.1 选择主站方案的决策记录EtherCAT主站方案有很多常见的是这么几类主站方案上手难度实时性适合阶段PLC加自带上位软件如Easy521配AutoShop低好验证单个关节模组、小批量设备TwinCAT/CODESYS环境中很好原型机快速搭建、少量轴验证Linux IGH/SOEM自研主站高好需要调内核整机多轴、需要深度集成算法Easy521这类PLC自带EtherCAT主站用AutoShop组态后可以直接扫到关节模组配置PDO映射、对象字典都很快。我建议所有第一次接触EtherCAT的人先用PLC或者是TwinCAT把关节模组跑通确认从站的PDO、状态字和同步模式符合预期再考虑自己写主站。否则一上来就在Linux上移植IGH出了问题你根本分不清是主站的问题还是从站配置的问题。等到整机几十个轴联调时我改用Linux IGH因为我们需要把视觉状态估计、步态规划算法和EtherCAT主站跑在同一台机器上这对PLC方案来说很难灵活扩展。4.2 从站ESC、SSC工程与EEPROM信息EtherCAT从站的核心是ESC芯片常见的是LAN9252、AX58100这类。它们内部有协议状态机、SyncManager、FMMU和DPRAMMCU通过SPI或并行接口访问这些资源。很多从站硬件做出来却死活进不了OP状态问题往往不在主站而在ESC初始化。SSC是倍福提供的从站协议栈代码生成工具。生成工程时要重点确认三件事ESC的EEPROM是否烧录了正确的厂商信息、产品代码和站地址配置MCU侧的中断服务函数是否响应了ESC的同步事件PDI读写DPRAM的数据一致性是否锁好。站地址尤其容易踩坑。EtherCAT支持配置别名和动态站地址默认情况下主站会按拓扑顺序分配地址。如果多个从站的EEPROM里设置了相同的配置地址扫描阶段就会出现站地址冲突导致某一站始终切不到OP。4.3 SM/FMMU/DC这些寄存器到底挡在什么地方刚接触EtherCAT的人最容易卡在SM和FMMU。这里我用自己的理解说清楚SMSync Manager是ESC内部同步管理单元负责协调DPRAM里的数据交换。SM0/SM1通常用于邮箱通信SM2/SM3用于过程数据。每周期主站往SM2对应地址写输出数据从SM3对应地址读输入数据。FMMUFieldbus Memory Management Unit类似地址映射表它把主站逻辑数据地址映射到从站物理内存地址。多从站共用一个EtherCAT帧时每个从站的FMMU决定自己在帧里的哪一段插入或提取数据。DCDistributed Clock是分布时钟同步机制用于让所有从站的SYNC事件对齐到同一时间基准保证多轴指令同时输出。如果从站配置了DC但同步周期和主站不一致就会反复从OP掉回Safe-OP。联调时如果某从站卡在PRE-OP到SAFE-OP这一步优先检查SM2/SM3对应的起始地址、长度是否和PDO映射一致如果卡在SAFE-OP到OP优先检查DC周期、同步信号使能和看门狗配置。这些内容在SSC生成的代码中都有默认配置但每个项目改PDO后SM长度常常被忽略最容易出问题。寄存器层面可以看ESC的地址AL Control在0x0120AL Status在0x0130SM配置从0x0800开始每个SM占8个字节FMMU从0x0600开始每个占16个字节。调试早期可以直接读写这些寄存器验证状态机。4.4 单域多从的PDO布局人形机器人控制里我喜欢把绝大多数伺服轴放进同一个EtherCAT域。所谓一个域可以理解成一个EtherCAT帧里包含多个子报文依次和多个从站交换数据。这样做的最大好处是主站一个周期发一帧所有关节同步更新系统运行频率高而且逻辑简单。但PDO总长度有上限。EtherCAT标准帧最大约1500字节扣除以太网头帧头和各种子报文头能承载的有效从站数据在1480字节左右。如果每个关节需要32字节的输入和32字节的输出40个轴就是2560字节已经超过单帧限制。解决办法是拆成多个域或者使用更长的EtherCAT帧扩展。实际项目里我不会在每一个关节上塞满所有数据而是只让PDO包含控制器真正每周期需要的数据目标位置、目标速度、控制字和回读状态字、实际位置、实际速度、力矩电流值、错误代码。诊断类参数按需通过邮箱读取不放在过程数据里。这样单个轴通常能控制在24到40字节40轴左右仍能单域容纳。另外每个从站的PDO映射表需要和驱动器固件保持匹配。改驱动器端的对象字典时主站侧映射表
