1. 动手之前，先把这条通信链路的“骨架”看明白

1.1 PWM舵机和总线舵机：为什么这么多种“舵机”玩法不一样

做舵机控制之前，最容易犯的错就是把所有舵机当成同一种东西。常见的舵机有两类：传统PWM舵机和总线舵机。

PWM舵机靠信号线上脉冲宽度决定角度，一根信号线最多控制一个舵机。你要接十个舵机，就得拉十根控制线，中间还得配PWM驱动器，接线和代码都容易乱。总线舵机就不一样了，它内部集成了解析芯片，所有舵机挂在同一条串口总线上，通过数据帧里的ID字段区分“这条指令是发给谁的”。串联起来以后，一根线就能把几十个舵机都管住，机械臂、六足机器人这类结构复杂的项目基本都用这种方式。

这篇文章里我主要展开的是总线舵机配合树莓派串口的场景。有人可能会问：总线舵机的调试不是用USB转串口在电脑上就能做吗？为什么偏偏要提树莓派？因为真正做机器人项目时，控制端一定是个嵌入式的、能跑Ubuntu的板子，树莓派恰好是这类环境里最普及的选择。也就是说，你要搞清楚的其实不只是“舵机怎么通信”，而是“在Linux环境下，串口设备如何正确暴露给应用层、如何绕过各种权限和复用问题、最后才谈得上帧协议”这一整条链路。

1.2 链路里的“隐形参与者”：电平、共地、半双工，一个都不能少

很多人在树莓派上控制舵机失败，第一反应是帧协议不对，其实先出问题的往往是物理链路。我用一个表格把容易忽略的环节整理出来：

这里重点说下供电。总线舵机在空载和堵转时电流差距非常大，堵转瞬间电流可能冲到2A以上。树莓派的5V引脚能输出的电流本身有限，带动几个舵机基本必崩。我现在的习惯是：系统电源线和大电流舵机电源线分开走，在舵机电源入口并一个470µF以上的电解电容，减少电压跌落对UART电平的干扰。共地我还会单独用一根粗线连到树莓派的GND，而不是依赖树莓派的供电线顺便带一下地，这样通信稳定性会明显好一截。

2. Ubuntu下激活树莓派串口：不是插上就能用的

2.1 设备节点的来龙去脉：为什么有两个串口设备

树莓派的SoC里不止一组UART，粗略分有两类：PL011某个增强型UART，以及迷你UART。在部分树莓派型号上，PL011的引脚被分配给了蓝牙模块，GPIO14和GPIO15只能连接到迷你UART。迷你UART有个硬伤：波特率跟随核心时钟变化，CPU频率一波动就容易出乱码。这也是为什么很多人刷了Ubuntu后，用GPIO14/15发串口数据总是不稳定。

在Ubuntu系统里，进入系统后你通常会看到两个设备：/dev/ttyAMA0和/dev/ttyS0。看名字挺简单，但它俩到底谁是蓝牙、谁是GPIO串口，取决于设备树配置。为了让GPIO14/15获得稳定的PL011，需要显式修改启动配置文件，把蓝牙的占用释放掉。

如果你运行的是Ubuntu 22.04及更新版本，配置文件路径一般是/boot/firmware/config.txt，使用方式类似树莓派OS。

2.2 解锁串口的配置步骤和验证方法

我建议在config.txt的文件末尾统一加这几行：

[all] enable_uart=1 dtoverlay=disable-bt

enable_uart=1是系统开关，告诉固件允许把UART功能暴露给GPIO；dtoverlay=disable-bt则把蓝牙相关的PL011占用解除，让这个稳定的串口控制器重新服务于GPIO14/15。

修改完成后重启，执行下面几条命令验证：

ls -l /dev/serial* dmesg | grep -i ttyAMA

正常情况下应该看到/dev/serial0 -> ttyAMA0这样的符号链接。/dev/serial0是个友好别名，它会自动指向当前活跃的串口设备，后续写程序时直接固定用这个路径，比硬编码ttyAMA0更安全。

接着做一次最基础的回环测试：找根杜邦线，把GPIO14和GPIO15直接短接，然后用stty配置波特率并发送数据：

stty -F /dev/serial0 1000000 raw -echo echo "hello" > /dev/serial0

如果回环测试能收到自己发出去的内容，说明底层串口已经通了。注意，回环测试要先把树莓派接到舵机上，不然电平会被外部元件干扰。

2.3 普通用户权限和ModemManager这个“捣乱分子”

Ubuntu下最常见的开串口失败原因是权限不足。默认串口设备属于dialout组，如果你不是这个组的成员，打开设备时会直接报PermissionError。把自己加到组里：

sudo usermod -aG dialout $USER

改完后一定要重新登录，或者注销再进桌面，组权限才会生效。我用groups命令检查过很多次，问题基本都是没有重新登录。

另一个容易被忽略的是ModemManager。默认Ubuntu系统里有一个ModemManager服务，它的工作就是监听串口设备，试图识别是不是调制解调器。这个服务会在你每次打开串口时插入探测请求，导致舵机收到一堆莫名其妙的字节。处理办法是把它移除或禁止，最省心的是卸载掉：

sudo apt remove modemmanager

如果项目环境不允许卸载，也可以用udev规则把ttyAMA0排除在ModemManager的探测列表之外，但复杂度高一些，我还是推荐直接移除。

3. 总线舵机数据帧拆解：每个字节都要有明确含义

3.1 通用帧结构长什么样

不同厂商的总线舵机协议会有细微差别，但底层范式高度一致。理解了最通用的那一套，换成其他牌子时只需要改指令编码和校验算法。我以某款典型的TTL总线舵机为例，它的数据帧分为六个区域：

舵机内部相当于一张寄存器表。常用寄存器包括扭矩开关、目标位置、目标速度、当前位置、当前速度等。举个例子，假设目标位置寄存器地址是0x2A，占2个字节，取值范围0到1000；目标速度寄存器地址是0x2C，占2个字节。那么让1号舵机转到500、速度1000，数据帧就是：

0x55 0x55 0x07 0x03 0x01 0x2A 0x01 0xF4 0x03 0xE8 0x14

逐个解释：0x07是长度，代表从0x03到最后的校验字节一共7个字节；0x03是写寄存器指令；0x01是舵机ID；参数区从0x2A开始，就是“目标位置高字节0x01、目标位置低字节0xF4、目标速度高字节0x03、目标速度低字节0xE8”。0x14是校验。

位置值500换算成16进制就是0x01F4，所以按高位在前、低位在后的顺序拆成两个字节；速度1000同理就是0x03E8。

3.2 校验和算法的计算技巧

校验和算法看着不起眼，实际上项目里80%的通信故障都跟校验算错有关。我这里采用的算法是：把长度字节、指令字节、ID字节、所有参数字节累加，取低8位，然后用255减去这个累加值，最后的结果就是校验字节。更直白的说法是：加入校验字节后，整段数据“长度+指令+ID+参数+校验”的累加和应该等于255。

用刚才的帧验证一遍：

0x07 + 0x03 + 0x01 + 0x2A + 0x01 + 0xF4 + 0x03 + 0xE8 = 0xEB 0xFF - 0xEB = 0x14

0x14正好就是校验字节。接收端收到整帧后做同样的累加，如果得到0xFF，说明帧有效。

要注意的是，这只是一个常见方案。有的舵机用XOR校验，有的用CRC16，有的要求累加结果为0。换舵机前一定要把自己手里那份手册上的校验公式逐字核对，特别是“是否包含长度字节”“参数个数按什么进制参与计算”这些细节，就差一个字节，整条总线的设备都会忽略你的指令。

3.3 波特率、舵机ID和回复时序，背后的逻辑比你想的多

总线舵机常见的波特率有115200和1000000两种。出厂默认波特率如果和你程序里配置不一致，帧一样会石沉大海。我习惯的做法是写一个小扫描函数，依次尝试115200、1000000、921600等几个候选波特率，用“读取舵机版本号”指令探活，一旦收到有效回复就锁定波特率。这个思路对刚拿到手的二手舵机特别有用，因为你根本不知道上一手把它设置成了多少。

舵机ID同理，很多项目里有几十个舵机，ID冲突会造成多发舵机同时响应，总线乱得一塌糊涂。我建议给每个舵机贴上物理标签，同时把ID列表存成配置文件，别靠记忆。批量修改ID时，先把要改的舵机单独挂到总线上，避免ID冲突时两个舵机同时回复。

还有一类参数特别容易忽略：舵机“回复等待时间”和“响应延迟”。有些总线舵机在收到指令后默认延迟一小段时间才回复，这个参数在数据手册里叫“反馈延迟”或者“返回延迟时间”。如果你的程序发出指令后立刻读串口，很可能读到的是上一个指令的残留数据，或者什么也读不到。

4. 用Python把舵机控制写成一套可靠的小工具

4.1 串口初始化中的那些细节

控制舵机最常用的Python库是pyserial。我的初始化代码长这样：

import serial SERVO_PORT = "/dev/serial0" BAUD = 1000000 def open_servo_serial(): s = serial.Serial() s.port = SERVO_PORT s.baudrate = BAUD s.bytesize = 8 s.parity = serial.PARITY_NONE s.stopbits = serial.STOPBITS_ONE s.timeout = 0.1 s.write_timeout = 0.1 s.open() s.reset_input_buffer() s.reset_output_buffer() return s

有两个地方值得展开讲。第一，timeout不要设成0。总线舵机的回复延迟通常只有几毫秒，但如果刚好遇到供电波动或者舵机正在处理上一帧指令，回复就可能晚到。timeout设为0.1秒，线程只会多等几十毫秒，代价完全可以接受；设成0会陷入“永远等待”的状态，程序直接卡死。第二，刚打开串口时一定要清空缓冲区。树莓派上电阶段可能收到过舵机发出的异常数据，不清空会导致后续解析时把残帧当成新帧，数据错位越来越严重。

4.2 帧构造和接收解析的代码实现

把校验和计算封装成一个函数：

def calc_checksum(parts): total = sum(parts) & 0xFF return (0xFF - total) & 0xFF def build_packet(cmd, servo_id, params): length = len(params) + 4 parts = [length, cmd, servo_id] + list(params) checksum = calc_checksum(parts) return bytes([0x55, 0x55] + parts + [checksum])

len(params) + 4对应“指令1字节 + ID1字节 + 参数N字节 + 校验1字节”，和前面协议定义完全吻合。

接收端解析时，要先找帧头，再根据长度字段读取后续字节，最后校验。这里最常见的问题是只读了length个字节就当作完整帧，其实那只是帧体长度，不包含帧头。我写的解析函数如下：

def read_frame(ser): while True: b = ser.read(1) if not b: return None if b[0] == 0x55: b2 = ser.read(1) if b2 and b2[0] == 0x55: break lenb = ser.read(1) if not lenb: return None length = lenb[0] rest = ser.read(length - 1) if len(rest) != length - 1: return None frame = [0x55, 0x55, length] + list(rest) if (sum(frame[2:]) & 0xFF) != 0xFF: return None return frame

这里sum(frame[2:])把长度字节一直到校验字节全部累加，必须等于0xFF，否则就丢帧。做法上我选择返回None而不是抛出异常，调用方可以根据业务场景决定是重发指令还是报错。

4.3 一个可以直接跑的来回摆动脚本

有了上面两个函数，控制舵机就很简单了：

import time def send_command(ser, cmd, servo_id, params=None, wait_reply=False): if params is None: params = [] pkt = build_packet(cmd, servo_id, params) ser.write(pkt) ser.flush() if wait_reply: return read_frame(ser) return None def set_position(ser, servo_id, pos, speed=1000): pos = int(pos) speed = int(speed) params = [0x2A, (pos >> 8) & 0xFF, pos & 0xFF, (speed >> 8) & 0xFF, speed & 0xFF] send_command(ser, 0x03, servo_id, params) if __name__ == "__main__": ser = open_servo_serial() # 先开扭矩，否则舵机只是锁紧状态，不会响应位置指令 send_command(ser, 0x03, 1, [0x28, 0x01]) time.sleep(1) for pos in [0, 250, 500, 750, 1000, 750, 500, 250, 0]: set_position(ser, 1, pos, speed=800) time.sleep(1) ser.close()

这个脚本里有个细节：开扭矩的0x28是扭矩寄存器地址，写入0x01代表开启。如果漏掉这一步，有些舵机会把位置指令收下但不执行，表现就是“舵机完全没反应但是报ACK成功”。很多入门项目失败就失败在这一步。

4.4 读取舵机当前状态和多舵机控制的扩展

读取位置同样简单。读取寄存器的指令是0x04，参数区填写起始地址和读取长度：

def read_position(ser, servo_id): reply = send_command(ser, 0x04, servo_id, [0x2E, 0x02], wait_reply=True) if reply is None: return None # 回复帧结构: 55 55 LEN 04 ID 2E 数值高 数值低 校验 data_hi = reply[6] data_lo = reply[7] return (data_hi << 8) | data_lo

这里reply的下标位置取决于完整帧从帧头开始的排列方式。回复帧里第0和第1字节是帧头，第2字节是长度，第3字节是指令，第4字节是ID，第5字节是寄存器地址，第6和第7字节是数据。如果你的舵机回复帧结构不同，按实际手册调整即可。

多舵机控制时，我一般分两种场景：如果希望多个舵机同时动作，就连续发多个单播指令，发完后再统一等待回复，而不是“发一个等一个”，否则串口空闲时间太长，动作同步性很差；如果是调试阶段，就更建议逐个发送并确认回复，定位问题时能一下看出哪个舵机没响应。广播指令0xFE适合做整组初始化，比如开关扭矩，但不适合做位置控制，因为所有舵机都往同一个目标位置走，回传数据也会全部混在一起。

5. 实测中最容易让人崩溃的几种情况

5.1 舵机完全无响应，先查什么

舵机一点反应都没有的时候，我从不动手改协议，而是按顺序做物理层检查：

1. 确认/dev/serial0存在，并且符号链接指向ttyAMA0而非ttyS0。
2. 确认自己在dialout组里，且已经重新登录。
3. 用回环测试确认树莓派本身能收发。
4. 用万用表量舵机供电电压，空载时是否在舵机要求的电压范围内。
5. 确认接线：舵机RX接树莓派GPIO14，舵机TX接树莓派GPIO15，公共线共地。

绝大多数时候，走到第3步就会发现是树莓派侧的问题，不是舵机的问题。尤其常见的是把config.txt改了没重启，或者改错了路径，系统根本没读到你的串口配置。

5.2 能发不能收：问题多半出在“单线半双工”上

树莓派的两个串口引脚是独立收发，GPIO14负责TX，GPIO15负责RX。但很多总线舵机是单线半双工设计，只有一个DATA引脚，收发复用在同一条线上。你如果直接把树莓派的TX、RX分别接到舵机的DATA和某个GND上，或者把两个独立引脚并联到同一个DATA点上，就会出现“能发送但永远收不到回复”的怪现象。

这种舵机的正确接法一般有两类：一类是接受通过外部方向信号控制收发状态的TTL转接板，板子把方向控制引出来，由你或固件决定何时切换到接收模式；另一类则是使用官方适配器，适配器内部已经处理了反向收发逻辑。我的建议是：如果舵机明确标记了DATA、RX、TX三个引脚，那就直连；如果只有DATA，老老实实加方向控制，不要试图用GPIO引脚硬顶。

判断方法也简单：发送一条“读位置”指令后，立刻用逻辑分析仪看DATA线上的电压波形。如果能看到舵机方向翻转后送回来的一串脉冲，说明物理层通，问题在你的串口程序没有及时转为接收模式；如果只能看到树莓派发出的单向脉冲，说明接线或方向逻辑有问题。

5.3 高负载下串口丢帧和乱码

树莓派跑Ubuntu，后台任务多、CPU调度紧张时，串口数据丢帧率明显上升。这里很容易分不清是程序问题还是硬件问题。我的排查经验是优先看波特率来自哪个串口控制器。如果设备节点是ttyS0，也就是迷你UART，那丢帧基本是固定的，因为迷你UART的波特率跟随核心时钟，CPU变频时误差会扩大。解决办法就是回到第2章，确保GPIO串口用的是PL011，也就是ttyAMA0。

即使确认了PL011，Python线程被调度器切走也会导致读取超时。一个有效但简单的改善方式是把串口读取放到独立线程，用队列把收到的帧抛给业务逻辑去处理。另外，把read_frame里的超时调得宽松些，避免在主程序多个短线程并发访问串口时出现“半截帧”的情况。

5.4 舵机偶发抽搐或角度偏差

如果舵机能动，但动作不连贯、偶尔抽搐一下，优先怀疑两个方向：供电波动和信号电平不达标。供电波动我之前提过，在舵机电源入口并电容是个成本很低的解法。信号电平则是树莓派3.3V输出和舵机5V输入的兼容问题，某些舵机对高电平阈值要求偏高，3.3V正好卡在临界值，温度稍微变化就触发不了。此时在信号引脚上外接一个简单的电平转换模块，或者用电平转换器把3.3V升到5V，通常马上就能稳定下来。

另外，线束太长也会在高波特率下产生反射。把波特率从1000000降到115200试试，如果异常消失，说明布线长度超过了这个波特率下的信号完整性限制，解决方案是缩短线长、换双绞线或者降低速率，不要指望靠软件修复信号质量。

最后

调试总线舵机这么多年，我最大的体会是：别一上来就啃协议，先把“树莓派能不能可靠收发”这件事钉死。我现在的固定流程是，每次开始舵机项目，先在电脑上跑一次回环测试，再用hexdump -C /dev/serial0抓一把总线数据做对照，确认系统侧完全干净后，才把舵机接进去。这样一旦后续出问题，“系统配置”这个变量已经被排除了，排查范围瞬间缩小到物理接线和协议逻辑。

如果你也刚把树莓派刷成Ubuntu，记得先检查/boot/firmware/config.txt里enable_uart=1和dtoverlay=disable-bt是不是真的生效，再谈帧协议。总线舵机和树莓派串口这套组合，摸透之后机械臂、云台、六足机器人的基础通信层都能直接复用，但最初的半天时间，确实值得花在把串口底层彻底理顺上。