企业官网建设流程全解析

1. 先说清楚这颗电机：硬件底子与通信协议设计

1.1 硬件参数与定位

第一次拿到CyberGear微电机时，我的第一反应是“这体积也太小了”。整个电机就是个方块，重量压得很低，但扭矩输出却不含糊，官方标称的工作电压范围在18V到30V之间，峰值扭矩能做到十几牛米这个量级——这对桌面机械臂、四足机器人、云台、AGV小车这类对功率密度和重量都敏感的项目来说，简直是量身定做的关节执行器。

它内部已经把无刷电机、行星减速器、绝对式编码器、驱动器、FOC电流环算法全部集成在一起，外面只留两个接口：电源口和CAN通信口。这意味着你完全不需要关心换相时序、电流采样、PID电流环这类底层东西，只需要通过CAN总线发目标位置、速度、力矩指令，它就能自己把电机转到指定角度。本质上它就是一个“智能执行器”，把最难啃的电机控制硬骨头全封装好了。

很多人拿到手第一个误区是：既然说明书上写了CAN，那拿个USB转CAN模块接上去，用串口助手发几个字节就能转起来。实际不是这么回事。CyberGear走的是CAN 2.0扩展帧，波特率默认1M，报文里每个字节的位分配都有严格定义，浮点数要做定点量化，控制字和参数要按协议拼装。如果不懂报文结构，发过去的指令十有八九是无效的，甚至会触发电机的错误保护。

1.2 为什么偏偏是CAN总线

这里先聊一个很多人问的问题：为什么小米要选CAN而不是RS485、SPI或者EtherCAT？

RS485的问题是半双工轮询、没有硬件仲裁机制。多台电机挂在同一总线上，主控必须挨个点名，实时性很难保证。假如你有6个关节，每个关节以1kHz频率刷新，轮询一圈的调度压力和总线冲突处理会让人痛不欲生。SPI的问题是通信距离短、主从关系死板，而且SPI的片选线一多，布线就成了噩梦。EtherCAT实时性确实强，但需要专门的从站控制器芯片，个人开发者用起来门槛太高，成本也不在一个量级。

CAN总线强在三点：第一，多主架构，任何节点都能主动发数据，总线仲裁由硬件完成，优先级高的帧自动抢占；第二，双线差分信号，抗干扰能力远强于单端信号，这对电机附近强电噪声环境非常重要；第三，帧结构里有CRC校验和错误帧机制，通信可靠性有保障。对机器人这种关节数量多、控制周期快、环境噪声复杂的场景，CAN几乎是性价比最优解。这也是为什么汽车电子、工业控制领域几十年了依然大量依赖CAN总线。

1.3 报文协议拆解：识别帧ID和数据段映射

CyberGear使用29位扩展帧ID，波特率默认1Mbps。帧ID的设计有一个核心思路：同时携带主机ID和电机ID。高分辨率的主机ID用来标识“谁在控制”，低8位电机ID用来标识“控制的是哪台电机”。这样一个总线上可以挂多台电机，互不冲突。主机ID可以理解为“主人的编号”，电机ID就是“每个关节的门牌号”，两者组合在一起才能把指令精确送到指定电机。

报文数据段固定8字节，前两个字节通常是控制字，高字节和低字节各占一个字节。控制字决定了这条报文是干什么用的，比如使能电机、失能电机、停止电机、还是设置控制模式。后面六个字节则根据不同的控制模式填入不同的数据。

以最常用的位置控制为例，需要把目标位置、目标速度、Kp、Kd、输出力矩这五个量打包到六个字节里。问题来了：这些量原始是浮点数，但CAN报文只能传整数，所以必须做量化转换。CyberGear的协议里每个量都有自己的物理范围，比如位置范围是-12.5到12.5圈、速度范围是-30到30转/秒、Kp范围是0到500、Kd范围是0到5、力矩范围是-12到12。你需要先把浮点数值映射到对应的整数区间，再按位拆分填到数据段里。

我整理过一份映射关系，写代码时直接照着用：

这里有一个细节经常坑人：所有数据都是小端序，也就是低字节在前。如果你按大端序拼包，电机收到的数值就是乱的，表现出来就是明明发了位置指令，电机却以离谱的速度猛冲或者完全不动。我的建议是，驱动代码里不要手写位操作，直接封装一个结构体，用memcpy处理，省得每次发指令都要小心翼翼数位。

2. 开源驱动代码：工程结构、移植步骤与核心API

2.1 开源仓库里到底有什么

现在大部分能找到的CyberGear驱动开源项目，目录结构不会有太大出入。核心部分分三层：底层CAN硬件抽象层、协议封装层、应用示例层。

底层CAN硬件抽象层是最关键的，它把具体芯片的CAN外设操作全部封装成统一接口，一般会提供几个函数：CAN外设初始化、发送一帧数据、接收一帧回调注册、错误处理回调。这部分和硬件强相关，如果你用的是STM32系列，驱动里通常直接给的是HAL库版本，把GPIO、CAN外设、中断配置都写在里面。如果是其他MCU，就需要自己按照接口定义重写这几个函数。

协议封装层是通用的，不依赖具体硬件。它负责把位置、速度、力矩这些物理量打包成符合CyberGear协议格式的8字节数据，也负责把电机返回的状态帧解析成人能看懂的物理量。这一层是精髓，算法在哪都通用，也是你最需要研读的部分。

应用示例层则提供了一套可直接运行的控制逻辑，比如初始化流程、使能流程、发送位置指令、读取编码器反馈。有些项目还会附带简单的上位机配套脚本，通过串口把控制指令转发到CAN总线上。

2.2 把驱动搬进自己的工程

移植驱动的时候，我建议按下面四步走，每一步都验证通过了再进行下一步。

第一步，拷贝驱动文件，只改底层接口。以STM32为例，你先把整个Driver目录拖进自己的工程，然后找到底层实现文件，把里面的CAN句柄替换成你自己在CubeMX里初始化好的句柄。如果CubeMX已经帮你生成了CAN初始化和GPIO配置，底层文件里对应的MX_CAN1_Init函数可以直接删掉，只保留驱动自己需要的节拍函数和发送函数。

第二步，配置CAN滤波器。这里要注意，驱动不是想收什么就收什么，必须在CAN外设的过滤器里设置好ID匹配规则。最简单的做法是设置成掩码模式，只接收电机ID对应那一帧或者那个范围的帧。如果不做过滤，总线上所有报文都会进接收中断，一旦总线上有多个ID的设备，你的接收回调里就要做一层ID判断，浪费CPU不说，还容易漏帧。

第三步，实现发送和接收回调。发送回调通常不需要你做什么，HAL库的发送函数本来就是非阻塞的，调用后等待发送完成即可。接收回调是重点，你需要在中断里调用驱动协议解析函数，传入收到的8字节数据和帧ID，然后再清掉接收标志。这里我强烈建议：中断里只做数据拷贝，不要做浮点解析，因为浮点运算在中段里不仅慢，还容易打断其他任务。把原始字节放进环形缓冲区，等主循环或者空闲中断再去解析，系统稳定性会好很多。

第四步，跑通回环测试。初始化完成后，先发一条查询状态的命令，看电机有没有正常返回。如果返回帧的ID和数据和你预期一致，说明底层通信已经通了，再进入控制逻辑调试。

2.3 核心代码示例：从浮点数到CAN报文的封装

直接看代码会更清楚。下面这个函数是从MIT控制模式报文格式演化来的，也是CyberGear驱动里最常见的一种打包方式：

typedef struct { uint16_t control_word; float position; float velocity; float kp; float kd; float torque; } MotorCmd; uint32_t float_to_uint(float x, float x_min, float x_max, int bits) { float span = x_max - x_min; if (x < x_min) x = x_min; if (x > x_max) x = x_max; return (uint32_t)((x - x_min) / span * ((1 << bits) - 1)); } float uint_to_float(uint32_t x_int, float x_min, float x_max, int bits) { float span = x_max - x_min; return (float)(x_int * span / ((1 << bits) - 1) + x_min); } void motor_send_cmd(CAN_HandleTypeDef *hcan, uint32_t motor_id, MotorCmd *cmd) { uint8_t data[8]; uint32_t pos_int, vel_int, kp_int, kd_int, tor_int; pos_int = float_to_uint(cmd->position, POS_MIN, POS_MAX, 16); vel_int = float_to_uint(cmd->velocity, VEL_MIN, VEL_MAX, 12); kp_int = float_to_uint(cmd->kp, KP_MIN, KP_MAX, 12); kd_int = float_to_uint(cmd->kd, KD_MIN, KD_MAX, 12); tor_int = float_to_uint(cmd->torque, TOR_MIN, TOR_MAX, 12); data[0] = cmd->control_word & 0xFF; data[1] = (cmd->control_word >> 8) & 0xFF; data[2] = (pos_int >> 8) & 0xFF; data[3] = pos_int & 0xFF; data[4] = (vel_int >> 4) & 0xFF; data[5] = ((vel_int & 0x0F) << 4) | ((kp_int >> 8) & 0x0F); data[6] = kp_int & 0xFF; data[7] = (kd_int << 4) | tor_int; uint32_t frame_id = (MASTER_ID << 8) | motor_id; CAN_TxHeaderTypeDef tx_header; tx_header.ExtId = frame_id; tx_header.IDE = CAN_ID_EXT; tx_header.RTR = CAN_RTR_DATA; tx_header.DLC = 8; HAL_CAN_AddTxMessage(hcan, &tx_header, data, &tx_mailbox); }

注意data[4]到data[7]这四个字节，它们是几个12位和16位数据交叉拼在一起的，稍微不注意就会拼错位。我的经验是先写一个单元测试函数，分别把pos_int、vel_int这些中间变量打印出来，再对照协议文档里的位宽分配，确认拼接逻辑正确后再烧进板子。直接用串口助手抓CAN报文，数一下每一位，基本不会错。

3. 中断接收还是DMA接收？我做了完整对比

3.1 两种接收方式的本质差异

这个问题是嵌入式社区里老生常谈的话题，但在CyberGear这种具体场景下有它自己的答案。中断接收是每来一帧CAN报文，CAN外设就拉一个中断给CPU，CPU暂停当前工作，去把数据从接收FIFO搬到内存，然后退出中断。DMA接收则是CAN外设收到数据后，由DMA控制器自动把数据搬到内存缓冲区，搬运完成后才触发一次中断通知CPU。

从机制上看，DMA似乎更高级，因为它可以大幅减少CPU的中断开销。但实际使用中，DMA接收CAN报文有一个绕不开的问题：你需要管理DMA的缓冲区、处理半满和全满中断、还要防止数据覆盖。如果是双缓冲区循环模式，缓冲区满和半满时都要搬运数据，逻辑复杂度比中断接收高出一大截。对于很多只跑一个简单控制循环的机器人项目来说，这种复杂度带来的收益非常有限。

3.2 CyberGear场景下的实测数据

我在一个基于STM32F407的项目上实测过。CyberGear反馈帧率通常是1kHz，也就是每毫秒一帧，一帧8字节。用中断接收，CAN接收中断触发频率是1kHz，中断服务程序里只做拷贝，拷贝8字节到环形缓冲区，大概耗时几十微秒以内。对比主循环里跑的位置环控制，1kHz的控制周期占用CPU比例大概在3%到5%，根本没压力。

DMA接收在这个场景下有点“杀鸡用牛刀”的感觉。只有当你的总线上挂了很多设备，比如十几个电机，每毫秒有几十帧数据涌入，或者主控CPU还要同时跑视觉算法、通信协议栈等高负载任务时，DMA才能体现出它的优势。如果你只是调一个关节两个关节，老老实实用中断接收就行。

给你一个判断准则：先算出CAN中断每秒触发次数，也就是总线上每秒的帧数。如果这个数字除以CPU主频，占比低于0.5%，中断接收完全够用。比如1M波特率、1kHz反馈，每秒1000帧，CPU主频72MHz，占比只有0.0014%，哪怕中断处理占个几十微秒，对系统也没影响。

3.3 中断处理的配置要点

用中断接收时，有几个配置细节特别关键。第一，接收FIFO选择哪个，CAN1和CAN2都有两个FIFO，一般都只用FIFO0，配置好CAN_RX_FIFO0_MSG_PENDING中断源即可。第二，中断优先级要给够，但不要太高。CAN接收中断必须能打断主循环里的控制任务，否则在主循环长时间占用CPU时，CAN接收缓存会被新帧覆盖导致丢帧，所以优先级至少要比普通定时器中断高。但也没必要给成最高优先级，因为控制循环本身也很实时。

第三，中断函数里别做解析。我在早期版本里犯过这个错误，直接在CAN接收中断里调用协议解析函数做float转换，结果一个中断动不动处理上百微秒，偶尔还被其他高优先级中断打断，导致解析到一半的数据被污染，最终表现为电机偶发抽动。后来改成中断里塞环形队列、主循环里解析，问题彻底消失。

4. 总线上为什么出现错误帧：一次完整排查链路记录

4.1 错误帧是怎么产生的

CAN总线协议设计了一个非常强悍的错误检测机制：位错误、填充错误、CRC错误、格式错误、ACK错误。任何节点在发送或接收过程中发现错误，都会立刻发出错误帧，把当前这一轮通信打断，然后重新调度。这个机制保证了总线的高可靠性，但也带来一个麻烦：一旦总线上某处存在隐患，错误帧满天飞，整个通信会反复重传，总线利用率急剧下降，控制周期直接崩掉。

常见错误帧来源有几个：波特率不一致导致位错误、终端电阻缺失导致信号反射、CANH和CANL接线反了导致电平异常、地电位差太大导致共模电压超标、或者某个节点的收发器坏了一半。其中终端电阻缺失是最容易被忽视的——两端的120欧姆终端电阻是必须的，缺一个就会让差分信号波形产生振铃，在高速率下直接导致位错误。

4.2 物理层排查：从万用表到示波器

我遇到过一次很奇怪的现象：电机在低速转动时一切正常，转速一拉高就开始随机卡顿，导通率指数上升。一开始怀疑是软件控制周期抖动，排查了整整两天，最终在示波器上一看，CAN差分信号波形的上升沿有明显振铃，过冲接近2V。而总线上只接了一个终端电阻——我偷懒只在一个节点上接了120欧姆，在1M波特率下长线缆的分布电容和电感就把信号搞坏了。解决方案简单粗暴，在总线另一端也接上120欧姆，振铃立刻消失。

所以排查错误帧的第一步永远是物理层。拿万用表测一下CANH和CANL之间的电阻，正常应该在60欧姆左右，因为两端各120欧姆并联。如果测出来是120欧姆，说明有一端没接终端电阻；如果测出来接近0欧姆，说明有短路或者哪里接线有问题。再量一下CANH和CANL对地电压，正常隐性电平应该在2.5V附近，显性电平CANH约3.5V、CANL约1.5V。数值偏差大，优先查供电地线和共地问题。

如果手头有示波器，直接测CANH和CANL的差分波形，看上升沿和下降沿是否干净。有振铃、出现过冲、或者电平摆幅明显不足，都是物理层问题。别急着怀疑软件，CAN总线的错误帧百分之七八十是物理层引起的。

4.3 协议层排查：波特率、采样点和ID冲突

物理层没问题的情况下，下一步查协议层。

波特率不匹配是最典型的。1M波特率下，位时间只有1微秒，发送节点和接收节点如果对位时间宽度的定义有微小差异，累计到一帧还没发完就会产生位错误。注意这里不仅是波特率数值要一样，采样点位置最好也一致。常用配置是采样点在75%到80%之间。如果你用STM32的HAL库，CAN_InitTypeDef里的TimeSeg1和TimeSeg2配置会直接影响采样点。比如我用APB1外设时钟42MHz，设置Prescaler=42，BS1=13，BS2=2，采样点就在(1+13)/(1+13+2)=87.5%，这个值在1M下表现很不错。

ID冲突同样会引发错误。如果总线上有两个节点配置了同一个CAN ID，它们同时发送时就会触发位错误，因为一个发显性一个发隐性，总线电平不对。在CyberGear的场景里，你要确认每个电机的ID是否通过拨码或者上位机软件真的设置了不同值，别相信出厂默认都是同一个。

4.4 用寄存器指标快速定位

大多数MCU的CAN外设都会提供错误状态寄存器，比如STM32的CAN1->ESR。这个寄存器里有两个关键计数器：TEC（发送错误计数）和REC（接收错误计数），还有CAN_ESR_EWG、CAN_ESR_EPV、CAN_ESR_BOF这几个状态位。如果REC持续增长，说明你的节点一直在收到垃圾数据，基本可以断定总线上有节点波特率不匹配。如果TEC持续增长，说明你的节点发送没人正确接收，要么是终端电阻的问题，要么是另一端根本没配置好。

我习惯在驱动初始化后加一个后台监控任务，定时读取ESR，把错误计数值和总线状态通过串口打印出来。这样即使电机暂时运行正常，也能提前发现总线隐患。比如某个节点偶发故障可能导致REC缓慢增加，虽然还没到主动报错的阈值，但趋势已经出来了，提前干预能省很多事。

5. 调参整定：位置、速度、力矩三层控制的实践路径

5.1 控制模式选择的顺序

CyberGear内部集成了完整的三环控制，最外层的位置环接收目标位置，中层速度环接收目标速度，最内层力矩环接收目标电流（也就是力矩）。开发者通过协议参数决定让电机工作在哪个层级。

我的建议是：拿到电机先不要直接上位置模式。先发一个很小的力矩指令，确认电机能转、方向正确、力矩反馈正常。这一步可以验证你的报文打包和解析是否真的通了，因为力矩控制只涉及一个参数，出错容易定位。然后切到速度模式，发一个固定的转速目标比如1转/秒，观察电机匀速转动是否平稳。确认速度环也OK之后，再上位置模式——这是最复杂的，因为要同时调Kp和Kd。

5.2 Kp和Kd怎么整定

CyberGear的Kp和Kd不是传统意义上控制卡上的PID增益，而是直接在内部位置环上做刚度（Kp）和阻尼（Kd）调节的参数。Kp决定电机抵抗位置偏差的力度，Kd决定它对速度变化的抑制作用。Kp太小电机软绵绵，受到外力就偏；Kp太大会出现高频抖动和啸叫。Kd的作用是给这个刚性加阻尼，防止超调和振荡。

我总结了一套可复制的整定路径。把电机悬空不带负载，先把Kd设成0.1，Kp从0慢慢往上加。每加一次，用手指轻轻拨动电机输出轴，感受它的抵抗感。当阻力已经从“轻飘飘”变成“很硬”且没有明显抖动的点，就是空载基础Kp。然后再慢慢加Kd，同样拨动输出轴，看它回正过程中是否还有来回摆动的欠阻尼表现。Kd加到回正干脆利落、没有超调，就完成了一轮基本整定。带负载之后你会发现需要的Kp比空载时大不少，这一步只能在真实负载工况下重新调。

调参过程中最容易犯的错是一次加太大。我有一次直接把Kp从10跳到100，电机当场开始高频尖叫，输出轴瑟瑟发抖，看起来像接触不良，其实是增益过大导致的极限环振荡。好在CyberGear有内部电流和位置保护，不然齿轮箱可能已经受伤了。规范做法是每次把目标值乘以1.3到1.5倍，观察一小段时间再继续加。

5.3 指令平滑：别把位置目标直接甩给电机

位置控制最忌讳的是直接把一个跳变的目标位置发给电机。假如当前位置在0度，你直接发90度，位置误差瞬间拉满，驱动器会全力输出，电流过冲，速度瞬间飙起来，轻则触发过流保护，重则撞上机械限位把机构打坏。

正确的做法是把轨迹规划和平滑滤波放在主控端。最简单的实现是斜坡发生器：每毫秒把当前目标位置朝最终目标位置移动一个最大步长。比如最大角速度限制为5转/秒，控制周期1kHz，那么每一步最多移动5/1000=0.005转。这样电机永远处于可控状态，不会出现暴力跃迁。

另一种更平滑的方式是对位置目标做低通滤波，但低通滤波会引入相位滞后，在需要高动态响应的场合反而不好调。我实际项目里用得最多的是梯形速度规划：加速段、匀速段、减速段三段式，按最大速度和最大加速度约束计算每一时刻的目标位置。代码实现不复杂，效果却比斜坡发生器好得多，关键还能精确控制到位时间。

我给CyberGear项目写过一个简单的位置斜坡函数，直接在主循环里调用：

float position_ramp(float current_cmd, float target_pos, float max_step) { float diff = target_pos - current_cmd; if (diff > max_step) return current_cmd + max_step; if (diff < -max_step) return current_cmd - max_step; return target_pos; }

配合1kHz控制周期，把max_step设成0.005圈，电机的运动就很柔和。当然，如果你的项目需要极限高速响应，可以跳过平滑，直接发目标位置，但要确保机械结构能承受瞬时冲击。

6. 踩坑实录：从转不起来到稳定运行

6.1 上电瞬间电机会自己转一下

这是CyberGear一个很有意思的行为：第一次上电使能后，如果你设定了位置模式但没有发送明确的目标位置，它会维持开机瞬间的编码器位置。但有些固件版本在使能瞬间会先回零或者自动锁定到某个预设角度，于是你就看到电机“咔”地自己转了一下，幅度不大但对某些精密机械结构来说很吓人。

解决方案是在上电初始化流程里，第一时间发送停止指令（控制字0x04），让电机进入待机，不要让它进入任何闭环控制。然后再依次配置模式、设置目标为当前位置、最后才使能。换句话说，使能必须放在所有参数设定完成之后，而不是开机第一件事。

6.2 一个电机转另一个不动，ID配置打架

我在四轴云台上挂四台CyberGear时遇到一个诡异问题：电机A和电机B，发送指令时A正常动，B完全没反应。排查过程走了一大圈，最后发现是主机ID配错了。

事情是这样的：我复制的驱动配置里所有电机都用的同一个主机ID，报文帧ID的高字节也一样，按理说没问题。但某个电机被我之前手动改过主机ID，导致它只响应新主机ID的报文，而我在应用层配置里写的还是原主机ID。所以A电机的报文能匹配上，B电机的报文因为主机ID不匹配被协议栈直接丢弃了。这种错位在调试多机时特别隐蔽，因为不是物理故障，纯靠肉眼看配置很难发现。建议在调多机前，逐个电机发送查询ID指令，确认每个电机当前的主机ID和电机ID，写成表格再开始配网。

6.3 运行中偶发抖动，终端电阻的锅

前面提过终端电阻缺失会导致振铃，但它还有一个更隐蔽的表现：不是完全不通，而是偶发抖动。当你只在一端接终端电阻时，总线信号反射只在特定频率和线缆长度组合下才引发问题。低速运行时可能完全没有感知，但电机高速换向时反射叠加到显性位，就会产生偶发位错误，进而触发仲裁失败和重传。控制环收到的反馈帧延迟了几个毫秒，表现就是电机偶发卡顿和异响。

排查方法很简单：用示波器看CAN_H和CAN_L之间的波形，在总线空闲时刻是否存在额外的振铃。如果波形上有一条“毛刺尾巴”，别犹豫，另一端补上120欧姆终端电阻。

6.4 软限位一定要写在应用层

CyberGear内部有机械限位保护，但如果你一直在接近限位的区域来回运动，机械限位撞击次数多了照样会伤到减速器和端盖。我建议在应用层加软限位：每次发送位置指令前，检查目标位置是否在允许范围内，同时实时监控编码器返回的位置，一旦越过软限位边界，立即发停止指令并把状态置为错误。

这个逻辑不复杂，但很多开发者会忘。直到有一次机械臂撞到自己的支架，听到清脆的“咔”一声，才发现硬限位已经挡不住冲击力。从那以后，我的所有关节控制代码里，软限位检查优先级永远排在控制指令下发之前。

7. 总线负载率计算与多机扩展策略

7.1 扩展帧到底占多少总线时间

多台CyberGear挂在一个总线上时，负载率就不是一个可有可无的问题了。CAN 2.0A标准帧11位ID，一帧至少需要约108位时间；而CyberGear用的扩展帧29位ID，数据段8字节时，一帧总位数大约在150位左右。具体构成是：SOF 1位、仲裁场32位（29位ID加SRR、IDE、RTR各1位）、控制场6位、数据场最大64位、CRC场16位、ACK场2位、EOF 7位、IFS 3位，加在一起约130位。数据8字节时64位，总位数为SOF1+仲裁32+控制6+数据64+CRC16+ACK2+EOF7+IFS3=131位。不同资料对CRC尾部的处理略有差异，但基本在130到150位这个区间。

在1M波特率下，1位占1微秒，所以一帧扩展数据帧大约占130到150微秒的总线时间。负载率计算公式是：

负载率 = (总线总帧数 × 每帧位时间) / 波特率

举个例子：一台CyberGear，主控以1kHz频率发送控制指令，电机以1kHz频率反馈状态，一收一发一共2kHz，也就是每秒2000帧。每帧按150微秒算，每秒占用总线时间就是2000 × 150微秒 = 300毫秒。1秒钟总线总时间是1000毫秒，所以单台电机占用约30%的负载率。

这个数值比很多人直觉高很多。如果你挂6台电机，每台都是1kHz控制和反馈，负载率直接接近180%，总线早就瘫了。所以多机场景必须做取舍。

7.2 多机组网的实际调度策略

面对多电机，我的做法是降低反馈频率。控制指令的发送频率可以保持1kHz，但反馈数据不需要每毫秒都收。CyberGear的反馈帧可以通过查询指令主动获取，不需要持续上报。我通常让主控每5毫秒查询一次各电机的状态，也就是反馈频率降到200Hz。这样单台电机的负载率就从30%降到了2000×150微秒 + 200×150微秒 = 33%左右。挂3台电机，负载率在100%边缘，刚好卡住。如果超过3台，我会再把控制频率降到500Hz，给总线留足余量。

这个调度策略可以通过错开查询时间实现。比如有4台电机，每隔1毫秒查询一台，轮询周期4毫秒，每台反馈频率250Hz。控制指令仍然按1kHz各自独立发送，但因为CAN总线的硬件仲裁机制，只要总负载率低于90%，报文的优先级和时序由硬件自动处理，基本不会有问题。

7.3 开源地址获取与项目选择建议

关于开源代码，GitHub上直接搜索“CyberGear”或者“CyberGear CAN”就能翻到不少仓库。挑选开源项目时我的建议是看三点：最近提交时间、issue数量和license声明。优先选近期还在活跃维护的仓库，不要选那种两年前就停更的老项目，因为CyberGear的固件版本可能有变化，老驱动的协议解析字段不一定兼容新固件。还要看README里有没有附带协议文档和接线说明，这类项目通常更靠谱。Gitee上也有镜像，搜“CyberGear驱动”能看到一些针对国内开发者适配的版本，有的还直接带了Keil工程和STM32CubeMX配置文件，拿来即用。

我个人在实际使用中的一个体会是：先跑通官方示例或者热门的开源示例，确认通信链路正常，再基于协议文档自己重写一版精简驱动。这样既能把原理吃透，又能避免直接套用他人代码时遇到莫名其妙的问题。很多时候电机不动，不是硬件坏了，而是你的报文里某个位没对齐、某个控制字没配对，一旦你自己写完那层协议封装，很多问题自然就消失了。