1. 跑通 OpenArm 那三条命令之前，得先承认一件事：卡住你的多半不是代码

OpenArm 这台 7 自由度机械臂的入门阶段，真正让人卡住的环节往往不在运动学解算，也不在控制算法，而在那三条看起来平平无奇的命令上。我第一次接触这类 7 自由度机械臂时也是这个心态——仓库 clone 下来，README 上就三行命令，想着十分钟搞定，结果整整一个下午都耗在candump刷屏的错误帧上。后来复盘才发现，这三条命令其实是三个完全不同的层次：第一条把 CAN 总线从内核层拉起来，第二条完成构建与零位标定，第三条才真正把演示节点跑起来。任何一层没对齐，后面全是白忙。

这篇内容就是围绕这三条命令展开的。我会把每条命令拆到"为什么这么写""参数在做什么""写错了会怎样"的程度，中间穿插我自己踩过的坑和一些只有真上手才会知道的细节。适合两类人看：手上刚拿到 OpenArm 或同类 7 自由度 CAN 总线机械臂、想把官方演示先跑通的新手；以及已经能跑但想搞清楚底层逻辑、准备自己写控制程序的开发者。CAN 总线的基本概念我会用生活化的类比讲清楚，不需要你有伺服调试经验，但最好知道什么是关节、什么是零位。

先给一个整体认知，免得后面章节看着散。7 自由度机械臂的每个关节背后都是一个带 CAN 接口的伺服驱动器，主机通过一条总线把 7 个关节串起来，用不同的帧 ID 区分。整条链路是：应用层算期望 → 打包成 CAN 帧 → SocketCAN 交给内核 → USB-CAN 适配器转成差分电平 → 关节驱动器解析 → 电机执行。三条命令分别对应这条链路的头、中、尾。链路任何一环断了，你看到的表象都差不多：机械臂一动不动，或者报一堆看不懂的错误。所以排查顺序必须是从物理层往上，不能反过来。

1.1 "插上 USB-CAN 适配器就该能通信"这个预设错在哪

新手最常见的预设是：USB-CAN 适配器插上，系统识别成串口，那就应该能通信了。这个思路在串口上成立，在 CAN 上不成立。CAN 是总线协议，不是点对点串口，内核里必须有一个网络设备（interface）来承载它，这个设备由驱动创建，但创建出来默认是DOWN状态，而且位速率是 0——也就是根本没配置。你可以把 CAN 接口理解成一块网卡，网卡没up、没配速率，插着线也不通。

更麻烦的是，很多适配器在 Linux 下插上之后，ip link里根本看不到对应设备，这时候问题在驱动层，跟机械臂一点关系都没有。我遇到过的情况是适配器用的芯片需要额外内核模块，dmesg里能看到 USB 枚举成功但没生成can0，这种时候去翻仓库的 issue 或者看适配器说明才是正解，命令敲一百遍也没用。所以动手前先确认一件事：ip link show里面有没有can0（或者can1）。没有，就去查驱动；有但是状态DOWN，才轮到第一条命令登场。

1.2 位速率、终端电阻、共地：物理层三处高频故障点

这三样东西我放在一起讲，因为它们出问题时的表现非常像：通信时好时坏、偶发错误帧、candump里偶尔冒出乱码。区分方法在下一小节，这里先说清楚它们各自是什么。

位速率是总线上每个位的持续时间，单位 bit/s。总线上所有节点必须用同一个位速率，差一点点都不行。这就像一个会议室里所有人必须用同一种语速说话，只要有一个人快 10%，别人就听不懂。7 自由度机械臂通常用 1 Mbps，原因在第二章细讲。

终端电阻是 CAN 差分总线的阻抗匹配，标准要求总线两端各一个 120 Ω，中间节点不接。为什么？CAN 用的是差分信号，两根线之间的电压差表示 0 和 1，信号在总线末端会反射，反射波叠加到原信号上就会把位电平搞乱。120 Ω 终端的本质是吸收掉这部分能量，让信号干净落地。你可以把它类比成水管末端的缓冲罐，没有它，水锤会把管子震得咣咣响。判断方法很简单：断电情况下用万用表量 CAN_H 和 CAN_L 之间的电阻，正常应该在 60 Ω 左右（两个 120 Ω 并联）。量出来 120 Ω 说明只有一端接了，量出来无穷大说明两端都没接，这两种情况都可能导致通信不稳定甚至完全不通。

共地这一点经常被忽略。CAN 是差分传输，理论上抗共模干扰能力强，但如果主机（通过 USB-CAN）和机械臂驱动器由不同电源供电，两者地电位差太大，共模电压就会超出收发器的容忍范围。表现是短距离测试没问题，一接上大功率电机、一加负载就开始丢帧。我现在的习惯是，凡是调试台架，主机和机械臂电源一定共地，宁可多拉一根线。

1.3 用 candump 和错误计数器做一次物理层自检

在敲第一条正式命令之前，我建议先做两步自检，这两步能省掉后面 80% 的困惑。

第一步，把接口拉起来（参数随便给个和驱动器一致的），然后开一个终端跑candump can0，另一个终端什么都不做，纯粹观察。如果总线上没有任何节点主动发帧，你应该看到一片安静，这是正常的。如果看到大量错误帧、或者candump直接报bus-off，那基本可以确定物理层有问题：位速率不匹配、终端电阻缺失、接线反了（CAN_H 和 CAN_L 对调）、或者某个节点没上电。

第二步，看内核统计：

ip -details -statistics link show can0

输出里重点看berr-counter（错误计数器）和restart-ms。健康状态下收发都正常，错误计数应该在 0 附近。如果bus-errors持续增长，别急着改代码，先回去查线。另外state ERROR-ACTIVE是正常的，一旦变成ERROR-PASSIVE或BUS-OFF，说明错误累计到阈值了，这时候驱动会主动把节点踢出总线，你敲什么命令都没用，得先重启接口。

提示：手上暂时没有硬件、或者想先验证软件链路，可以用虚拟 CAN 接口做回环测试。加载vcan模块、建一个vcan0、然后candump vcan0配cansend vcan0 123#1122，能收到就说明你的 SocketCAN 环境和权限配置没问题。这一步能把"软件问题"和"硬件问题"彻底分开，非常值得花五分钟做。

2. 第一条命令：ip link set can0 up，每个参数都不是摆设

先把完整形态摆出来。很多人从 README 上抄的是一行版本，实际工程里我会写成三行，原因后面讲：

sudo ip link set can0 down sudo ip link set can0 type can bitrate 1000000 sample-point 0.875 restart-ms 100 sudo ip link set can0 up

这三行合起来才是"第一条命令"的完整含义。它做的事情非常底层：告诉内核，把这个叫can0的网络设备配置成 CAN 类型，位速率 1 Mbps，采样点 87.5%，并且在总线进入 bus-off 后 100 ms 自动尝试恢复，然后把它启用。配置完成后，can0就变成了一个可以被应用程序打开、读写的套接字设备。

2.1 逐段拆解这行命令，以及为什么必须先 down

ip link set can0 down这一句看起来多余，其实是必须的。CAN 设备的位速率、采样点这些参数只能在设备处于 DOWN 状态时修改，接口一旦 UP，再去ip link set can0 type can bitrate ...就会直接报错：

RTNETLINK answers: Device or resource busy

这个报错我第一次见的时候一头雾水，因为报错信息完全没提"设备正在运行"。后来才知道必须先 down。这也是为什么我不用那种"一行搞定"的写法——某些版本的 iproute2 里，ip link set can0 up type can bitrate 1000000这种把 up 和配置写在一起的命令，执行顺序是先 up 再配参数，结果就是上面那个报错。稳妥起见，永远拆成 down / 配置 / up 三步。

type can是告诉 iproute2 你要配置的是 CAN 类型的链路层参数，不是普通的以太网参数。bitrate 1000000就是 1 Mbps，单位是 bit/s，注意不要写成 1000——那不是 1000 kbps，是 1 kbps，配错了通信必然失败。sample-point 0.875是采样点位置，下一小节单独说。restart-ms 100是自动恢复定时器，总线进入 bus-off 后，内核每隔 100 ms 尝试重启一次，这个参数在调试阶段特别有用，否则一次干扰就得手动重来。

2.2 七自由度机械臂为什么偏爱 1 Mbps 这个位速率

选位速率本质是在"带宽"和"可靠性"之间找平衡。位速率越高，单位时间能传的帧越多，但对总线长度、终端匹配、线材质量的要求也越苛刻。CAN 的经验关系是：1 Mbps 对应总线长度不超过约 40 m，500 kbps 约 100 m，125 kbps 可以到 500 m 左右。这个限制来自信号传播延迟和仲裁机制——速率越高，一个位的时间越短，信号必须在一个位的时间内跑完全线并稳定下来。

7 自由度机械臂的总线长度通常在一两米以内，物理上完全支持 1 Mbps。而带宽需求是这样的：7 个关节，如果控制频率 500 Hz，每个周期每个关节一帧控制指令，就是每秒 3500 帧。按标准帧 8 字节数据算，一帧在总线上的时间大约是 111 位（含帧间隔），1 Mbps 下约 111 μs，最坏情况考虑位填充增加约 20%，按 135 μs 估。3500 帧 × 135 μs = 0.47 秒，占 1 秒的 47%。这个负载在 1 Mbps 下是可以接受的，换到 500 kbps 就变成 94%，几乎跑满，一旦加上反馈帧就彻底堵死。所以 1 Mbps 不是随便选的，是被帧数和周期反推出来的。

2.3 采样点与 SJW：位速率对得上却偶发错误帧的真正原因

这是最容易被忽略的参数。两个节点位速率都是 1 Mbps，理论上应该能通，但如果采样点设置差异太大，就会出现"大部分时候正常、偶尔报错"的诡异现象。

原理是这样的：CAN 总线上的节点没有独立的时钟线，全靠位流里的跳变沿来重新同步。每个位被划分成若干个时间份额（TQ），采样点定义在一个位的百分之多少处进行采样。采样点太靠前，信号还没稳定；太靠后，容易受下一bit的影响。业界惯例是 75% 到 87.5% 之间，1 Mbps 这种高速率场景通常用 87.5%。SJW（同步跳转宽度）则定义了接收节点在一次重同步中最多能调整多少个 TQ，一般设 1 到 4。

驱动器出厂时通常有一个默认采样点，你主机这边如果设了个差异很大的值，两个节点对"位的中点在哪"的认知就不一致，短帧没事，连续多个相同极性位之后的那个跳变沿就可能采错。表现就是错误帧计数缓慢增长，跑几分钟才 bus-off 一次，非常难查。

提示：不确定驱动器采样点时，最稳妥的做法是查驱动器手册，或者干脆不显式指定sample-point，让内核按位速率给一个默认值，然后观察错误计数。如果错误计数不涨，就别折腾；如果涨，再逐个试 0.75 / 0.8 / 0.875 这几个常见值。改采样点必须重新 down/up，热改不生效。

2.4 让 can0 开机自动起来，别每次都靠手敲

调试阶段手敲没问题，但机械臂一旦进入日常使用，每次都sudo ip link set ...很烦，而且容易忘。两个办法，我都用过。

一是写进 systemd service，After=network.target，ExecStart里放那三行。好处是可以用systemctl restart can-setup快速重置总线，坏处是要处理启动顺序和适配器枚举时序——USB 设备枚举是异步的，服务可能比can0出现得更早，启动就失败了。稳妥的做法是加ExecStartPre=/bin/sleep 2或者用 udev 规则触发。

二是直接用 udev 规则，在适配器插入时自动配置。这个方案更优雅，但 udev 里跑ip命令需要绝对路径，而且不能保证执行顺序，调试起来比较痛苦。我现在偏向第一种，简单直接，出问题也好查。

还有一个权限问题要提一句。默认情况下只有 root 能打开 CAN 套接字，普通用户跑演示程序会报Operation not permitted。解决方式有两种：把接口的所属组改成你的用户组并加读写权限，或者干脆用sudo跑演示。我倾向后者，因为调试阶段用 root 能少一类坑，等稳定了再做权限细化。用sudo跑图形界面程序可能遇到环境变量问题，这个属于另一类坑，不在本篇范围。

3. 第二条命令：构建与零位标定，演示能不能跑起来由它决定

三条命令里，第二条最"虚"，因为它不是一个固定命令，而是一组准备工作，通常表现为"编译 + 标定"两步。README 上往往就一行colcon build或者cmake -B build && cmake --build build，但它背后藏着的依赖、模块、标定流程，才是真正决定成败的部分。

3.1 依赖、内核模块与权限：构建阶段就该一次解决的事

先说要加载的内核模块。SocketCAN 本身是内核自带的，但需要can和can_raw两个模块，部分发行版默认不自动加载。检查方法：

lsmod | grep can

没输出就手动加：

sudo modprobe can sudo modprobe can_raw

这个坑的典型表现是：ip link set can0 type can ...报Operation not supported，或者can0明明存在但一配置就失败。我第一次遇到时以为是适配器坏了，折腾了半天才发现是模块没加载。

再说编译依赖。这类机械臂的上位机程序通常依赖 CAN 通信库（C++ 用 SocketCAN 原生接口，Python 用 python-can）、数学库、以及可能的消息中间件。构建失败最常见的原因是子模块没拉取——很多人 clone 的时候忘了--recursive，编译时报一堆找不到头文件的错误。我现在的固定动作是：clone 完第一件事git submodule update --init --recursive，然后再编译。

编译本身没什么好说的，但有个细节值得提：编译产物和运行时用的库版本必须一致。如果系统里装过多个版本的通信库，运行时可能链接到旧版本，表现是程序能启动但一发包就崩。排查方法是ldd看一下可执行文件链接的实际路径，确认指向你刚编译的那个。

3.2 关节 ID 与 CAN 帧 ID：一张必须先画出来的映射表

这一步是很多人忽略的。总线上 7 个驱动器，每个都要有唯一标识，主机靠帧 ID 区分它们。如果你不知道哪个 ID 对应哪个关节，后面的演示必然乱套——可能出现"想动肘部结果腕部转了"的情况，非常吓人。

我的做法是动手前先画一张表，把它写在纸上贴在工作台旁边：

这张表里的具体数值要以你手上驱动器的实际配置为准，不同方案差别很大，有的是控制帧和反馈帧同 ID 靠数据内容区分，有的是固定偏移。关键是要亲手核对一遍，而不是假设。核对方法：逐个给驱动器上电（一次只上一个），用candump can0观察它主动上报的帧 ID，记下来。这一步花十分钟，能省掉后面几小时的混乱。

3.3 零位、限位与上电顺序：不定零位就上电，撞的是自己的钱

零位标定是整个准备阶段最重要的一步，也是最容易出事故的一步。所谓零位，就是机械臂的"出厂姿态"参考点，所有关节角度都以它为基准。驱动器掉电后编码器如果是增量的，位置信息就丢了，必须重新找零；绝对编码器的驱动器虽然记住位置，但机械装配时的零位偏差仍需校准。

标定的常规流程是：先把机械臂手动摆到设计规定的零位姿态（通常是各关节处于中间位置、整臂竖直或水平伸直，具体看仓库文档），然后运行标定脚本把这些位置写进驱动器。有的方案要求逐个关节标定，有的支持一条命令标定全部。

这里有个必须先确认的事情：标定之前，关节必须是失能（disable）状态。失能状态下电机不出力，你可以用手掰；一旦使能，电机锁死，你想掰都掰不动，强行掰会损伤减速器。所以顺序永远是：上电 → 确认失能 → 手动摆位 → 标定 → 使能。

限位是另一层保护。软件限位写在程序里，硬件限位是机械挡块。我强烈建议第一次跑演示前，把软件限位设得保守一点——比如设计行程是 ±180°，先设成 ±30° 跑通再说。机械臂撞一下的代价，可能是几千块的减速器，也可能是一块被砸坏的屏幕，不值得省这个步骤。

3.4 使能与失能逻辑：把急停做成肌肉记忆

使能（enable）意味着驱动器开始闭环控制，关节会保持当前位置。失能（disable）则是彻底放开。这两个操作在演示程序里通常会自动执行，但你必须知道它们在代码的哪个位置，以及怎么手动触发。

我的习惯是：第一次跑任何新程序，手指永远放在电源开关或者急停按钮上，程序启动后先观察三秒，确认所有关节只是"绷住"而没有乱动，再让它执行轨迹。这个习惯救过我至少两次——有一次是零位符号搞反了，一使能就往反方向顶，手快切了电，只听到一声闷响，没造成损失。

另外，使能之后关节的刚度（对应位置环的 Kp）是可以调的。默认值往往偏硬，第一次跑建议把刚度调到 30% 左右，让机械臂动起来软绵绵的，出问题也不至于撞坏东西。等确认轨迹正确，再逐步加回去。

4. 第三条命令：跑演示，从"关节会动"到"动得对"

到这一步，硬件通了、程序编好了、零位也标了，可以跑演示。命令本身很短，通常长这样：

./openarm_demo --can can0 --freq 500

或者 Python 版本：

python3 -m openarm.demo --channel can0 --rate 500

参数名以你手上仓库为准，但含义大同小异：指定用哪个 CAN 接口、控制频率多少。跑起来之后，正常情况下你能看到终端里滚动打印各关节的角度、速度、电流，机械臂开始做预设动作。

4.1 演示节点内部到底在循环什么

理解这个循环，比会敲命令重要得多。演示程序的核心是一个定时循环，每个周期做三件事：

第一，读。从总线收各关节的反馈帧，解析出当前位置、速度、力矩、温度、错误码。第二，算。根据演示模式（正弦摆动、关节空间插值、末端直线等）算出这一周期 7 个关节的期望位置。第三，写。把 7 个期望位置打包成控制帧，按各自的帧 ID 发出去。

听起来简单，但这里有个时序问题：读和写是有先后还是并发？如果串行执行，先发 7 帧再收 7 帧，一个周期内总线上的时间就是 14 帧的开销。如果并发（读线程 + 写线程），就要处理数据一致性——你算期望位置时用的是上一周期的反馈，这个延迟在低频下无所谓，高频下会影响稳定性。看演示代码时可以特别留意这块，它是你后面自己写控制程序时最值得参考的部分。

4.2 控制周期与总线负载：算一笔 7 关节的账

前面提过一帧大约 135 μs（含最坏位填充）。把不同控制频率下的总线占用算出来，你就明白为什么演示程序默认频率往往不是 1 kHz：

这张表说明两件事。一是 1 kHz 控制频率在 1 Mbps 单向通信下就已经吃满总线，根本留不出反馈的空间，所以纯 1 Mbps 方案想做 1 kHz 闭环是不现实的。二是如果演示程序只发控制帧、靠驱动器主动上报反馈（很多驱动器默认以固定周期上报），那么 500 Hz 是可行的，但余量不大，总线上一旦有重传或错误帧，就可能丢帧。

这也解释了为什么很多方案会往 CAN FD 走。CAN FD 的数据段可以跑到 5 Mbps，同样 8 字节数据，传输时间缩短到原来的五分之一左右，7 个关节的控制帧总耗时能压到 200 μs 以内，这时候再上 1 kHz 才有意义。不过 CAN FD 要求适配器和驱动器都支持，混插是不行的——如果总线上有一个只支持经典 CAN 的节点，整条总线都得退回经典 CAN 模式。

4.3 七自由度冗余：为什么演示程序大多用关节空间正弦而不是末端轨迹

这一点挺有意思。7 自由度相对 6 维任务空间（位置 xyz + 姿态 rpy）多了一个自由度，这就是所谓的冗余。冗余的好处是灵活——同样一个末端位姿，肘部可以有无数种摆法，能绕开障碍；坏处是逆运动学解不唯一，解出来是一条一维流形（零空间），你得额外定规则去选。

演示程序如果直接给末端轨迹，就必须处理这个选择问题，还要保证解在时间上连续（否则关节会跳变），实现复杂度陡增。所以绝大多数官方演示用的是关节空间的正弦摆动——每个关节各自按A·sin(2πft + φ)动，互不干涉，不需要逆解，代码几十行就能写完。这不是偷懒，而是把"验证通信链路和驱动能力"这个目标和"验证运动规划"这个目标明确分开，很合理。

等你把演示跑通、想往上做的时候，第一个要补的就是逆解。常见做法是数值逆解（雅可比迭代）配零空间投影，把冗余自由度约束到某个代价函数最小的方向。这块内容足够单独写一篇，这里只是提醒你：演示能跑不等于运动学没问题，两者是两码事。

4.4 用日志和回放验证这一次跑得对不对

演示跑起来、机械臂在动，不等于跑对了。我判断"跑对了"的标准有三条：一是终端日志里没有错误帧、没有丢帧告警；二是 7 个关节的实际角度曲线能跟上期望曲线，相位滞后在合理范围内（500 Hz 下通常几毫秒）；三是跑完之后ip -details -statistics link show can0里的错误计数没有明显增长。

要做到前两条，得养成记录日志的习惯。演示程序一般支持把每周期的时间戳、期望值、实际值打成 CSV 或者 rosbag 之类的记录文件。跑完拿回来画个图，期望和实际两条曲线叠在一起，一眼就能看出问题：如果实际曲线明显滞后且幅度衰减，说明刚度不够或者控制频率太低；如果某一路完全不动，说明那一路的帧 ID 或驱动器配置有问题；如果出现尖刺，多半是丢帧导致的。

这个习惯的价值在于，它把"感觉机械臂动得挺顺"变成了可量化的事实。后面你做任何改动——换控制频率、调刚度、改轨迹——都能用同一条曲线对比，判断改动是好是坏。

5. 演示跑通之后，现场最容易翻车的几处细节

能跑通演示只是起点，真正投入使用前还有一批问题在等着。这一章列的都是我自己或者身边同行实际遇到过的，按现象分类，方便你对照排查。

5.1 抖动、异响、过流：三种现象对应三类根因

抖动这个现象最典型。很多人第一反应是"通信有问题"，其实大概率是控制参数问题。判断方法很简单：把机械臂摆在静止姿态，不发任何轨迹，只让它保持位置，如果这时候抖，那就是闭环参数问题，跟通信无关；如果只有运动时才抖，才需要怀疑通信或者轨迹。

异响要格外警惕，尤其是周期性、和角度相关的响声。我遇到过一次，某个关节在特定角度区间有轻微咔哒声，一开始没在意，跑了几天之后声音变大，拆开发现是减速器里进了异物。硬件问题越早发现越好，别硬跑。

5.2 总线错误计数上涨和断线重连

跑一段时间后错误计数缓慢上涨，是比"完全不通"更麻烦的问题，因为它不影响功能，但埋着隐患。常见原因有三个：终端电阻只接了一端（短距离能跑，长距离或高频下出错）、某个节点的地电位偏移较大、线缆屏蔽没做好受变频器之类干扰。

排查思路是从物理往上：先量电阻确认 60 Ω，再把总线长度缩短试试，再检查接地，最后才怀疑驱动器。我建议在长时间运行前，先做一次两小时的空跑，记录错误计数的增长曲线。如果两小时涨了几十个，那还可以接受；如果涨了几千，一定要查清楚再上生产。

重连逻辑也值得一提。演示程序通常假设总线一直是好的，一旦 bus-off 就直接崩。实际使用中，电源波动、插头松动都可能导致短暂断线，程序需要有恢复能力。基础做法是：检测到发送失败或接收超时，主动把接口 down 再 up，重新使能关节，然后从当前位置平滑接续。这里面有个细节——重新使能前一定要读一次当前位置作为新起点，否则期望值和实际值偏差太大会直接顶出去。

5.3 长时间运行的温升与力矩衰减

关节电机的力矩能力是随温度衰减的。常温下能持续输出的力矩，绕组温度到 80 度以上可能就剩七成。演示程序跑几分钟看不出来，连续跑一小时就明显了——同样的轨迹，后半段跟不上，位置误差变大。

判断方法是看驱动器上报的温度。大部分驱动器反馈帧里都带温度字段，只是演示程序不一定打印出来。你可以自己加几行代码把它打出来，或者用candump抓原始帧手工解析。如果发现温度持续上升不收敛，要么降低负载，要么加散热，要么把占空比降下来——间歇运动比连续运动友好得多。

6. 把三条命令沉淀成自己的启动流程

跑通一次之后，我建议立刻做一件事：把这三条命令固化成一个脚本或者一套流程文档。理由很实际——你现在记得每一步的细节，两周之后再回来，很可能就忘了当时为什么要先 down 再 up，为什么要先失能再标定。

6.1 一份可直接复用的启动脚本结构

我的习惯是分三段写，每段失败就立刻停，不要往下走：

#!/usr/bin/env bash set -e # 第一段：总线 echo "[1/3] 配置 CAN 总线" sudo ip link set can0 down 2>/dev/null || true sudo ip link set can0 type can bitrate 1000000 sample-point 0.875 restart-ms 100 sudo ip link set can0 up sleep 0.5 # 自检：能读到接口状态才继续 ip -details link show can0 | grep -q "state ERROR-ACTIVE" || { echo "总线状态异常，请检查物理连接" exit 1 } # 第二段：环境自检（不重复编译，只检查产物是否存在） echo "[2/3] 检查程序产物" [ -x ./build/openarm_demo ] || { echo "未找到可执行文件，请先编译" exit 1 } # 第三段：运行演示 echo "[3/3] 启动演示" ./build/openarm_demo --can can0 --freq 500

这个脚本的关键点在set -e和那个自检。set -e保证任何一步失败就整体退出，不会带着半配置状态往下跑——带着DOWN的接口跑演示，报的错会非常迷惑。自检那一步用grep检查状态字符串，是因为接口刚 up 的时候可能还在协商，加个sleep再查更稳。

零位标定我建议单独一个脚本，不要混在启动脚本里。原因很简单：标定需要人手动摆位，混进去容易误触发，一旦程序以为你要标定而后台自动跑了，很危险。

6.2 从演示代码里值得抄走的三样东西

演示代码看起来简陋，但有三块写得比我见过的很多自研代码更靠谱，值得直接搬。

第一是帧的打包和解包。这部分涉及字节序、位域拼接、符号扩展，自己写很容易出错，尤其是不同驱动器协议里多字节字段的大端小端不一致。演示代码里这份映射一般已经验证过了，直接用，别重造。

第二是定时循环的实现。留意它是用sleep还是用绝对时间戳对齐。用sleep的循环会累积漂移，一小时下来可能差好几毫秒；用绝对时间戳的循环（记录起始时间，每次算出下一个目标时刻再睡）不会漂。如果你的演示代码用的是后者，直接抄；如果是前者，建议改成后者。

第三是错误处理的分层。好的演示代码会把"通信错误""驱动器报错""运动学越界"分开处理，而不是笼统地抛一个异常。这在你后面排查现场问题时价值巨大——至少能一眼看出是线松了还是参数给错了。

最后分享一个我自己用的小技巧：每次改动参数或者代码，都在启动脚本旁边记一行注释，写上日期、改了什么、为什么改。三个月后回头看，这一行注释比任何文档都有用——它记录的是当时的判断依据，而不只是结果。机械臂这种软硬件耦合的系统，出问题时的第一现场信息非常宝贵，别指望自己的记性。