本文我将结合自己的经验，梳理无人机/机器人集群通信的必要知识和实战建议。
当下机器人集群通信的趋势是由"窄带串口类数传+自定义数据协议 "转向"大带宽网络通信+抽象通用类协议"，因此本文主要讲的是网络通信。
机器人集群通信架构逐层剖析
无人机集群通信数据通常会经过下面几类层次：
text
应用数据：位置、速度、任务状态
↓
应用协议：MAVLink、自定义消息、ROS 消息
↓
中间件：DDS、ZeroMQ 等（可选）
↓
传输层：UDP 或 TCP
↓
网络层：IP、路由、组播/单播
↓
链路层：Wi-Fi、专用数传、Mesh 链路
↓
物理层：串口、网口、射频、天线这和常见的 OSI 七层模型有关，但在机器人系统中，会话层和表示层往往不单独实现；DDS、ZeroMQ 等中间件则可能夹在传输层和应用层之间，帮助开发者处理发现、连接、序列化和 QoS 等问题。
1. 物理层：网线、网口与串口
物理层关注电气接口和线缆连接，传输的本质是 0 和 1 的 bit 流。无人机集群中常见的接口包括网口（RJ45）、RS-232 串口以及其他串行接口。
数传模块一般会提供串口，有些数传也同时提供多个串口和网口。对于单片机飞控，直接连接和使用数传串口通常比较简单；但对于运行 Linux 的机载计算机，例如树莓派，使用数传提供的网口会更方便地接入集群网络，与其他节点通信。
需要注意，串口或网口只是物理接口，并不等于上层协议。接口中传输的内容还可能是 MAVLink、ROS 序列化消息或其他自定义数据。
2. 数据链路层：数传、无线网卡与网桥
数据链路层主要负责物理地址寻址、数据成帧、流量控制、数据检错和重发等工作。这一层会把连续的 bit 流封装成 frame（帧），规定 0 和 1 如何分成一个个数据包。
这一层常见的是 IEEE 802 局域网标准，其中最常见的包括 IEEE 802.3 以太网，也就是常说的有线网络；以及 IEEE 802.11 无线局域网，也就是常说的 WLAN 或 Wi-Fi。
无线数传可能采用 IEEE 802.11 这类 WLAN 协议。其中，802.11n 通常被称为 Wi-Fi 4，主要工作在 2.4 GHz；802.11ac 通常被称为 Wi-Fi 5，主要工作在 5 GHz；802.11ax 通常被称为 Wi-Fi 6，在效率和速度方面进一步提升。不过，这几类协议的常规传输距离都比较有限。
为了进入 IoT 物联网场景，802 家族还推出了 802.11ah，也就是 Wi-Fi HaLow。它工作在 Sub-1 GHz 频段，例如部分数传设备会采用这一技术，但实际传输距离仍然受设备、天线和环境影响，不能简单按标准名称推断最终覆盖范围。
常见的无线传输协议还包括 Zigbee（IEEE 802.15.4）。它的带宽相对较低，在无人机集群中需要结合具体业务评估。
顺便提一下，如今同时追求较远传输距离、较高带宽以及可组网能力（星型组网或 Mesh 组网）的数传，很多会采用 软件无线电（SDR）实现。软件无线电使用可编程硬件，例如 FPGA、DSP，通过软件编程实现通信协议，而不是完全依赖固定的模拟或数字电路。
3. 网络层：路由与 IP
网络层负责对网络中的数据包进行路由选择。网络层处理的是 数据包（packet），使用 IP 地址区分不同的机器，主要作用是为数据选择和建立通路，常见设备包括路由器和多层交换机。
网络层最常见的协议是 IP。它实现了子网内不同机器之间的互连。在实际使用中，通常需要给每台机器配置 IPv4 地址，并让它们处于可以互通的网段中。
这里重点看一下路由。使用 Wi-Fi 时，通常需要一个路由器作为 AP，其他节点接入 AP，所有消息都经过路由器进行路由和转发。比如 A 机器和 B 机器通信，也可能需要先经过路由器转发，因此通信延迟和网络稳定性会受到这个中心节点影响。
有些采用 星型组网 的数传与此类似：需要一个中心数传负责路由，其他节点的消息可能都经过中心节点转发。它的优点是结构清晰、管理方便，缺点是节点通常需要处在中心节点的通信范围内，中心节点也可能成为网络瓶颈或单点故障。
另一种组网方式是 Mesh 组网。它不需要专门的中心路由器，网络中的节点都可以参与路由，自组织形成网络，并在部分链路变化时进行调整。无线网卡的 Ad-hoc 模式，以及部分支持 Mesh 的数传，都属于这一思路。
Mesh 的优点是没有单一中心节点，节点之间可以直接或多跳转发；缺点是网络结构和路由维护更加复杂，实际带宽、延迟和稳定性需要通过具体设备与飞行环境测试。相关组网方式可参考：Ubuntu Ad-Hoc 组网通信。
4. 传输层：TCP、UDP 与端口
从传输层开始，主要就是软件部分。传输层关注的是不同机器上的应用程序之间如何通信，最常用的协议是 TCP 和 UDP。
每个应用程序都可以在网卡上使用一个端口号。传输层关注的就是端口到端口的通信，处理的数据单位通常称为 数据段（segment）。
TCP 和 UDP 都需要知道通信双方的 IP 地址和端口。
- TCP 是面向连接的点对点通信：服务器和客户端通常需要先建立连接，之后才能收发数据，并且 TCP 具有确认、排序和重传机制，以保证数据可靠传输。
- UDP 不需要事先建立连接，应用程序只负责向本机某个端口发送数据，或从其他设备的某个端口读取数据；因此，UDP 除了点对点通信外，还支持多播（组播）和广播，加入组播群的节点都可以收到群内发送的消息。
因此，TCP 是可靠的传输协议，但连接和重传机制可能带来额外开销；UDP 不保证送达和顺序，但支持多点传输，适合对实时性要求较高的状态数据。实际编程中，通常通过 socket 套接字完成 TCP 和 UDP 通信。
一些消息队列，例如 ZeroMQ 或 MQTT，会对 TCP 的连接过程进行封装，使应用使用起来更接近 UDP 的效果 ：开发者不必直接处理所有客户端和服务器连接细节，也可以使用一对多的通信模型。我的 swarm_ros_bridge 就是使用 ZeroMQ 对 TCP 进行封装，实现多机器人应用程序之间的通信。
TCP 还是 UDP？
1. 从通信质量看
如果不关心实时性，只要求数据不能丢弃，那么 TCP 更可靠。如果只关心数据流的实时性、更加看重低延迟，那么 UDP 可能更合适。不过，在很多局域网场景中，TCP 的速度也已经足够快。
2. 从连接方式看
如果事先不知道所有机器人的 IP，只知道应用程序使用的端口，可以使用 UDP 组播：所有机器人加入同一个组播地址，向组播群发送消息，其他节点就能收到。例如，多机地面站接入飞机时，飞机 IP 可能并不固定，此时 UDP 组播会比较方便。
3. 从带宽占用看
UDP 组播或广播 会向组内其他节点发送消息，某些节点可能并不需要这些数据，因此会造成带宽浪费。相比之下，TCP 点对点通信可以减少不必要的数据传输。
但如果某个节点发送给其他节点的内容完全相同，例如向 N 个节点广播自己的位置，那么 UDP 组播可能更节省带宽。TCP 需要为每一对连接分别发送一份相同的数据，而组播可以让网络中的链路和设备避免重复传输同一份消息。
在星型组网中，所有消息还可能需要经过中心路由节点转发，因此 TCP 和 UDP 的实际带宽差异还与网络拓扑有关。对于数据量不大的场景，TCP 点对点通信通常已经能够满足需求。
5. 会话层与表示层
按照传统 OSI 七层模型，会话层负责建立、管理和终止会话，表示层负责数据表示、编码和转换。但在现代机器人网络应用中，这两层通常不会以独立协议的形式单独实现，很多功能被操作系统、传输层库、中间件和应用层协议吸收，因此可以视为被简化或合并。
6. 应用层：HTTP、DNS、SSH 与 MAVLink
应用层是纯软件部分，关注应用程序之间传输的报文格式和协议。常见的应用层协议包括 DNS、HTTP、SSH，以及无人机系统中常见的 MAVLink。
多机器人之间传递的信息完全可以自行定义 ：开发者规定每一帧报文中各字段的含义、数据类型和长度，也可以采用通用协议标准。MAVLink 就是无人机系统中常见的轻量级消息协议。
我的 swarm_ros_bridge 传输的就是序列化后的 ROS 消息，并且为每个 ROS 消息或话题单独使用端口。可以理解为，它的应用层协议就是 ROS message 的定义方式。
有时，传输层和应用层之间还会加入一个 中间层。例如 DDS（Data Distribution Service）就是以数据为中心的中间件协议和 API 标准。DDS 将应用程序从操作系统、网络传输和底层数据格式等细节中抽象出来，并通过不同编程语言提供统一的概念和 API，使应用程序能够跨操作系统、语言和处理器体系结构交换信息。
底层细节，例如数据线格式、节点发现、连接、可靠性、传输选择、QoS 和安全性等，都可以由中间件负责管理。swarm_ros_bridge 也属于这一类中间层，目的是简化应用层开发，避免应用程序直接操作传输层协议。严格来说，中间层最终仍然服务于应用层通信。
ROS机器人集群未来的通信协议
前面介绍了 TCP、UDP、ZeroMQ、ROS 消息和 DDS。结合无人机/机器人集群的实际需求，我对后续通信架构有几个比较明确的判断。
1. 不建议直接手写原始 TCP/UDP 通信
直接调用 socket 手写 TCP 或 UDP，当然可以把消息发出去，但它更像是"把传输层接口接通"，并没有解决集群通信真正麻烦的部分：
- 节点如何自动发现，不依赖提前写死所有机器人的 IP；
- 如何抽象一对多、组播和广播；
- 如何管理节点上线、下线、重连和网络变化；
- 如何按话题或业务类型控制可靠性、频率、压缩和加密；
- 如何让 Python、C++ 等不同语言的节点使用一致的接口。
如果每个项目都重新手写一套发现、连接、重传和消息分发逻辑，最终很容易变成"每个项目一套私有协议"。因此，原始 TCP/UDP 更适合作为底层能力，而不适合作为无人机集群应用直接依赖的完整通信抽象。
2. 不建议把 ROS 自带的多机通信直接当作最终方案
ROS 2 的 DDS 通信非常适合单机多进程，也能在一定条件下完成多机通信。但在机器人集群规模扩大、网络环境复杂之后，直接把所有机器都放进同一个 ROS 通信域，会遇到一些工程问题：
- DDS 的发现机制会产生额外的发现流量和状态维护开销；
- 多台机器人上的节点、话题、服务和参数同时暴露，容易造成话题和节点管理混乱；
- 默认通信边界不够清晰，需要额外依赖
ROS_DOMAIN_ID、命名空间、QoS 和网络配置进行隔离； - 对跨机器人通信而言，哪些话题应该跨网传输、以什么频率传输、是否需要压缩，往往需要额外的桥接或过滤层；
- 当图像、点云和高频状态数据同时存在时，仅靠 ROS 的默认通信方式，很难精细控制跨机器人的带宽、压缩、频率和可靠性。
因此，这里的判断不是说 ROS 2 或 DDS "不能多机通信"，而是说：不建议把 ROS 2 默认的 DDS 网络发现和全量话题暴露，直接作为大规模机器人集群的跨机通信架构。更合理的方式是把 ROS 2 限制在单机内部，跨机器人部分增加明确的通信边界、话题筛选和协议转换。
3. 强烈推荐关注 Zenoh
Zenoh 官网：https://zenoh.io/
Zenoh 的诞生，与台湾 Zenoh/Cyclone DDS 相关团队在实际工程中对 DDS 的反思有关：传统 DDS 的发现机制在多机器人、跨网段和无线网络环境下可能带来较大的 overhead，组播发现和端口管理也容易造成通信边界不清晰、网络流量复杂等问题。Zenoh 正是在这类痛点上发展起来的，试图提供更适合分布式机器人集群的通信抽象。
我更看好 Zenoh 成为机器人集群未来的重要通信协议。Zenoh 的设计目标不是简单替代一个 socket，而是把发布/订阅、查询/应答、服务调用、节点发现、路由和数据传输统一到一个更适合分布式系统的抽象中。
它的理念与 ROS 的使用方式比较接近：可以按 key expression 组织数据，使用发布者和订阅者完成话题通信 ，也可以通过 queryable 和 querier 实现类似服务端 serve 与客户端 call 的请求/响应机制。这样，上层应用关注的是"我需要什么数据、提供什么服务"，而不是每个节点具体连哪一个 IP、使用哪一个端口。
Zenoh 的价值主要体现在以下几个方面：
- 发现机制更适合分布式网络：支持组播 scouting，也支持基于 gossip 的节点发现和信息传播；当网络不适合使用组播时，还可以通过显式配置的 router 或 peer 建立连接；
- 通信边界更清晰：通过 key expression 和路由配置决定哪些数据跨机器人、跨网络传输，而不是让所有 ROS 话题默认互相可见；
- 端口和拓扑更容易管理：在 router/client 部署方式下，机器人应用可以连接到统一的 Zenoh router 服务端口，常见配置是 TCP 7447，不需要为每个话题手工分配一个端口；具体端口数量仍取决于部署模式和配置，不能简单理解为任何模式下永远只有一个端口；
- 传输能力更完整：支持发布/订阅、查询/应答、不同可靠性级别、批处理、分片、压缩、TLS 和访问控制等机制；
- 跨语言支持较好：提供 Rust、C/C++、Python、TypeScript 等语言接口。尤其是 TypeScript 支持，对 Web 前端、可视化和远程运维界面比较友好；
- 部署轻量：Zenoh 的核心实现基于 Rust，官方提供可直接运行的二进制组件，没有其他依赖，不需要装巨大的ROS，适合部署到机载计算机、边缘设备和路由节点。
Zenoh 的出现，也与机器人领域对 DDS 发现机制开销、跨主机发现流量、端口管理复杂以及通信边界不清晰等问题的长期反思有关。包括 Cyclone DDS 生态中的开发者和机器人通信实践者，都在推动更可控、更适合跨网络部署的通信方案。更准确地说，这是对现有 DDS 多机部署痛点的工程回应，而不是简单的"某个团队因为不满而重新开发协议"。
所以，我对未来机器人集群通信的建议是：ROS 2 负责单机内部的节点、算法和工具生态，Zenoh 负责跨机器人、跨网络的数据交换；必要时通过 Zenoh-ROS 2 bridge 做边界转换。这样既可以保留 ROS 2 的开发效率，又能对跨机器人通信进行更细粒度的路由、压缩、频率和安全控制。
我未来也将发布一个 Zenoh + ROS 2 的多机通信 bridge，用于探索这套架构在无人机集群中的实际效果，敬请期待。