附录2 相关知识点
本页是为「自己动手造机器人」准备的知识梳理：从一颗电机到一条总线，把这台 Episode 六轴臂用到的核心技术按 执行 → 驱动 → 通信 → 软件 → 标准 的层次讲清楚， 最后落到「迁移到你自己的 SOMA 机器人」的选型建议。内容为整理性综述，具体数值以厂商资料为准。
1. 系统架构总览
先看全局。这台臂的电气链路只有四根线进臂（2 根电源 + 2 根 CAN），所有关节挂在同一条 CAN 总线上， 是典型的「主控 + 总线 + 分布式关节驱动」结构——也是绝大多数现代机器人（机械臂、机器狗、人形）的通用范式：
┌─────────┐ USB ┌──────────┐ CAN_H / CAN_L ┌───────── 同一条 CAN 总线 ─────────┐
│ 上位机 │ ───────▶ │ USB2CAN │ ════════════════▶ │ J1 J2 J3 J4 J5 J6 │
│ PC/SBC │ ◀─────── │ (PEAK) │ ◀════════════════ │ 每个关节 = 1 块 ZDT 闭环驱动板 │
└─────────┘ └──────────┘ │ + 1 台 42 步进电机 + 磁编码器 │
运动学/SDK 协议转换 └──────────────────────────────────┘
12V/10A 电源 ─┘ (关节 1~4 还串了行星减速器)
| 层次 | 本臂的实现 | 作用 |
|---|---|---|
| 应用 / 运动学 | 上位机软件、sdk_demo.py（见附录1 §3） | 笛卡尔/关节空间指令、轨迹、逆解 |
| 通信 | CAN 总线 + USB2CAN（PEAK PCAN） | 主控与 6 个关节之间收发指令/状态 |
| 驱动 | 6× 张大头(ZDT) 闭环步进驱动板（FOC） | 把指令变成电机的电流/位置闭环 |
| 执行 | 6× 42 步进电机 + 磁编码器（关节 1~4 带行星减速器） | 真正出力、转动关节 |
对照本臂参数（附录1 §2.1）：6 轴、步进电机 + 高精度行星减速器、FOC 闭环、CAN 总线、 12V/10A、重复定位 ±0.03mm、回零=机械限位 + 编码器自动回零。下面逐层拆解。
2. 执行层：42 步进电机
从最底下「真正出力」的那一层说起。机器人的关节要转，归根结底靠电机；选什么电机，几乎决定了整台机器的成本、精度和脾气。 这台臂选的是步进电机——最朴素、最好上手的一类。先弄懂它怎么转、看哪些参数，再回头理解为什么还要给它配一块「闭环驱动板」（§3）就顺理成章了。
2.1 步进电机原理
步进电机靠「定子线圈按相序通电、转子一步步对齐磁场」转动：每给一个脉冲，转子走固定的一个 步距角。它开环也能定位（数脉冲就知道走了多少），结构简单、低速大扭矩、成本低， 所以教学/轻负载机械臂特别爱用。本臂 6 个关节就是 6 台两相混合式步进电机。
2.2 「42」与 NEMA 机座号标准（硬件制造标准）
「42 步进」里的 42 指电机方形端面约 42mm，对应美标 NEMA 17 （1.7 英寸 = 43.2mm 安装面）。NEMA（美国电气制造商协会）的机座号是步进电机最通用的机械制造标准， 规定了安装孔距、轴径、法兰尺寸，保证不同厂家的同号电机可互换。
| NEMA 号 | 端面尺寸 | 典型用途 |
|---|---|---|
| NEMA 14 | ~35mm | 小型云台、轻关节 |
| NEMA 17（42） | ~42mm | 桌面机械臂、3D 打印机、本臂 |
| NEMA 23（57） | ~57mm | 大一点的臂、CNC |
2.3 关键参数（选型时看这些）
买电机、调驱动时，下面这几个参数是真正要盯的——它们直接决定关节能出多大力、能转多快、会不会发烫：
| 参数 | 含义 | 常见值 |
|---|---|---|
| 步距角 | 每个整步转过的角度 | 1.8°（200 步/圈）/ 0.9°（400 步/圈） |
| 相数 / 线数 | 两相双极最常见 | 2 相 / 4 线 |
| 额定相电流 | 每相允许的持续电流，决定发热与扭矩 | 1.0~2.0 A |
| 保持转矩 | 通电静止时能扛住的最大力矩 | 0.2~0.5 N·m（42 机座） |
| 相电阻 / 相电感 | 影响高速扭矩衰减 | — |
2.4 细分（Microstepping）
驱动器把每个整步再用电流正弦插值切成很多份（16、32、256 细分），得到更平滑、噪声更小、分辨率更高的运动。 注意：细分提高的是「分辨率」，不直接等于「绝对精度」——绝对精度仍受电机本身、装配、减速器回隙限制。
2.5 减速器与回隙
本臂关节 1~4 串了行星减速器。减速比 N 会：扭矩 ×N、转速 ÷N、分辨率 ×N（关节角更细）， 代价是引入回隙（backlash，齿轮间隙）——这正是 1.3 手册里「回隙说明」要专门讲的来源。 做高精度关节时，减速器的回隙等级往往是精度瓶颈。
2.6 步进 vs 伺服 vs 无刷模组
步进不是唯一选择，只是最适合「桌面臂、想快点跑起来」的那一档。横向比一下三类主流方案，也方便你日后给 SOMA 升级时心里有数：
| 方案 | 特点 | 适合 |
|---|---|---|
| 闭环步进（本臂） | 低速大扭矩、便宜、控制简单；高速扭矩衰减快 | 桌面臂、教学、轻负载 |
| 伺服电机 | 高速高动态、贵、需调环 | 工业臂、产线 |
| 无刷(BLDC/PMSM) FOC 关节模组 | 高功率密度、可力控；常见准直驱 | 机器狗、人形（你的 SOMA 进阶方向） |
3. 驱动层：张大头(ZDT) 闭环步进驱动
电机只是「肌肉」，它自己不会算该出多大力、转到哪。负责这件事的是贴在每个关节尾部的那块驱动板—— 可以把它理解成关节的「小脑」：上面有编码器看着电机实际转了多少、有 MCU 实时算电流、再按总线上收到的指令把电机推到位。 这一层决定了关节能不能不丢步、能不能力控、安不安静，是步进方案从「能转」到「能用」的关键。
3.1 为什么要「闭环」
纯开环步进有个致命问题：负载过大或加速过猛会丢步（失步），而主控并不知道，位置就错了。 解决办法：在电机尾部加一颗磁编码器实时读真实角度，形成闭环——丢步能自动补偿、可输出力矩、更安静更凉。 本臂「步进 + 编码器自动回零 + FOC 闭环」就是这个路线。
3.2 Emm42 / ZDT 是什么
本臂每个关节尾部那块驱动板是 张大头（ZDT，ZHANGDATOU） 的 42 机座闭环步进驱动板 （常见型号如 Emm42_V5.0 / ZDT_X42）。张大头是国内知名开源硬件作者，这类板子的特点：
- 板载磁编码器（如 MT6816/MT6701，14 位 ≈ 16384 计数/圈），直接贴在电机尾部；
- 板载 MCU 跑电流环 FOC + 位置/速度环，自带整定；
- 通信支持 UART 串口 + CAN（X 系列/V5 带 CAN），每块板有独立地址/ID，可多块挂同一条总线；
- 协议公开（命令帧格式文档化），方便二次开发。
3.3 FOC 磁场定向控制
FOC（Field-Oriented Control，磁场定向控制）：把两相步进当作一台两相永磁同步电机(PMSM)来控， 借编码器实时角度把电流分解到「转矩分量 q 轴 / 励磁分量 d 轴」，只用恰好够的电流产生转矩。 好处：发热小、噪声低、可力矩控制、低速平稳。这也是本臂参数里写「FOC 闭环」的含义。
3.4 校准与回零（你装配教程里的那一步）
闭环驱动出厂/装配后必须做一次编码器零位标定：让驱动器知道「编码器读数 ↔ 电机电角度」的对应关系， FOC 才能算准。这正是 1.1 装配教程里逐个关节「装驱动板 → 校准 → 测试」、以及 1.2 调试校准做的事。 运行时的「回零」则是把关节转到机械限位、再用编码器找到绝对零位（本臂：机械限位 + 编码器自动回零）。
3.5 控制模式与板载参数
同一块驱动板，按上位机下发的指令类型可以工作在几种控制模式下，对应机械臂不同的用法：
| 控制模式 | 说明 |
|---|---|
| 位置模式 | 给目标角度（带梯形加减速），关节运动到位——机械臂最常用 |
| 速度模式 | 给目标转速，持续转 |
| 力矩 / 电流模式 | 给目标电流→力矩，做柔顺/拖动示教 |
每块板出厂前要配：地址 ID（1~6 对应 6 个关节）、相电流、细分、CAN 波特率。地址不同才能在同一条总线上区分。
4. 通信层：CAN 总线标准
有了会自己闭环的关节，还得让主控能同时指挥六个关节、并听到它们的反馈，而且布线不能乱成一团。 这台臂的答案是：所有关节挂在同一条 CAN 总线上，主控通过一个 USB2CAN 适配器接进去。 为什么偏偏是 CAN、它凭什么能在一条线上可靠地区分和调度这么多节点——这一节从协议本身讲起。
4.1 CAN 是什么（ISO 11898）
CAN（Controller Area Network） 由 Bosch 于 1986 年为汽车设计，1993 年成为国际标准 ISO 11898。它是多主、广播、基于消息的串行总线：任何节点都能主动发，报文用 标识符(ID) 标记内容与优先级，差分信号抗干扰，内置 CRC/ACK/自动重传，可靠性极高。
4.2 帧格式与仲裁
CAN 上传的不是连续字节流，而是一个个独立的帧。一帧里最关键的几个字段：
| 字段 | 说明 |
|---|---|
| Identifier | 11 位（标准帧）或 29 位（扩展帧 2.0B）——既是身份也是优先级 |
| DLC + Data | 数据长度码 + 0~8 字节数据（经典 CAN） |
| CRC / ACK / EOF | 校验、应答、帧结束 |
仲裁：多个节点同时发时，ID 数值越小优先级越高；节点边发边听，发隐性位却读到显性位就退出竞争、 但不丢数据、等空闲重发。这保证了确定性——高优先级报文延迟可预测，机器人实时控制很需要这点。
4.3 物理层与波特率
两根线 CAN_H / CAN_L 差分传输，总线两端各接一个 120Ω 终端电阻。 经典 CAN 最高 1 Mbit/s；速率越高总线越短：
| 波特率 | 最大总线长度（约） |
|---|---|
| 1 Mbit/s | 40 m |
| 500 kbit/s | 100 m |
| 250 kbit/s | 250 m |
| 125 kbit/s | 500 m |
4.4 CAN FD（演进）
CAN FD（CAN with Flexible Data-rate，灵活数据速率 CAN）由 Bosch 于 2012 年发布、后纳入 ISO 11898-1:2015。它保持 CAN 物理层与仲裁机制不变，解决经典 CAN 的两个瓶颈：数据太短（≤8 字节） 与速率太低（≤1 Mbit/s）。两大改进：
- 更长数据段：单帧数据从 8 字节扩到最多 64 字节；DLC 编码扩展，支持 0–8、12、16、20、24、32、48、64 字节这几档。
- 灵活双速率（BRS）：仲裁段仍用较低速率（保证多节点仲裁可靠），数据段可切到更高速率（常见 2M、5M，甚至 8 Mbit/s），由帧中的
BRS位控制是否切换。
相对经典帧新增的关键位：
| 位 | 含义 |
|---|---|
FDF / EDL | 标识该帧是 CAN FD 帧（取代经典帧的 r0 位） |
BRS | Bit Rate Switch，是否在数据段切换到高速率 |
ESI | Error State Indicator，发送节点错误状态指示 |
兼容性（不对称）：CAN FD 控制器能收发经典 CAN 帧；经典 CAN 控制器不能正确处理 CAN FD 帧（会报错）。 因此一条总线上只要有 CAN FD 流量，所有节点都必须支持 CAN FD。
配置 CAN FD 设备需给两个比特率（nominal 仲裁段 + data 数据段），SocketCAN 下示例：
ip link set can0 up type can \
bitrate 500000 sample-point 0.8 \
dbitrate 2000000 dsample-point 0.8 fd on
# bitrate / nominal bitrate：仲裁段速率
# dbitrate / data bitrate：数据段速率PEAK 的 PCAN-USB FD、PCAN-USB Pro FD 等支持 CAN FD；本驱动用 pcanfd.h / pcanfd_* API
读写 FD 帧（PCAN-Basic 的 FD 初始化见 §5.6）。本臂用的是经典 CAN（PCAN-USB），不涉及 FD，此处仅作知识储备。
4.5 USB2CAN 与「为什么机器人用 CAN」
USB2CAN（本臂用 PEAK PCAN，见附录1/驱动包）把 PC 的 USB 转成 CAN 物理口，让电脑成为总线上一个节点。 机器人爱用 CAN 的原因：一条总线菊花链串所有关节（本臂全臂仅 4 根线）、多电机天然组网、确定性实时、抗干扰、生态成熟。 更高性能场景（高自由度/高频）则会上 EtherCAT。
4.6 PEAK-System 公司与 PCAN 产品线
PEAK-System Technik GmbH 是一家德国公司，成立于 1999 年，总部位于德国达姆施塔特（Darmstadt）， 是 CAN 总线领域全球知名的硬件与软件供应商，覆盖 CAN / CAN FD、LIN、K-Line 等现场总线技术。 其产品统一以 PCAN 为前缀，按物理接口分类：
| 产品系列 | 接口 | 说明 |
|---|---|---|
| PCAN-USB | USB | USB 转 CAN 适配器（本项目对应类型） |
| PCAN-USB FD | USB | 支持 CAN FD 的 USB 适配器 |
| PCAN-USB Pro FD | USB | 双通道 CAN FD + LIN |
| PCAN-PCI / PCIe | PCI / PCIe | 板载 CAN 卡 |
| PCAN-miniPCIe | Mini PCIe | 工控机 / 嵌入式 |
| PCAN-Chip | 焊接模块 | OEM 集成 |
| PCAN-Ethernet Gateway | 以太网 | CAN over IP 网关 |
配套上位机软件：
| 软件 | 用途 |
|---|---|
| PCAN-View | 免费的 CAN 报文监控 / 收发工具 |
| PCAN-Explorer | 专业 CAN 分析软件（脚本、绘图、数据库） |
| PCAN-Basic | 跨平台编程 API（见 §5.6） |
很多第三方 USB2CAN 设备在协议设计、上位机兼容性上都会对标 PEAK 的 PCAN-USB 系列，因此 PEAK 驱动常作为该领域的参考实现。 PEAK 在 Linux 上有两条路径：① PEAK 官方 PCAN-Linux 驱动（即本项目，提供
pcan模块，支持 chardev 与 netdev）； ② 内核自带 SocketCAN 的peak_usb驱动。见 §5.2 / §5.5。
5. 软件与驱动标准
前面三层都是硬件——电机、驱动板、总线。但你最终是用代码来指挥这台臂的，从一行 move_xyz
到电机真正转动，中间隔着好几层软件：操作系统怎么把 USB2CAN 认成一个 CAN 设备、用什么库收发帧、帧里又按什么协议写命令。
这一节把这条「软件栈」自上而下拆开，并交代本臂在每一层各自选了哪条路（也是你将来给 SOMA 写控制软件时要照着搭的骨架）。
5.1 软件栈分层
应用层 运动学 / 轨迹 / VLA 策略 ← 你写的程序、SDK demo ───────────────────────────────────── 接口层 上位机 SDK / API（move_xyz…） ← 附录1 §3 的 13 个 API ───────────────────────────────────── 库 层 PCAN-Basic / SocketCAN 收发 ← 跨平台 CAN 读写 ───────────────────────────────────── 驱动层 内核驱动（PEAK pcan.ko / 内核 CAN） ───────────────────────────────────── 硬件 USB2CAN → CAN 总线 → ZDT 驱动 → 电机
5.2 设备驱动标准：SocketCAN vs chardev
Linux 下读写 CAN 有两条路：SocketCAN（内核原生框架，把 CAN 当网络接口 can0，用 socket 收发，最通用）；
或厂商 字符设备（chardev，如 PEAK 的 /dev/pcanusb32 + PCAN-Basic 库）。本臂驱动包两种都覆盖
（架构细节见 §5.5，编译安装见 §5.8）。
SocketCAN（最初由 Volkswagen Research 贡献）把 CAN 控制器抽象成一块「网卡」、CAN 帧当作「网络数据包」：使用新的协议族
AF_CAN / PF_CAN，支持原始套接字 SOCK_RAW（CAN_RAW）与广播管理器 CAN_BCM；
多个应用可同时打开同一接口（内核负责分发），这是相对传统字符设备的一大优势。命令与编程见 §5.7。
PEAK 设备接入 SocketCAN 有两种来源：① 内核内置 peak_usb（随主线发布，许多 PEAK USB 设备开箱即以 can0 出现，只支持 SocketCAN）；
② 本项目 pcan 驱动的 netdev 模式（make netdev 编译后同样注册为 can0）。
而 chardev（/dev/pcanXX + PCAN-Basic）是 pcan 的另一种模式——本臂校准软件/上位机走的正是 chardev + PCAN-Basic（见附录2 §0 结论）。
5.3 应用层协议：厂商私有 vs CANopen（驱动控制标准）
CAN 只规定了「怎么传一帧」，没规定「帧里写什么命令」——那是应用层协议的事，有两条路线：
- 厂商私有协议：如 ZDT/Emm42 自定义的命令帧（地址 + 功能码 + 参数 + 校验）。简单直接，本臂走这条。
- CANopen（CiA 标准）：CAN in Automation 组织的 CiA 301 基础协议 + CiA 402（运动控制 profile）， 用「对象字典 + PDO/SDO」统一了伺服/驱动的控制方式，工业界通用。代价是更重、更复杂。
给自制机器人的提示：少量电机、想快速跑起来 → 用厂商私有协议（像本臂）；要接多品牌工业驱动、要可维护性 → 上 CANopen/CiA 402。
5.4 本系统的 SDK / 运动学层
最上层是上位机暴露的 API（附录1 §3：angle_mode、move_xyz_rotation、move_linear_xyz_rotation、
gripper_on/off、get_pose…）。它把「笛卡尔位姿 / 关节角」翻译成对 6 个驱动板的 CAN 指令，
并封装了正/逆运动学（DH 参数见附录1 §2.1；DH 与 URDF 两种描述方式的对比见 §6）。这一层就是你将来给 SOMA 写「大脑→身体」接口时要自己实现的部分。
5.5 PCAN 驱动架构（peak-linux-driver）
本项目即 PEAK 官方的 peak-linux-driver（仓库内含 8.13.0 / 8.14.0 / 8.15.1 / 8.15.2 / 8.17.0 / 8.20.0 多个版本，
本机用 8.20.0）。核心是一个名为 pcan 的内核模块，外加用户空间库与测试程序。目录结构：
peak-linux-driver-x.y.z/
├── driver/ # 内核驱动源码（GPL）
│ ├── src/ # 各芯片/接口的实现
│ ├── pcan.h # chardev 模式用户态接口定义
│ ├── pcanfd.h # CAN FD 相关接口定义
│ └── pcan.conf # 模块配置
├── lib/ # libpcan 用户空间库（LGPL）
├── libpcanbasic/ # PCAN-Basic API 实现（见 §5.6）
├── test/ # 测试/示例程序（pcanview、receivetest、transmittest…）
├── Documentation/ # man 手册等文档
└── Makefile # 顶层构建脚本许可证：driver/ 子目录为 GPL；其余子目录为 LGPL。驱动可编译成两种互斥的模式：
- chardev 模式（默认，
make）：设备表现为字符设备/dev/pcan0//dev/pcanusb32，用open/read/write/ioctl访问，配合 libpcan / PCAN-Basic 库；PEAK 私有 API，跨 Windows/Linux/macOS 一致。本臂用这种。 - netdev 模式（
make netdev）：设备注册为 SocketCAN 网络接口can0，用标准ip link+ socket + can-utils 操作，与 Linux 生态无缝集成。
其他特殊构建目标：
| 目标 | 用途 |
|---|---|
make（默认） | chardev 版本 |
make netdev | SocketCAN 网络接口版本 |
make xeno | Xenomai 3.x 实时（RTDM）版本 |
make rtai | RTAI 5.x 实时（RTDM）版本 |
按物理接口模块化支持 USB（本项目重点）、PCI / PCIe、PC/104、ISA / Dongle（并口）等。
⚠️ 与内核内置
peak_usb的区别 / 冲突：内核内置peak_usb随主线发布、只支持 SocketCAN；本项目pcan由 PEAK 维护、更新更快、同时支持 chardev 与 netdev 并附带 PCAN-Basic 生态。 两者会争抢同一 USB 设备，实际只能保留其一——加载本驱动前sudo rmmod peak_usb或把它加入 modprobe 黑名单（本机做法见 §5.8 与episode-driver/CLAUDE.md）。
5.6 PCAN-Basic API（chardev 应用接口）
PCAN-Basic 是 PEAK 提供的跨平台编程接口，让程序用统一函数集访问所有 PCAN 硬件（USB、PCI、LAN…），
在 Windows / Linux / macOS 上调用一致。本项目 libpcanbasic/ 子目录就是它在 Linux 上的实现，底层依赖 chardev 模式的 pcan 驱动。
单一头文件 PCANBasic.h，支持经典 CAN 与 CAN FD，多语言绑定（C/C++、C#、Python、Delphi、VB…），用通道句柄（如 PCAN_USBBUS1）统一标识设备。
关键函数：
| 函数 | 作用 |
|---|---|
CAN_Initialize() | 初始化经典 CAN 通道（指定波特率） |
CAN_InitializeFD() | 初始化 CAN FD 通道（指定双速率） |
CAN_Read() / CAN_ReadFD() | 读取一帧 |
CAN_Write() / CAN_WriteFD() | 发送一帧 |
CAN_FilterMessages() | 设置接收滤波器 |
CAN_GetValue() / CAN_SetValue() | 读/写参数（设备信息、LED、总线状态） |
CAN_Reset() | 清空收发队列 |
CAN_Uninitialize() | 释放通道 |
CAN_GetErrorText() | 把错误码转成可读文本 |
最小使用流程（C，伪代码）：
#include "PCANBasic.h"
// 1. 初始化：USB 通道1，500 kbit/s
CAN_Initialize(PCAN_USBBUS1, PCAN_BAUD_500K, 0, 0, 0);
// 2. 发送
TPCANMsg msg = { .ID = 0x123, .MSGTYPE = PCAN_MESSAGE_STANDARD,
.LEN = 2, .DATA = {0xAB, 0xCD} };
CAN_Write(PCAN_USBBUS1, &msg);
// 3. 接收
TPCANMsg rx; TPCANTimestamp ts;
if (CAN_Read(PCAN_USBBUS1, &rx, &ts) == PCAN_ERROR_OK) {
// 处理 rx
}
// 4. 释放
CAN_Uninitialize(PCAN_USBBUS1);CAN FD 用一条比特率字符串描述时序，而非单一波特率常量：
TPCANBitrateFD bitrate =
"f_clock_mhz=80, nom_brp=2, nom_tseg1=63, nom_tseg2=16, nom_sjw=16, "
"data_brp=2, data_tseg1=15, data_tseg2=4, data_sjw=4";
CAN_InitializeFD(PCAN_USBBUS1, bitrate);PCAN-Basic 走 chardev（
/dev/pcanXX，见 §5.5）；若改用 netdev / SocketCAN 则不用 PCAN-Basic，而用标准 socket API（见 §5.7）。 二者选其一，取决于你想要「跨平台 PEAK 生态」还是「Linux 原生生态」。
5.7 CAN 命令速查（can-utils / ip link）
走 SocketCAN（netdev 模式）时，用 ip 命令管理接口、用 can-utils 工具集收发：
# 查看 CAN 接口
ip link show
# 配置并启用经典 CAN（500 kbit/s）
sudo ip link set can0 type can bitrate 500000
sudo ip link set can0 up
# 配置 CAN FD（仲裁 500k / 数据 2M）
sudo ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on
sudo ip link set can0 up
# 关闭接口
sudo ip link set can0 down| can-utils 工具 | 用途 |
|---|---|
candump can0 | 抓取/打印总线上所有帧 |
cansend can0 123#DEADBEEF | 发送一帧 |
cangen can0 | 生成随机流量（压测） |
canplayer | 回放 candump 日志 |
canbusload | 统计总线负载 |
原始套接字编程示例（C，简化）：
int s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
struct ifreq ifr;
strcpy(ifr.ifr_name, "can0");
ioctl(s, SIOCGIFINDEX, &ifr);
struct sockaddr_can addr = { .can_family = AF_CAN,
.can_ifindex = ifr.ifr_ifindex };
bind(s, (struct sockaddr *)&addr, sizeof(addr));
struct can_frame frame;
read(s, &frame, sizeof(frame)); // 收
write(s, &frame, sizeof(frame)); // 发5.8 驱动编译与安装（peak-linux-driver）
以下命令在解压后的 peak-linux-driver-x.y.z/ 目录内执行（基于项目 README 整理）。
1) 编译依赖（Debian/Ubuntu，其他发行版找等价包）：
sudo apt install linux-headers-$(uname -r) libpopt-dev g++ make
# linux-headers-$(uname -r)：编译内核模块必需，必须匹配当前运行内核
# libpopt-dev、g++：仅 test/ 子目录的示例程序需要2) 编译（chardev / netdev / 实时，三选一；切换前先 make clean）：
cd peak-linux-driver-x.y.z
make clean all # chardev 模式（默认）→ /dev/pcanXX
# make netdev # SocketCAN 模式 → can0
# make xeno # Xenomai 3.x 实时（RTDM）
# make rtai # RTAI 5.x 实时（RTDM）3) 安装 / 卸载：
sudo make install # 对 driver/lib/test/libpcanbasic 分别安装
sudo make uninstall4) 加载与验证：
# 加载内核模块
sudo modprobe pcan # 或 sudo insmod driver/pcan.ko
lsmod | grep pcan # 查看模块是否加载
ls -l /dev/pcan* # chardev：查看设备节点
ip link show | grep can # netdev：查看网络接口
cat /proc/pcan # chardev 模式的状态信息
dmesg | grep -i pcan # 内核日志仓库辅助脚本：pcan_make_devices（创建 /dev/pcanXX 节点）、lspcan（列出已识别的 PCAN 设备）、pcanosdiag.sh（收集系统诊断信息，报问题时附上）。
常见坑：
| 问题 | 原因 / 解决 |
|---|---|
| 编译报找不到内核头文件 | linux-headers 版本与 uname -r 不一致 |
| 设备没出现 | 内核内置 peak_usb 抢占了设备 → sudo rmmod peak_usb 或加入 modprobe 黑名单 |
权限不足访问 /dev/pcanXX | 把用户加入对应组，或用 udev 规则设权限 |
| Secure Boot 拒绝加载模块 | 需对模块签名，或在 BIOS 关闭 Secure Boot |
| 想随内核自动重建 | PEAK 也提供 DKMS 打包方式，内核升级后自动重编 |
本机实操记录（含内核 6.17 兼容补丁、MOK 签名、apt-mark hold 等具体命令）见
episode-driver/CLAUDE.md §0 / §3–§9；驱动包下载见附录1 资料中心。
6. 机器人的运动学描述：DH 参数 vs URDF
前面 §5.4 提到上位机封装了正/逆运动学。那么「这台臂长什么样、各关节怎么连」这件事，到底怎么写下来给计算机算？ 主流有两套答案：偏数学推导的 DH 参数，和偏工程落地的 URDF。本节讲清两者的区别，以及为什么到了 ROS/MoveIt 时代，你更常打交道的反而是 URDF。
6.1 DH 参数回顾
DH 是两位提出者的姓氏首字母——Jacques Denavit 与 Richard Hartenberg（1955 年论文提出、1964 年合著教材系统化）。 它给串联臂的每个连杆建一套坐标系，用最少的 4 个参数描述相邻坐标系之间的变换（DH 本身详见 1.8 DH 参数与正逆运动学 与附录1 §2.1）：
| 参数 | 含义 | 几何意义 |
|---|---|---|
θ 关节角 | 绕 z 轴旋转 | 旋转关节的变量 |
d 连杆偏移 | 沿 z 轴平移 | 移动关节的变量 |
a 连杆长度 | 沿 x 轴平移 | 两 z 轴间公垂线长度 |
α 连杆扭转 | 绕 x 轴旋转 | 两 z 轴之间的夹角 |
这 4 个参数组成一个 4×4 齐次变换矩阵，把第 i−1 个坐标系变换到第 i 个；把所有连杆的变换矩阵依次相乘，就得到基座→末端执行器的总变换——这正是机械臂正运动学的核心。
⚠️ DH 有两种约定：标准 DH（Standard / Distal）与改进 DH（Modified / Proximal，Craig 提出）。 两者坐标系的摆放位置与矩阵相乘顺序都不同（标准为
Rot(z)·Trans(z)·Trans(x)·Rot(x)，改进为Rot(x)·Trans(x)·Rot(z)·Trans(z)），参数表也不一样。 因 John J. Craig 的经典教材流行，改进 DH 在现代教学与工程里更主流。拿到任何一张 DH 表，第一件事是先确认它是哪种约定——混用会直接算错。
6.2 URDF 是什么
URDF（Unified Robot Description Format，统一机器人描述格式）是 ROS 生态里描述机器人的标准——一种基于 XML 的文件，主要写两类东西：
- Link（连杆）：机器人的刚体部件，可含
visual（显示用的外观/网格）、collision（碰撞模型，通常比 visual 更简化）、inertial（质量、质心、惯性张量，供动力学计算）。 - Joint（关节）：连接父、子两个 link，指定关节类型（
revolute旋转 /prismatic平移 /fixed固定 /continuous连续旋转）、转轴axis，以及最关键的origin——子坐标系相对父坐标系的位姿，用xyz（平移）+rpy（roll-pitch-yaw 旋转）表达。
<joint name="joint2" type="revolute">
<parent link="link1"/>
<child link="link2"/>
<origin xyz="0.5 0 0.2" rpy="0 1.5708 0"/> <!-- 子坐标系相对父的固定安装位姿 -->
<axis xyz="0 0 1"/> <!-- 绕子坐标系 z 轴转 -->
</joint>关键点：
origin是相对位姿（子相对父）、是固定的安装关系，既不是绝对坐标、也不包含「当前转了多少度」。 关节的实时角度由运行时的控制器/程序提供；要算末端此刻在世界里的位置，就拿「固定的连接结构 + 当前各关节角」，从基座一节节往下乘变换矩阵（即正运动学）。
6.3 DH vs URDF：同一件事的两种表达
两者解决的是同一个问题——描述串联机构里相邻部件之间的几何变换。差别在于「约定的强弱」和「承载的信息量」：
| 对比项 | DH 参数 | URDF |
|---|---|---|
| 每段变换用几个数 | 4（θ / d / a / α） | 6（xyz + rpy） |
| 坐标系摆放 | 强约定（z 沿关节轴、x 沿公垂线…） | 自由，放哪都行 |
| 还描述什么 | 仅运动学 | + 可视化 / 碰撞 / 惯性 |
| 擅长场景 | 公式推导、解析逆解、论文 | ROS/MoveIt 部署、仿真、可视化 |
| 能否互转 | 可以。DH→URDF 容易（每行 DH 变换对应一个 joint 的 origin）；URDF→DH 较麻烦（URDF 坐标系未必满足 DH 约定，需重新对齐），但有现成工具 | |
一句话：DH 是「最小参数 + 强约定」的运动学描述方法，偏数学；URDF 是「完整机器人描述文件格式」，偏工程，运动学只是它描述的一部分。 两者的几何信息可以互通，但 URDF 承载的内容远不止 DH 那点东西。
6.4 URDF 在 ROS / MoveIt 生态中的应用
在现代软件框架里，你通常不必手写 DH 表，而是准备/导出一份 URDF，剩下的交给工具链自动处理：
- MoveIt：读 URDF（+ SRDF）自动做正/逆运动学、运动规划、碰撞检测——不用你手推 DH。
- RViz：按 URDF 的 visual 与 TF 实时可视化机器人当前姿态。
- Gazebo / Isaac：按 collision + inertial 做物理仿真。
- robot_state_publisher：读 URDF + 各关节角，发布全身 link 的 TF 坐标变换树。
URDF 常由 CAD（SolidWorks / Fusion 的导出插件）或 Xacro（带宏的 URDF，避免重复书写）生成。本课程提供的 ROS 2 功能包里就含 Episode 臂的 URDF（见附录1 资料中心）； 你将来给 SOMA 上 ROS2 / MoveIt 时，第一步往往就是准备一份准确的 URDF。
7. 相关标准汇总
把前面散落在各层的「标准」收拢成一张表，方便日后选型或查阅时一眼定位——每一行回答的都是「这件事归谁管、管的是什么」。 你会发现一台机器人从机械到软件，背后其实站着一整排不同组织维护的规范：
| 领域 | 标准 / 规范 | 维护方 | 管什么 |
|---|---|---|---|
| 电机机械 | NEMA 机座号（NEMA 17/23…） | NEMA（美国电气制造商协会） | 安装尺寸、轴径、互换性 |
| 电机电气 | 步距角 1.8°/0.9°、绝缘等级、IP 防护 | IEC / 厂商 | 步距、绝缘、防护 |
| 总线-数据链路 | ISO 11898-1（经典 CAN / CAN FD） | ISO（源自 Bosch） | 帧格式、仲裁 |
| 总线-物理层 | ISO 11898-2（高速 CAN） | ISO | 电平、终端电阻、收发器 |
| 驱动控制协议 | CANopen CiA 301 / CiA 402 | CiA（CAN in Automation） | 运动控制对象字典、状态机 |
| Linux 驱动 | SocketCAN | Linux 内核社区 | 内核 CAN 网络框架 |
| 机器人描述 | URDF / Xacro | ROS / Open Robotics | 连杆-关节结构、可视化/碰撞/惯性 |
| 厂商驱动 | ZDT/Emm42 私有协议、PCAN-Basic API | 张大头 / PEAK-System | 具体板子的命令与库 |
8. 给「自己造机器人」的启示
把这台 Episode 臂当作一块「积木样板」，迁移到你自己的 SOMA 机器人时可以这样想：
- 关节方案按负载选：桌面/轻负载 → 闭环步进（便宜好上手，就是本臂）；机器狗/人形等要功率密度和力控 → 无刷 FOC 关节模组（如准直驱 + 高分辨率编码器）。
- 总线先选 CAN：多电机、要确定性、布线少（菊花链）。先用厂商私有协议快速跑通，规模化或要可维护性再迁 CANopen/CiA 402； 追求高频高自由度再考虑 EtherCAT。
- 闭环是底线：任何要精度/安全的关节都上编码器闭环，别用纯开环；校准（编码器零位）和回零策略要从第一天就设计好。
- 软件按层搭：内核 CAN 驱动 → 收发库 → 关节抽象（地址/模式/限位）→ 运动学/轨迹 → 策略（你的 VLA/大脑）。 每层接口清晰，将来换电机/换总线只动一层。
- 从本臂直接复用：CAN 收发、ZDT 驱动协议、运动学 DH、上位机 SDK 这些（附录1）都能当你 SOMA 的起步脚手架。
一句话路线：先把这台臂的每一层吃透 → 用相同分层换上你自己的电机/结构 → 接上你的策略大脑， 就是 SOMA 从「拼装样板」到「自研机器人」的最短路径。