wavefinder 的奇妙冒险 Zephyr / 嵌入式 Linux · 机器人 · 边缘计算

遥操作主臂双链路通信实时性实践：UART 2M + CAN 1M 达妙七轴 500 Hz

一、结论

链路 角色 介质 / 速率 节拍
关节侧 MCU ↔ 7×达妙电机 CAN 1 Mbps，标准帧 MIT 每周期逐轴问询
上层 MCU ↔ 上位机 UART 2 Mbps，多轴 MIT 打包帧 与关节侧同频
整机对齐 控制 / 反馈 应用层统一节拍 500 Hz（2 ms）

一句话： 实时性不靠「所有层都拉到 1 kHz」，而靠 关节 CAN 与上层 UART 共用同一 2 ms 节拍；瓶颈在 CAN 1M 的七轴问询，不在 UART，也不在 MCU 主频本身。

二、系统怎么分层

┌─────────────────┐     UART 2 Mbps      ┌──────────────────┐
│  上位机 / Orin   │ ◄──────────────────► │   先楫 MCU        │
│  多轴 MIT 打包   │   一帧含 7 轴控制/反馈 │  汇聚 · 定周期    │
└─────────────────┘                      └────────┬─────────┘
                                                  │ CAN 1 Mbps
                         ┌────────────────────────┼────────────────────────┐
                         ▼                        ▼                        ▼
                    达妙轴1                   达妙轴2 …                达妙轴7
                  （MIT 控制帧）            （问询触发反馈）         （状态帧回传）

2.1 为什么要两段链路

  • 关节侧要对接电机厂协议：达妙默认 CAN 1M、8 字节 MIT，反馈多为问询式（发命令帧 → 电机回状态帧）。
  • 上层要稳定、少抖动的「整臂视角」：不适合把 14 路 CAN 帧直接暴露给 Linux/ROS；由 MCU 收齐再打包，上位机每拍只处理一帧多轴 MIT。

两段各干各的：CAN 保证电机交互；UART 保证整臂接口简洁。

2.2 一周期里 MCU 做什么

典型 2 ms 内顺序大致是：

  1. 按轴发送达妙 MIT 控制帧（CAN ID = 电机 ID）
  2. 接收对应反馈帧（位置 / 速度 / 力矩 / 温度等）
  3. 组装上层协议的多轴控制或反馈载荷
  4. 经 UART 与上位机完成该拍的收发

信令类事务（设频、清错、查丢包等）若插入，会占用该拍的定频槽位，需在协议里约定优先级，避免和 MIT 定频帧抢同一周期。

三、达妙电机侧：CAN 1M

3.1 协议特征（与实时性相关的部分）

  • 波特率：1 Mbps（可配，工程常用默认 1M）
  • 帧格式：标准 CAN，数据域 固定 8 字节
  • MIT 控制：位置 / 速度 / Kp / Kd / 前馈力矩等位域打包进 8 字节
  • 反馈：收到匹配 CAN ID 的控制帧后，回传状态帧（问询式）

因此 7 轴、双向问询 时，一拍在总线上大约是：

7（命令）+ 7（反馈）= 14 帧

3.2 带宽粗算

经典 CAN、8 字节数据帧，单帧占用大约 0.11～0.13 ms 量级（含仲裁与开销；最坏填充会再差一点）。

估算 14 帧占用 相对 2 ms（500 Hz）
偏乐观 ~0.11 ms/帧 ~1.5 ms 仍有余量
常用 ~0.12 ms/帧 ~1.7 ms 紧，但可工程化
偏悲观 ~0.15 ms/帧 ~2.1 ms 理论上贴边或溢出

工程含义：

  • 500 Hz：与「7 轴单总线达妙问询」是匹配的甜点区——紧，但留得出 MCU 打包和 UART 上报的缝。
  • 1 kHz（1 ms）：同样约 1.7 ms 的总线活，在单路 CAN 1M、七轴全问询下往往装不下；要上更高带宽（如 CAN-FD）、拆总线或减每拍交互量。

所以 500 Hz 不是「随便选的数字」，而是 电机协议形态 + 轴数 + 波特率 共同约束下的结果。

四、上层 UART 2M

上位机与 MCU 之间用专用帧：

  • 物理：TTL UART，工程实现波特率 2 Mbps
  • 定频：多轴 MIT 控制帧 / 反馈帧 按同一 feedback_rate 对齐
  • 设频范围在协议层可到 10～500 Hz，工程配置取 500

载荷量级：单轴控制约十余字节、反馈约十余字节，7 轴打进一帧后，即便加上帧头与校验，双向合计也只在 数百 kbps 量级，相对 2 Mbps 很宽裕。

因此：

  • UART 负责 整臂接口与节拍对齐
  • 实时性压力主要落在 CAN 侧 14 帧/拍，而不是串口打不满

实现上注意：主机侧发送周期与 MCU 反馈周期一致；一拍内信令与定频 MIT 互斥，避免同拍叠帧导致节拍漂移。

五、500 Hz 对齐

容易混淆的三个「频率」：

名称 含义 本方案取值
电机总线交互 CAN 上完成 7 轴问询的闭环 落在 2 ms 窗内
MCU↔上位机 UART 定频 MIT 打包 500 Hz
上层控制线程 订阅状态、算命令、再下发 与上同频对齐

原则：

  1. 同频：控制下发与状态上报同一节拍，减少排队与相位差。
  2. 定周期：MCU 用定时器硬节拍驱动 CAN 轮询，避免「主循环跑多快算多快」。
  3. 超时与保护：达妙侧有通信丢失保护；上层协议可查丢包；丢一拍不应拖垮后续拍。
  4. 观测：除了「配置写成 500」，还要看周期抖动、总线负载感、丢包率——实时性以实测为准。

六、先楫 MCU

在这种架构里，MCU 不是「简单透传」，而是实时边界上的 汇聚与隔离：

职责 说明
协议适配 达妙 CAN MIT ↔ 上层多轴 MIT 帧
节拍主时钟 2 ms 内完成轮询 + 打包 + 串口
故障收敛 单轴离线 / 过温 / 通信丢失 → 统一状态与保护
卸载上位机 Linux/ROS 不直接啃 14 帧/拍的 CAN 细节

算力上，先楫类 Cortex-M 做 500 Hz 的打包与状态机足够；真正要设计的是 CAN 负载、中断与 DMA、临界区长度，而不是「主频能不能到 500 Hz」。

七、工程上容易踩的坑

  1. 只改上层频率、不改电机侧调度
    UART 设成 500，CAN 仍按松散轮询，会出现「上报 500、关节数据陈旧」。

  2. 信令挤占定频拍
    设零、清错、查丢包与 MIT 同拍互斥；频繁信令会制造周期性「缺控 / 缺反馈」。

  3. 按最坏填充位做设计，却不做实测
    纸面可能判死刑；应用层要结合示波器 / 逻辑分析仪 / 丢包统计看真实余量。

  4. 把厂宣「总线能力 1 ms」当成应用层必须 1 kHz
    达妙调试工具可以设 1 ms 连发，那是单电机或轻负载场景的能力展示；七轴单总线要单独算账。

  5. 文档与实现不一致
    以代码与配置为准核对波特率（例如上层是 2M 还是其它），避免联调各说各话。

八、可复用的设计清单

若要复现类似「多轴电机 + MCU 汇聚 + 上位机」的实时链路，建议立项时先写清：

九、小结

这套主臂通信实时性的核心不是堆更高的标称频率，而是：

  1. 关节侧用 CAN 1M 按达妙 MIT 问询 7 轴；
  2. MCU在 2 ms 内收齐并打包；
  3. 上层用 UART 2M 以多轴 MIT 与上位机 500 Hz 对齐。
  4. 如果与上位机硬件通信口后续改为 EtherCAT 过程数据按周期交换，有 CRC、状态机（如 OP）、看门狗，比裸 UART 流式拆帧更不容易静默坏数据
    确定性更好，少很多半帧、粘包、校验偶发失败类问题。

在七轴、单总线、问询式反馈的约束下，500 Hz 是算得清、跑得通的工程点；链路分层让上位机保持整臂接口，把实时压力关在 MCU 与 CAN 这一侧消化。

posted @ 2026-11-12 11:21  wavefinder  阅读(5)  评论(0)    收藏  举报