折腾完手头这四台树莓派我终于把多台树莓派主机通信这件事理清楚了。如果你在网上搜过相关话题大概率会看到一堆零散的方案有人用网络调试助手测UDP有人在ROS2里配DDS还有人直接拿杜邦线把板子的串口、SPI、I2C连起来。方案太多反而容易懵因为每种通信方式背后对应的场景完全不同。这篇文章就把我实际部署中验证过的方案、踩过的坑、以及选型逻辑一次性说清楚覆盖局域网UDP通信、硬件串口/SPI/I2C/CAN直连、ROS2多机通信这几条主要路线适合正在搭树莓派集群、小车编队、分布式传感器节点或者单纯想搞懂多块板子之间到底怎么高效说话的玩家参考。1. 多机通信选型先想清楚数据从哪来到哪去再谈协议很多人一上来就问用TCP还是UDP要不要上ROS2这其实把顺序搞反了。通信方案不是越高级越好而是越匹配场景越好。我接手过的项目里因为选错通信方式导致返工的情况并不少见所以这一节先把不同通信方式的适用范围讲透后面再展开实操。1.1 不同距离和场景下的通信方案对照树莓派之间的通信本质上只有两条路走网络或者不走网络。走网络又分局域网和跨公网不走网络则是通过GPIO引脚直接进行硬件级通信。通信方式传输介质典型距离速率量级适用场景UDP/TCP以太网/WiFi局域网内几十到几百米Mbps-Gbps多机数据交换、实时控制、视频流MQTT/WebSocket网络跨公网取决于带宽远程监控、物联网平台接入UART串口杜邦线/排线板间1-2米内115200bps-数Mbps树莓派与单片机、简单双机通信SPI杜邦线/PCB走线板间0.3米内10Mbps以上高速传感器、显示屏、短距高速主从通信I2C杜邦线/PCB走线板间0.5米内100kbps-3.4Mbps多从设备传感器总线、低速配置CAN双绞线几十米到上千米最高1Mbps车载/工业多节点实时控制这张表看着简单但选型时最容易被忽略的是距离和节点数。比如I2C在板内通信很稳定一旦用杜邦线拉长到30厘米以上信号完整性就会下降而UART虽然只有两根数据线但点对点通信时抗干扰能力比I2C好不少所以树莓派和STM32、Pico这类单片机协作时我几乎首选UART。1.2 为什么我大部分场合选UDP而不是TCP这是所有新手都会纠结的问题。我的结论是树莓派多机局域网通信UDP是默认选项TCP只在特定场景才需要。原因有三点。第一UDP无连接省掉了TCP三次握手和四次挥手的开销。多机场景下如果每台设备都要和另外三台维持TCP长连接连接管理的复杂度和心跳开销会随着节点数平方增长。第二UDP支持广播和组播一台树莓派可以直接广播一条消息让局域网内所有树莓派同时收到TCP做不到这一点。第三很多实时控制类数据比如小车底盘速度指令、传感器采样值允许偶尔丢包丢了下一帧补上就行TCP的重传机制反而会造成延迟抖动。TCP适合的场景是数据必须完整到达且顺序不能乱比如文件传输、数据库同步、远程配置下发。如果你在做这类需求TCP当然没问题但如果你只是想让多台树莓派互相发传感器数据和控制指令UDP加应用层简单确认机制就够了。提示选型时记住一句话——宁可在应用层为UDP补可靠机制也不要在网络层被TCP的延迟卡死。很多工业级中间件比如ROS2的DDS底层也大量使用UDP的变种就是这个道理。2. 先把基础网络环境配稳固定IP、主机名和调试工具多台树莓派走网络通信第一道坎是网络环境。你会发现如果每台设备的IP是DHCP动态分配的重启一次路由器IP就变了代码里写死的IP地址全部失效排查起来非常痛苦。所以任何多机项目开始之前先花十分钟把每台树莓派的IP固定下来。2.1 树莓派固定IP的两种方式树莓派官方系统Raspberry Pi OS和Ubuntu Server的配置方式不一样别搞混了。树莓派OS基于Debian修改/etc/dhcpcd.confsudo nano /etc/dhcpcd.conf在文件末尾加上interface eth0 static ip_address192.168.1.101/24 static routers192.168.1.1 static domain_name_servers192.168.1.1 interface wlan0 static ip_address192.168.1.102/24 static routers192.168.1.1 static domain_name_servers192.168.1.1Ubuntu Server 22.04及以上包括树莓派5装Ubuntu使用netplansudo nano /etc/netplan/50-cloud-init.yamlnetwork: version: 2 ethernets: eth0: dhcp4: no addresses: - 192.168.1.103/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [192.168.1.1]然后应用配置sudo netplan apply注意固定IP之前先用ip addr确认网卡名称是eth0还是别的名字树莓派5上有些系统会把有线网卡命名为end0照抄配置会失败。2.2 用主机名互访代码里不用写死IP固定IP之后还有一步值得做配置/etc/hosts。我在每台树莓派上都把其他几台的主机名和IP写了进去这样通信代码里就可以直接写主机名而不是IP。sudo nano /etc/hosts添加类似这样的内容192.168.1.101 rpi-master 192.168.1.102 rpi-node1 192.168.1.103 rpi-node2 192.168.1.104 rpi-node3如果你不想手动维护hosts文件还可以靠mDNSavahi直接用主机名.local访问。树莓派OS默认装了avahi-daemonUbuntu Server需要手动装sudo apt install avahi-daemon -y之后ping rpi-master.local能通就说明mDNS生效了。我在实际项目中两种方式混用固定主机名映射用于关键节点mDNS用于临时加入的调试设备。2.3 用网络调试助手快速验证通路热搜词里提到了两台电脑udp通信使用网络调试助手这个工具在树莓派多机调试时同样好使。我常用的套路是先用网络调试助手装在一台电脑上和第一台树莓派做双向UDP收发确认网络链路没问题再去写正式的通信代码。网络调试助手的核心设置就四个协议类型UDP/TCP、本地IP、本地端口、目标IP、目标端口。比如树莓派A监听5005端口电脑上把目标IP设为树莓派A的IP、目标端口设为5005点打开然后发送一串测试数据树莓派A上用nc -ul 5005监听能看到数据就说明链路通了。# 树莓派上监听UDP 5005端口 nc -ul 5005如果是调试视频流这类数据可以顺手抓包看一眼。热搜词里有树莓派OV5647摄像头和luvcview我在调试摄像头推流时就用tcpdump确认摄像头数据是否真的从树莓派发出去了sudo tcpdump -i eth0 udp port 5005 -XX看到连续的数据包再排查接收端的解码问题看不到包就回头查网络配置。这一条排查链路能帮你省掉大量的无效排查时间。3. Python实现多树莓派UDP通信从基础收发到自动发现网络环境稳了接下来是重头戏怎么写通信代码。树莓派上最顺手的语言是Python标准库里的socket就能搞定UDP/TCP不需要装任何第三方库。下面这两段代码是我项目里的基础模板直接从树莓派A发送消息到树莓派B。3.1 一段能直接跑的UDP收发代码发送端树莓派Asender.pyimport socket import time DEST_IP 192.168.1.102 # 树莓派B的IP DEST_PORT 8888 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) for i in range(10): message fhello from rpi-master, seq{i}.encode(utf-8) sock.sendto(message, (DEST_IP, DEST_PORT)) print(fsent: {message}) time.sleep(1) sock.close()接收端树莓派Breceiver.pyimport socket LOCAL_IP 0.0.0.0 # 监听所有网卡 LOCAL_PORT 8888 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((LOCAL_IP, LOCAL_PORT)) sock.settimeout(5) print(flistening on {LOCAL_PORT}...) while True: try: data, addr sock.recvfrom(1024) print(freceived from {addr}: {data.decode(utf-8)}) except socket.timeout: print(timeout, still listening...)这里重点解释两个细节。第一接收端bind的IP写的是0.0.0.0而不是具体IP意思是监听本机所有网卡。如果你写死成192.168.1.102一旦这个IP换了或者走了WiFi网卡就收不到数据了。第二sendto每次发送的是一条独立的数据报。UDP保留了消息边界所以接收端每次recvfrom拿到的就是发送端一次sendto的完整内容这一点和TCP的字节流模型完全不一样理解了它你就明白为什么UDP天然适合做消息通信。3.2 多机自动发现广播包与心跳固定IP解决了地址不变的问题但如果你要做一个真正能自动组网的系统比如三台树莓派组成的传感器集群谁先开机谁就能被发现需要的是自动发现机制。UDP广播是最简单的实现方式。广播发现代码所有节点同时运行import socket import time import json BROADCAST_ADDR 192.168.1.255 DISCOVERY_PORT 9999 # 本机信息 node_info { hostname: socket.gethostname(), ip: get_local_ip(), role: sensor_node } sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.bind((, DISCOVERY_PORT)) sock.settimeout(2) def get_local_ip(): s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) try: # 不需要真正发送数据只是通过连接过程获取本机IP s.connect((8.8.8.8, 80)) ip s.getsockname()[0] finally: s.close() return ip # 定时发送广播心跳 while True: # 发送本机信息 sock.sendto(json.dumps(node_info).encode(utf-8), (BROADCAST_ADDR, DISCOVERY_PORT)) # 接收其他节点的广播 try: data, addr sock.recvfrom(1024) info json.loads(data.decode(utf-8)) print(fdiscovered node: {info[hostname]} at {info[ip]}) except socket.timeout: pass time.sleep(3)这里有几个细节值得注意。广播地址要写你所在子网的广播地址如果网段是192.168.1.x广播地址就是192.168.1.255如果路由器开了AP隔离很多家用路由器默认开启广播包在WiFi客户端之间会被隔离收不到广播就检查这个设置。另外广播包会被子网内所有设备收到如果你有多个项目在同一网段跑最好给不同项目设置不同的DISCOVERY_PORT避免互相干扰。心跳机制是另一块核心。真实系统中节点可能随时掉线不能只靠收到过广播就认为节点永远在线。我给每个节点维护一张在线表每次收到心跳就刷新对应节点的最后活跃时间超过N秒没收到心跳就把节点标记为离线。这个逻辑用字典实现即可几十行代码搞定效果却非常稳定。3.3 实测中踩过的坑坑一端口被占用或者重启服务时报错。如果上次程序异常退出socket可能处于TIME_WAIT状态再次bind同一端口会报Address already in use。解决办法是bind之前设置SO_REUSEADDRsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)坑二树莓派多个网卡导致发到错误的网卡。我之前有台树莓派同时插着网线和WiFisocket默认路由可能走WiFi但目标设备在有线网段结果消息一直发不出去。排查办法是绑定发送网卡的IP或者在系统路由表里设置静态路由。最简单的方式是创建socket后显式bind到指定网卡的IPsock.bind((192.168.1.101, 0)) # 0表示随机端口坑三局域网WiFi丢包。2.4GHz WiFi在干扰严重的环境里丢包率可能高达5%UDP不重传应用层要自己做超时重发。我给关键控制指令做了三发一确认机制发送方连发三次相同消息接收方收到后回复ACK发送方收到ACK就停止重发。这个机制比TCP轻量但对付WiFi丢包足够了。4. 不依赖网络的硬通信串口、SPI、I2C与CAN如果你的树莓派集群在无网络环境工作或者对时延和实时性要求极高比如多台树莓派控制机械臂关节指令延迟超过1ms就会抖那就要走硬件通信。树莓派GPIO引脚支持UART、SPI、I2C外加通过SPI扩展CAN这四条路线我分别在项目里实测过。4.1 UART串口树莓派与树莓派/单片机的传统链路UART串口是树莓派和单片机协作最常用的方式。树莓派3B/4B/5上串口引脚是GPIO14TXD和GPIO15RXD但默认情况下这些引脚被分配给了蓝牙模块直接操作会踩坑。启用硬件串口的步骤sudo raspi-config # Interface Options - Serial Port - # 登录shell是否可用选No # 硬件串口是否启用选Yes执行完重启后检查串口设备ls -l /dev/serial*正常会看到/dev/serial0 - ttyAMA0这个软链接。树莓派4B/5上用/dev/serial0比直接写/dev/ttyAMA0更保险因为系统版本不同底层tty设备名可能不同而serial0永远是那个可用的硬件串口。两端连线树莓派A GPIO14(TXD) - 树莓派B GPIO15(RXD) 树莓派A GPIO15(RXD) - 树莓派B GPIO14(TXD) 树莓派A GND - 树莓派B GND注意TXD接RXD、RXD接TXD这个是交叉接法新手的第一个报错基本都来自这里。另外两块板子必须共地GND连GND否则电平参考点不一致会出现乱码或者完全收不到数据。测试串口最简单的方式是用minicomsudo apt install minicom -y minicom -D /dev/serial0 -b 115200树莓派A上开minicom树莓派B上执行echo hello /dev/serial0A端能看到字符就说明通路正常。实际写Python程序时用pyserial库import serial ser serial.Serial( port/dev/serial0, baudrate115200, timeout1 ) ser.write(bhello from rpi-master\r\n) data ser.readline()常见的坑是权限问题。非root用户打开/dev/serial0会报Permission denied需要把当前用户加入dialout组sudo usermod -a -G dialout $USER重启登录后生效。热搜词里有一条树莓派pico控制舵机这个场景我做过树莓派4B通过UART向树莓派Pico发送角度指令Pico收到后驱动舵机。Pico端用MicroPythonfrom machine import Pin, PWM, UART import time uart UART(0, baudrate115200) uart.init(115200, bits8, parityNone, stop1) servo PWM(Pin(0)) servo.freq(50) while True: if uart.any(): data uart.readline() try: angle int(data) duty 65535 * (angle / 180 * 0.1 0.025) servo.duty_u16(int(duty)) except ValueError: passUART点对点的优势在于代码逻辑简单、双方都不需要IP、延迟稳定缺点是只能双机通信不能一个串口挂多台设备严格说UART支持多机但树莓派硬件串口一般不做这种用法。4.2 SPI与I2C一主多从短距高速SPI和I2C适合树莓派作为主机挂载多个从设备可以是传感器也可以是其他树莓派配置为从设备模式。这两者的核心区别在于SPI是全双工、高速、四线制MISO/MOSI/SCLK/CSI2C是半双工、低速、两线制SDA/SCL各有侧重。树莓派上启用SPI和I2Csudo raspi-config # Interface Options - SPI - Enable # Interface Options - I2C - Enable启用后用命令查看设备ls /dev/spidev* # 输出类似 /dev/spidev0.0 /dev/spidev0.1 sudo apt install i2c-tools -y sudo i2cdetect -y 1i2cdetect会扫描I2C总线上的设备地址如果某个从设备地址冲突或者接线不对这个命令能最快暴露问题。我在项目里用I2C挂了三块IMU传感器MPU6050结果三块默认地址都是0x68冲突导致全部读不到数据。解决办法是给其中两块板子把AD0引脚拉高地址变成0x69再用0x68, 0x69, 0x69区分——熟悉I2C地址配置的人都知道这个套路但第一次遇到确实容易卡住。SPI没有地址概念用CS片选引脚区分设备。多台树莓派如果都支持SPI从机模式可以组成一主多从结构但树莓派的SPI从机模式配置比较复杂我一般在树莓派和STM32、FPGA这类硬件之间用SPI树莓派之间很少用。4.3 CAN总线更适合多节点实时控制的工业通信热搜词里can通信can芯片出现了好几次。CAN总线在工业现场和车载环境是统治级的存在因为它支持多达上百个节点、传输距离超过千米、带优先级仲裁机制非常适合多台树莓派做分布式实时控制的场景比如多台小车协同避障。树莓派本身没有CAN控制器需要外接CAN控制器芯片和收发器。最经典的组合是MCP2515SPI转CAN控制器加TJA1050CAN收发器。我之前用过带MCP2515和TJA1050的集成扩展板直接插树莓派GPIO排针就能用。接线要点# 板子上的VCC接3.3V或5V看模块说明 # GND接GND # SPIMOSI(GPIO10)、MISO(GPIO9)、SCLK(GPIO11)、CS(GPIO8) # INT接到GPIO25用于中断可选内核启用CAN驱动并配置接口sudo nano /boot/config.txt # 添加一行 # dtoverlaymcp2515-can0,oscillator16000000,interrupt25 sudo reboot # 启动CAN接口 sudo ip link set can0 up type can bitrate 500000 sudo ip link set can0 txqueuelen 1000如果树莓派5上路径不是/boot/config.txt而是/boot/firmware/config.txt注意区分。测试两个节点通信# 节点A candump can0 # 节点B cansend can0 123#DEADBEEFCAN总线两端必须各接一个120欧姆终端电阻否则信号反射会导致通信极不稳定。很多现成的CAN模块自带120欧姆电阻和跳线帽只需要在总线的物理两端各保留一个电阻中间节点不需要——这个点我最初忽略了结果三节点测试时偶尔丢帧加了终端电阻就好了。4.4 布线与供电翻车实录硬件通信最大的坑不是代码是物理层。我分享三个真实翻车案例。案例一共地问题导致串口乱码。两块树莓派没有连GND只连了TXD和RXD结果接收到的数据全是乱码。原因很简单两块板子的地电平不一样导致逻辑电平的0和1判断出错。接上GND后问题立刻消失。案例二杜邦线太长导致SPI不稳定。SPI时钟频率设成10MHz时用20厘米的杜邦线连接树莓派和SPI传感器数据时不时出错。把频率降到1MHz后就稳定了。经验法则杜邦线越短越好超过15厘米就不要追求高速率。案例三舵机启动拉低电压导致CAN丢帧。树莓派4B通过CAN控制一个舵机舵机启动瞬间电流很大如果树莓派和舵机共用一个5V电源电压跌落会导致CAN控制器工作异常。最后给舵机单独供电才解决。这个案例也解释了为什么工业控制里的通信系统和动力系统一定要隔离供电。5. ROS2多机通信树莓派机器集群的工程化方案如果你的多台树莓派要组成一个机器人集群比如AGV小车编队、机械臂协同直接在socket上写应用层协议很快会变得难以维护。这时候ROS2几乎是绕不开的中间件。5.1 为什么树莓派5UbuntuROS2成为主流组合ROS1的设计里必须有一个master节点负责管理所有话题通信master挂了整个系统就瘫了。ROS2底层换成了DDSData Distribution Service实现了完全的分布式自动发现每个节点启动时会通过UDP广播自己的存在订阅相同话题的节点会自动建立连接不需要中心服务器。这个特性对多台树莓派组成的集群太合适了——随便哪台节点掉线其他节点之间仍然能正常通信。树莓派5性能更强装Ubuntu Server 22.04/24.04再跑ROS2完全没有压力。树莓派4B跑ROS2问题也不大但编译大型包的时候会明显偏慢建议直接用预编译的二进制包。安装ROS2 Humble对应Ubuntu 22.04的核心命令sudo apt install ros-humble-ros-base -y source /opt/ros/humble/setup.bash echo source /opt/ros/humble/setup.bash ~/.bashrc5.2 多机配置的四个关键步骤想让两台树莓派上的ROS2节点互通必须完成四件事。我按实际操作顺序列出来照做就行。第一步配置/etc/hosts。和前面UDP通信一样DDS虽然能自动发现但发现过程依赖节点名称解析。把每台树莓派的IP和主机名写进/etc/hosts能显著减少发现失败的概率。第二步时间同步。DDS的消息带有时间戳如果各节点系统时间差太多某些QoS策略下消息会被判定为过期而丢弃。装chrony做时间同步sudo apt install chrony -y sudo systemctl enable chrony sudo systemctl start chrony第三步设置相同的ROS_DOMAIN_ID。如果同一个网络里有多组树莓派在跑ROS2必须用domain id隔离否则不同组的话题会串。在每台设备的~/.bashrc里加export ROS_DOMAIN_ID1第四步处理防火墙。如果启用了ufwDDS的自动发现端口默认被挡会出现两个节点能看到自己但看不到对方的典型症状。最省事的配置是放行DDS所需端口或者干脆在测试环境先关闭防火墙sudo ufw disable # 测试环境生产环境请按需放行端口5.3 验证多机topic在一个终端运行ros2 run demo_nodes_cpp talker另一台树莓派上运行ros2 run demo_nodes_cpp listener如果配置正常listener会持续打印收到的话题内容。如果收不到按这个顺序排查# 1. 看节点是否能发现对方 ros2 node list # 2. 查看话题列表 ros2 topic list # 3. 看topic是否真的有数据在流动 ros2 topic echo /chatter如果你能看到对方节点但话题没有数据多半是QoS不匹配。ROS2的QoS里发布者的可靠性和订阅者的可靠性必须兼容比如一个RELIABLE一个BEST_EFFORT就会不互通。这个话题比较细只能说尽量保持两端默认策略一致别轻易改。6. 排错经验多树莓派通信故障排查链路通信出问题的时候最怕的是瞎猜乱试。我用的是一套从物理层到应用层的逐层排查方法效率很高分享出来。6.1 分层排查法按顺序来物理层检查线是否插紧、电源是否充足、指示灯是否正常。我见过太多网络不通最后发现是网线松了或者电源适配器功率不足导致系统反复重启。链路层ping是最快的连通性测试。如果ping不通检查IP配置、子网掩码、网线连接。如果ping通但延迟波动大大概率是WiFi干扰或者供电不稳。ping -c 5 192.168.1.102传输层ping通不代表端口能通。用nc测试指定端口# 树莓派B上监听UDP 8888 nc -ul 8888 # 树莓派A上发送 echo test | nc -u 192.168.1.102 8888如果nc不通抓包看数据是否到达了网卡sudo tcpdump -i eth0 udp port 8888应用层代码里加上打印日志确认发送是否真的执行、接收是否阻塞。Python的socket如果没设timeoutrecvfrom会永久阻塞程序看起来像死机了实际上是等数据等不到。6.2 几个高频故障案例的完整排查过程案例A串口乱码。现象minicom里显示乱码。排查链路检查波特率。两端必须一致我以为自己设的都是115200结果一端是115200一端是9600。检查接线。TXD和RXD有没有交叉。检查共地。检查是不是接到了蓝牙串口上。运行ls -l /dev/serial*确认用的是/dev/serial0而不是/dev/serial1。最终定位第二个原因和第四个原因叠加。案例BUDP收不到数据但ping通。现象网络能ping通UDP发送端不报错接收端一直没有数据。排查链路接收端netstat -unap确认程序真的在监听8888端口。抓包发送端tcpdump -i eth0 udp port 8888接收端同样抓包。如果发送端有包出去但接收端抓不到检查路由、防火墙、AP隔离。如果接收端网卡上能抓到包但程序收不到检查bind的IP是不是0.0.0.0程序是否启动在错误的网络命名空间。最终定位接收端bind到192.168.1.102但系统重启后IP变了新IP变成了.103程序绑定的 IP 上没有数据到达。案例CCAN通信丢帧。现象candump偶尔能收到消息但经常丢帧或者完全没数据。排查链路ip -details link show can0确认接口是否upbitrate是否正确。ip -s link show can0查看错误计数如果TX errors和RX errors不断增加基本可以确定是物理层问题。检查终端电阻。两端是否各有120欧姆。检查总线线缆是否过长、是否使用了双绞线。最终定位中间节点把终端电阻拔了导致总线上三节点时阻抗不匹配。6.3 供电噪声与无线通信的诡异相关性最后说一个很隐蔽的问题。我在做树莓派小车编队的时候出现过这样的现象小车电机的PWM频率越高树莓派之间的UDP通信丢包越严重最后甚至WiFi断连。排查了很久才明白电机驱动的大电流瞬间拉低了整个系统的5V电压树莓派供电不足导致WiFi模块不稳定。解决方案有两条一是把电机供电和树莓派供电完全分开用独立的DC-DC模块二是在电源输出端并联大电容2200uF以上缓冲瞬态电流。从那以后我做的任何带电机/舵机的项目都严格执行动力电源和逻辑电源分开的原则通信问题一下子少了很多。这也解释了为什么工业控制领域总强调隔离。低速的数字信号、高速的网络信号、大功率的动力信号走同一套供电系统出问题只是时间问题。树莓派虽然是个开发板但一旦进入多机协作的真实场景它面对的物理挑战和工业PLC是一样的。写在最后我现在的标准做法折腾了这么多通信方案之后我现在启动一个新项目会按照这样的固定套路来先判断数据量、延迟要求、节点数量、是否需要跨公网确定用网络通信还是硬件通信如果走网络统一用UDP加简单的应用层确认机制把每台树莓派的IP固定并配置好/etc/hosts如果涉及多台树莓派做机器人类的协同任务直接用ROS2省掉自己造中间件的功夫如果要在无网络环境做实时控制UART或CAN优先但一定先把供电和共地问题解决。说实话树莓派之间的通信本身并不难难的是搞清楚自己到底需要哪种通信方式以及出了问题怎么高效地定位。希望这篇整理能帮你少走一些弯路。如果你在复现过程中遇到其他奇怪的现象建议从第6节的排查链路开始逐层往下看大多数问题都出在那些你以为不可能出错的地方。