跳转至

RDK X5 CAN 通信

本文根据已录制课程的配套课件整理,保留原课件的接线、命令、实测结果和验证范围。

原始课件

从机器人应用到板载控制器回环,建立两层可复现验证。

本课完成两条验证链路

先观察 CAN 在机器人中的真实应用,再独立验证 X5 板载 CAN 控制器。

USB-CAN 应用

复用已验证机器人控制链,执行一次官方复位动作。

板载 CAN

识别 X5 的 can4,并进入控制器内部回环模式。

证据闭环

100 帧逐帧收发一致,错误计数保持为零。

CAN 适合可靠的多节点通信

标识符

报文由 ID 表达优先级和数据含义。

差分总线

外部总线通过 CAN_H 与 CAN_L 抵抗共模干扰。

控制器

Linux 通过 SocketCAN 把控制器呈现为网络接口。

验收

比较发送 ID、长度和数据,不只看接口是否存在。

应用与板载能力分开验证

机器人已完成标定

USB-CAN驱动执行器

官方复位产生可见动作

板载 can4独立内部回环

100/100逐帧匹配

机器人复位展示 CAN 的应用价值

机器人被轻微摆离默认姿态后,官方控制流程通过 USB-CAN 让关节回到复位目标。

可见动作

身体和关节产生连续、受控的复位运动。

复用团队链路

沿用已部署 SDK、配置与默认姿态,不重新标定。

课程证据

证明 CAN 能承载真实执行器控制,而非只显示终端文本。

这段动作证明什么?

USB-CAN 动作与板载 CAN 回环是互补证据,不能互相替代。

  • 证明现有机器人、USB-CAN 和执行器链路可完成官方复位
  • 证明关节反馈在动作前后发生可观察变化
  • 不把一次复位扩大为行走或舞蹈验收
  • 不宣称 USB-CAN 动作使用了 X5 白色 SH1.0 接口
  • 板载接口能力由后续 can4 内部回环单独验证

X5 板载 CAN 与外部接口

系统中的 can4 对应 X5 板载 m_can 控制器。本课使用控制器内部回环,不需要把 SH1.0 接口连接到外部节点。

RDK X5 onboard CAN pinout

can4:真实板载控制器|内部回环无需外部线束

内部回环仍经过真实控制器

配置can4 DOWN

模式LOOPBACK ON

速率1 Mbps

收发ID 0x5A5

比对序号与载荷

脚本完成配置、收发与恢复

测试关闭软件 echo,避免把 SocketCAN 自回显误认为硬件控制器回环。

接口配置

ip link set can4 type can bitrate 1000000 loopback on
ip link set can4 up

只在接口原本为 DOWN 时执行。

测试帧

ID: 0x5A5
DATA: sequence + AA551234
COUNT: 100

每帧按 ID、长度和数据比对。

终端实时显示逐帧结果

录屏展示 can4 身份、回环配置、帧计数与最终 PASS。

发送

连续产生 100 个带递增序号的经典 CAN 帧。

接收

接收端从真实控制器回环路径取回同一帧。

判定

100/100 匹配后才输出 PASS,并恢复接口状态。

X5 板载回环结果

接口

can4 / m_can / SPI5.0

速率

1,000,000 bit/s

数据

标准 ID 0x5A5,8 字节

结果

100 发送、100 接收、100 匹配

完成后恢复干净状态

课程测试不改变机器人 USB-CAN 的 can0 至 can3,也不保留后台进程。

  • 关闭测试 socket
  • 将 can4 恢复为 DOWN
  • 关闭 LOOPBACK 与 LISTEN-ONLY
  • 核对 berr-counter tx=0、rx=0
  • 不重载驱动、不重启系统、不修改设备树

回环失败时按顺序排查

先确认接口与模式,再排除软件 echo 和过滤设置。

Step 1

确认使用 can4,而不是机器人 USB-CAN 的 can0 至 can3。

Step 2

发送时不要同时启用 listen-only。

Step 3

关闭发送 socket 的软件 echo,避免重复帧。

Step 4

退出后复查 can4 为 DOWN,模式均为 OFF。

RDK X5 CAN 验证完成

真实机器人动作与板载控制器回环共同说明 X5 具备 CAN 应用和开发能力。

应用可见

USB-CAN 驱动机器人完成官方复位。

控制器可测

can4 完成 1 Mbps 内部回环。

边界清晰

不把内部回环等同于外部线束或电机协议验证。