多机器人集群网络通信协议分析

本文讨论的是多机器人网络通信各层的情况和协议。

每个机器人连接一个数据传输通信模块（以下简称为数传，也泛指市面上的图传或图数一体的通信模块），数传之间进行组网来传递信息。

根据ISO的划分，网络通信的OSI模型分为从低到高的7层。

参考：

ISO七层协议模型架构、各层的解析及其协议_肥嘟嘟的左卫门的博客-CSDN博客

计算机网络各层涉及协议(超级详细） - 知乎 (zhihu.com)

分布式之远程通信协议_一个想进阶的java菜鸟的博客-CSDN博客 

1、物理层（网线、网口、串口）

电气接口、线缆连接。如网口(RJ45)、RS232串口等。这一层只和硬件有关，传输的是0和1的bit流。

数传一般提供串口，但有的数传也同时提供多个串口和网口。对于单片机飞控来说，连接和使用数传的串口是比较容易的。但是对于有linux系统的上位机（如树莓派）来说，使用数传上的网口会更加方便地连接到集群内其他个体。

2、数据链路层（数传、无线网卡、网桥）

该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。这一层中将bit流封装成frame帧，即规定了0和1的分包形式。

这一层常见的协议是IEEE 802局域网标准，其中最常见的有IEEE 802.3以太网（也就是常说的有线网），IEEE 802.11无线局域网（也就是常说的WLAN或者WiFi）。

无线数传可能使用的是IEEE 802.11这种WLAN协议，其中802.11n也俗称WiFi4（2.4GHz），802.11ac也俗称WiFi5（仅在5GHz频段工作），802.11ax也俗称WiFi6（速度更快）。但这三种协议传输距离都很近，为了进军IoT物联网市场，802家族还推出了802.11ah协议，俗称WiFi-HaLow（比如阿木实验室的homer数传就是采用的这种协议），其工作在Sub-1GHz频段，但传输距离也只有1km。

常见的无线传输协议还有Zigbee（IEEE 802.15.4），但是组网不灵活，带宽很低。

顺便提一下，如今同时满足传输距离远（10km以上）、带宽高（10Mb以上）、可组网（星型组网或mesh组网）的数传大都是由软件无线电（SDR）实现的，即用可编程的硬件（比如FPGA、DSP）通过软件编程而非电路（模拟或者数字电路）的形式来实现（上述？）通信协议。

3、网络层（路由器，IP）

对网络内的数据包进行路由选择。网络层处理的是数据包（packet），使用的是IP地址（区分不同的机器），作用是路由（为每个数据选择和建立一条通路），常见的设备是路由器、多层交换机。

网络层最常见的协议就是IP协议，其实现了子网内不同机器间的互连，但是实现细节并不需要我们关心，你只需要知道把每台机器设置固定IPv4的IP，并且使得它们的IP在一个网段就行。

如何判断两个IP地址是否在同一个网段？什么是子网掩码？ - 知乎 (zhihu.com)

这里重点提一下路由。用过WiFi的都知道，一般需要有一个路由器作为AP，其他节点接入AP，所有消息都经过路由器来路由和转发。比如A机器和B机器通信，也一定是先通过路由器转了一手，因此延迟较大（100ms），而且依赖路由器这个中心节点。

现在一些星型组网的数传就是类似这种架构，需要一个地面端数传来路由，所有天空端数传的消息可能都是经过地面端数传来路由和转发的，延迟较大，而且所有节点必须保持在地面端中心节点的通信范围内，其优点是结构稳定可靠。

还有一种组网方式叫mesh组网，不需要一个专门的节点作为路由器，所有的节点都具有路由功能，自组织形成网络，自愈合。比如无线网卡的Ad-hoc模式，还有一些数传也具有mesh组网的功能。其优点是无中心节点，直接点对点传输延迟小（1ms）；缺点是网络结构可能不太稳定，带宽也会比星型网络小一些。

ad-hoc可以参考：ubuntu Ad-Hoc组网通信_adhoc组网_集智飞行的博客-CSDN博客

4、传输层（TCP、UDP，端口）

从这层开始，就是纯软件部分了。传输层关注的是各个机器上的各个应用程序之间通信的问题，最常用的就是TCP和UDP协议。

每一个应用程序都会在网卡注册一个端口号，该层就是端口与端口的通信，处理的数据单位是数据段（segment）。

TCP协议和UDP协议都需要知道应用程序的IP和端口。区别是TCP协议是面向连接的点对点连接，服务器和客户端应用程序必须都在线而且先建立连接，才能进行数据收发，而且还有数据重发的机制保证数据一定传输给对方。而UDP协议不需要建立连接，应用程序只负责向本机的某个端口发送数据或者从别机的某个端口读取数据，而不管有没有程序在接收或者发送，因此UDP协议除了点对点通信外，还支持多播（组播）、广播，即加入组播群的节点都能收到群内所有其他节点的消息。

显然，TCP是可靠的传输协议，缺点是略慢，只能点对点。UDP协议是不可靠的传输协议，支持多点传输。编程中使用socket套接字来进行TCP和UDP通信。

然而有一些消息队列MQ(message queue)，比如ZeroMQ或者MQTT，将TCP的连接过程封装了一下，让用户使用起来也具有UDP那样的效果，比如不关心是否有客户端、服务器在连接，支持一对多传输等。我的swarm_ros_bridge就是采用了ZeroMQ对TCP的封装来实现多机器人应用程序之间灵活的通信：

集群多机ROS通信中间件：swarm_ros_bridge_ros 中间件_集智飞行的博客-CSDN博客

机器人集群多机间通信是采用UDP还是TCP好呢？

1. 从通信质量来看

如果不关心数据实时性，而只要求数据不能丢弃，那么TCP更可靠。如果只关心数据流的实时性，看重低延迟，那么UDP可能好一些（TCP其实也不慢）。

2. 从连接方式来看

如果事先不知道所有机器人的IP，只知道程序用的端口，那么应当用UDP的组播，即所有机器人都加入这个组播地址，往组播群里发消息，则其他个体都能收到。比如做一个多机地面站，接入飞机的IP可能事先并不确定，此时应当用UDP组播。

3. 从通信带宽占用来看

UDP组播/广播由于向群里所有其他个体都发送了消息，可能有些个体并不需要知道这些消息，这造成了带宽的浪费。相比之下，TCP点对点通信就减少了这种带宽的浪费。

但是，如果某个体和其余个体通信的内容都是一样的，比如要向N个其他节点广播自身的位置，那UDP组播更节省带宽。因为UDP组播情况下每条链路、每个设备都最多只会经过一次，因此占用的带宽不会随着广播域的增大而扩大。而TCP需要为每两两连接的个体发送一次相同的数据包。

比如下图，黄色方块代表星型组网中的路由器，所有消息都要经过它转发，那么TCP显然比UDP多发了一次相同的数据。

 

也许，为每个机器人设置一个不同的UDP组播群，需要它信息的邻居加入这个组播群，这是比广播或者TCP通信更好的方法？

对于数据量不大的情况，TCP点对点通信完全足以胜任。

参考：​​​​​​ UDP广播和TCP链接传送数据，哪个更节省带宽？ - 知乎 (zhihu.com)

 UDP广播和TCP链接传送数据，哪个更节省带宽？ - 知乎 (zhihu.com)

5、会话层

该层被弃用。

6、表示层

该层被弃用。

7、应用层（HTTP、DNS、ssh、mavlink）

这一层是纯软件部分，关注的是应用程序之间传输的报文的格式协议。常见的协议比如DNS协议（解析域名，运行在UDP协议之上，使用端口号53），HTTP协议（浏览器网页协议）。多机器人之间传递信息的应用层协议完全可以自己定义，比如自己规定报文中每帧的内容含义。也可以用一些通用的协议标准，比如mavlink（常用于无人机之间）。

我的swarm_ros_bridge其实传输的就是序列化(serialize)后的ROS消息，并且为每一个ROS消息/话题单独开了一个端口。可以理解为其应用层协议就是ROS message的定义方式。

有时候，传输层和应用层之间还会加一个中间层，比如DDS（Data Distribution Service）就是以数据为中心的中间件协议和API标准。DDS将应用层程序从操作系统，网络传输和低级数据格式的详细信息中抽象出来。以不同的编程语言提供了相同的概念和API，从而允许应用程序跨操作系统，语言和处理器体系结构交换信息。底层细节，如数据线格式、发现、连接、可靠性、协议、传输选择、QoS、安全性等都由中间件管理。

swarm_ros_bridge也属于中间层，都是为了简化应用层的开发，避免繁琐的直接对传输层协议的操作。本质上，中间层也属于应用层。