通信与总线：康复机械臂控制链路搭建经验

在 KineWeave 康复机械臂中期检查前的系统调试阶段，通信与总线问题逐渐从“设备能不能连上”转向“能否支撑高频、同步且稳定的控制”。项目早期使用 CAN 快速完成了 Demo，随着电机、六维力传感器和力矩传感器对控制频率与同步性的要求提高，通信架构逐步转向 EtherCAT。

这次调整并不只是更换一种通信协议，还涉及主站环境编译、非标网口做线、设备时钟同步以及定制力矩传感器的接口适配。把这些环节放在同一条链路上理解，才能看清通信系统为什么会成为控制效果的基础。

通信架构随控制需求升级

CAN 最初被选用，是因为它相对简单，项目周期又比较紧，需要先完成一版可运行的 Demo。随着系统进入高频控制和多设备协同阶段，CAN 的带宽逐渐成为限制因素，难以同时满足多路传感器和 1 kHz 级控制的需要。

经过调研，项目在整体重构节点确定采用 EtherCAT。这个时机很重要：当系统本身已经需要调整时，直接按照后续开发需求重构通信架构，比继续在原有 CAN 方案上叠加补丁更合适。

flowchart TD
    A[临时 Demo<br/>CAN 简单易用] --> B[多设备与高频控制需求增加]
    B --> C[带宽和同步能力成为限制]
    C --> D[整体重构节点调研 EtherCAT]
    D --> E[搭建 EtherCAT 主站与设备链路]
    E --> F[实时环境编译]
    E --> G[非标网口做线]
    E --> H[设备统一时钟]
    E --> I[CAN FD 转 EtherCAT 接入力矩传感器]

维度	CAN	EtherCAT
项目阶段	临时 Demo、快速验证	系统重构和长期开发
主要特点	简单、上手快	工业级通信，适合高频同步控制
主要边界	带宽有限，多设备高频运行时容易受限	链路搭建和实时环境配置更复杂
本项目中的作用	快速验证早期方案	承载电机、力传感器和控制链路

这次选型带来的经验是：通信协议不应脱离项目阶段和控制目标单独评价。CAN 适合快速起步，但当系统需要更高频率、更强同步性和更多设备协同时，就需要重新审视通信架构是否仍有足够余量。

EtherCAT 链路搭建中的几个关键环节

EtherCAT 并不是接上网线就能直接运行。实际搭建过程中，软件环境、物理连接和设备同步需要同时满足条件，任何一环不匹配，都可能影响最终控制效果。

实时通信环境的编译验证

电机对同步精度有较高要求，默认系统中的网卡和通信环境不能直接满足高精度实时控制的需要。因此，项目结合实际工控机环境完成了实时通信相关的网卡驱动与 EtherCAT 主站环境编译，并对接口层进行了验证。

在 KineWeave 的软件验证中，IgH 环境构建和链接检查已经通过，89 项硬件接口测试也完成了验证。但这类结果的边界需要明确：编译通过和接口测试通过，只能说明软件环境和接口层基本成立，并不等同于已经在真实电机和总线上完成运行验证。没有加载真实内核模块、没有接入实际总线之前，仍然不能把它当作真机可用的结论。

非标网口与线缆选择

电机侧的 EtherCAT 网口采用了非标准的四线连接方式，而工控机侧通常使用标准八芯 RJ45 接口，因此需要通过自制端子和转接线完成连接。端子选型没有完全照搬厂家提供的特化端子，而是根据线型和压接条件选择了更通用的 1 mm 间距端子。

线材经历了两个阶段。第一版使用多股线直接连接，能够完成通信，并达到约 500 Hz 的运行频率。但当目标提升到 1000 Hz，且通信线与 24 V 电源线存在缠绕时，线材的抗干扰能力和长期稳定性就不能只用“能不能通信”来判断。

因此，后续更换为带屏蔽层的四芯线。屏蔽层并不是为了改变协议本身，而是为了降低高频通信和电源线相互缠绕时的干扰风险。由此形成的经验是：在高频场景中，线缆选择要同时考虑导线数量、端子匹配、屏蔽方式、布线关系和目标频率，第一版“能用”的连接方式不一定适合长期稳定运行。

设备统一时钟

电机和六维力传感器的采集器都支持 EtherCAT。为了让不同设备的采样和控制数据处在同一个时间基准下，项目将电机与六维力采集器串接到同一条 EtherCAT 总线上，使设备能够在总线内部完成时钟同步，并支撑 1 kHz 级的协同控制。

这里的重点不是简单地把设备接到同一根线上，而是让数据具有共同的时间基准。对于需要同时参考位置、速度和力信息的机械臂控制来说，时钟同步是后续数据融合和控制响应成立的前提。

定制力矩传感器的接口适配

力矩传感器属于偏定制化的部件，电路设计和校准通常依赖厂家完成。重新定制可以获得更匹配的接口，但会带来较长的沟通和交付周期；直接使用现有传感器，则会受到原有通信接口和带宽的约束。

当前力矩传感器只支持 CAN。若将 7 个力矩传感器直接串接在 CAN 链路上，带宽不足以支撑 1000 Hz 级的采样频率。因此，项目没有重新等待一套传感器定制，而是采用 CAN FD 转 EtherCAT 转接板进行接口适配。

flowchart LR
    M[工控机<br/>EtherCAT 主站] --> E[EtherCAT 总线<br/>统一时钟]
    E --> J[关节电机]
    E --> F[六维力采集器]
    E --> B[CAN FD 转 EtherCAT 转接板]
    B --> T[7 个力矩传感器<br/>CAN / CAN FD 链路]

转接板提供三路 CAN FD 接口，通过编写固件，将下层兼容 CAN 协议的传感器数据以更合适的速率转换为 EtherCAT 数据，再接入前面的电机和六维力通信链路。这样既保留了现有定制传感器，又把它们纳入统一的 EtherCAT 时钟体系，是在交付周期、接口条件和控制需求之间做出的工程折中。

接入完成后，电机、六维力传感器和力矩传感器转接板都可以挂在同一个 EtherCAT 时钟下，整条总线的带宽实际只使用了不到 10%。这说明当前通信架构的主要限制并不在 EtherCAT 本身，而更集中在力矩传感器及其下层 CAN 链路的接口能力上。

通信调试形成的判断

这次链路搭建形成了几条可以迁移到其他项目的经验：

调试现象	形成的认识	对应经验
CAN 可以完成早期 Demo，但难以支撑多设备高频控制	通信方案的适用性取决于当前阶段和控制目标	先满足验证速度，再根据系统需求进行架构升级
EtherCAT 编译和接口测试通过	软件环境成立不代表真实总线运行成立	明确区分编译验证、接口验证和真机验证
多股线在 500 Hz 下可以通信	“能用”和“稳定”是不同标准	高频通信需要结合屏蔽、布线和电源干扰评估线材
电机和六维力需要同时参与控制	数据同步不只是带宽问题，也是时间基准问题	多设备协同时优先考虑统一时钟
力矩传感器接口定制周期长且带宽受限	设备接口不匹配时，可以增加中间适配层	用转接板和固件完成协议转换，降低整体改造成本
EtherCAT 总线实际负载不到 10%	总线能力仍有较大余量	评估通信架构时要同时关注当前负载和可扩展空间

小结

康复机械臂的通信系统不是单独服务于某个设备，而是连接电机、力传感器、力矩传感器和控制算法的共同基础。CAN 让项目快速完成了早期 Demo，EtherCAT 则在系统进入高频控制和多设备协同后，提供了更大的带宽和统一的时间基准。

这段经验最终沉淀为一个比较稳定的判断顺序：先根据控制目标和项目阶段选择通信架构，再验证实时环境和物理链路，接着确认多设备之间的时钟关系，最后检查定制设备是否需要通过适配层接入。只有把协议、线缆、同步和设备接口放在同一条链路中观察，通信问题才不会被误判成单纯的电机或控制算法问题。