ros2--大数据包丢帧问题
问题
两台主机A,B,A主机ping B很快,B主机ping A很慢?
带宽(Bandwidth)
-
定义:指网络通道在单位时间内能传输的最大数据(比特)量,通常用来衡量网络的传输能力。
-
单位:比特每秒(bps)、千比特每秒(Kbps)、兆比特每秒(Mbps)或吉比特每秒(Gbps)。
-
作用:
-
带宽越高,网络传输数据的速度越快(例如下载文件、视频流更流畅)。
-
但带宽≠实际网速,实际速度还受延迟、拥塞、设备性能等因素影响。
-
-
例子:
-
100Mbps 的宽带理论上每秒可传输 100 兆比特(约12.5兆字节)的数据。
-
1. 物理层面的“通道”
-
有线网络:如以太网电缆、光纤等物理介质,带宽受介质本身的物理特性限制(如铜线的频率衰减、光纤的光信号损耗)。
-
无线网络:如 Wi-Fi、5G 等无线电频段,带宽受频谱宽度、干扰、信号强度等因素影响。
2. 逻辑层面的“通道”
-
协议层划分:在同一个物理介质上,可通过多路复用技术(如频分、时分、码分)划分多个逻辑通道。
-
例如:Wi-Fi 的 2.4GHz 频段可分割为多个信道(Channel 1/6/11),每个信道是一个独立的逻辑通道。
-
-
虚拟网络:如 VPN、VLAN 或软件定义网络(SDN)创建的虚拟通道,带宽受底层物理网络和调度策略限制。
3. 网络协议中的“通道”
-
传输层通道:如 TCP/UDP 连接。一条 TCP 连接的带宽受拥塞控制算法、窗口大小等影响。
4. ROS 2 中的“通道”
-
DDS 通信层:ROS 2 基于 DDS(如 Fast DDS、Cyclone DDS),每个 Topic 或 Service 对应 DDS 的发布/订阅通道。
-
带宽限制因素:DDS 的 QoS 策略、共享网络介质、本地回环(
lo
)接口的性能等。
-
-
实时性影响:即使物理带宽充足,通道的延迟或抖动也可能影响有效传输能力。
例子:
-
ros2 topic bw
测量的实际是 DDS 在某个 Topic 上占用的逻辑通道带宽。 -
该命令通过订阅指定 Topic,统计 单位时间内接收到的数据比特量,从而计算带宽。
ros查看带宽的命令
ros2 topic bw <topic_name>
在 ROS 2 中,ros2 topic bw
命令仅适用于 Topic,不能直接用于 Service 或 Action,原因如下:
1. 为什么 ros2 topic bw
不支持 Service/Action?
-
Topic 是持续单向数据流(发布/订阅模型),适合统计带宽(如每秒传输的数据量)。
-
Service 是请求-响应模型(双向,单次调用),没有持续的数据流,带宽统计无意义。
-
Action 虽然是长期交互(目标+反馈+结果),但其底层由多个 Topic 组成(如
/_action/feedback
、/_action/status
),但ros2 topic bw
无法直接统计整个 Action 的带宽。
ros带宽排查
ros需要排查带宽一般是在进行image(图像)或者视频发布的时候,因为数据多,数以每次传输的数据包的大小就越大,需要的带宽也就越大,所以网络传输速率也就越低。
eg:发布sensor_msg/msg/Image:
原始数据图像:
经过数据压缩之后的图像:
指标 | /image_raw (原始图像) | /image_raw/compressed (压缩图像) |
消息大小 | 固定 614.46 KB (≈0.61 MB) | 固定 0.05 MB (≈50 KB) |
传输速率(bw) | 持续下降至 ~350 KB/s | 稳定在 ~1.55 MB/s |
消息频率 | ~9 Hz (与之前一致) | ~30 Hz (与之前一致) |
带宽效率 | 低(大消息+低频率) | 高(小消息+高频率) |
网卡信息查看
lo (本地回环接口--虚拟网卡)
-
状态:
<LOOPBACK,UP,LOWER_UP>
-
这是一个回环接口(虚拟接口,用于本地通信)。
-
UP
表示接口已启用。 -
LOWER_UP
表示物理链路已连接(虽然是虚拟接口)。
-
-
MTU: 65536(最大传输单元,支持大容量数据包)。
-
队列策略 (qdisc):
noqueue
(无排队,立即处理数据包)。 -
状态:
UNKNOWN
(回环接口的特殊状态,实际工作正常)。 -
MAC 地址:
00:00:00:00:00:00
(全零,是回环接口的默认地址)。
2. enp2s0 (有线以太网接口)
-
状态:
<NO-CARRIER,BROADCAST,MULTICAST,UP>
-
NO-CARRIER
表示没有检测到物理网线连接(未插网线或交换机未通电)。 -
BROADCAST
和MULTICAST
表示支持广播和多播。 -
UP
表示接口已软件启用,但物理链路未通。
-
-
MTU: 1500(标准以太网帧大小)。
-
队列策略 (qdisc):
fq_codel
(公平队列算法,用于流量管理)。 -
状态:
DOWN
(因无物理连接,实际不可用)。 -
MAC 地址:
00:e0:9d:86:04:30
(网卡的硬件地址)。
3. wlp3s0 (无线网卡接口)
-
状态:
<BROADCAST,MULTICAST,UP,LOWER_UP>
-
UP
和LOWER_UP
表示接口已启用且物理链路正常(已连接 Wi-Fi)。 -
DORMANT
模式表示接口空闲但保持连接(可能未主动传输数据)。
-
-
MTU: 1500(标准无线网络帧大小)。
-
队列策略 (qdisc):
noqueue
(无排队,常见于无线接口)。 -
状态:
UP
(接口正常工作)。 -
MAC 地址:
28:d0:ea:9e:1b:c8
(无线网卡的硬件地址)。
MTU
MTU(Maximum Transmission Unit,最大传输单元) 是网络接口一次能传输的最大数据包大小(以字节为单位),超过这个值的数据包会被分片(fragmented)。
数据包单位换算
字节(Byte)
单位 | 缩写 | 换算关系 | 示例 |
---|---|---|---|
千字节 | KB | 1 KB = 10³ B = 1000 B | 1 个文本文件 ≈ 10 KB |
兆字节 | MB | 1 MB = 10⁶ B = 1000 KB | 1 首 MP3 ≈ 3 MB |
吉字节 | GB | 1 GB = 10⁹ B = 1000 MB | 1 部电影 ≈ 2 GB |
太字节 | TB | 1 TB = 10¹² B = 1000 GB | 1 块硬盘 ≈ 1 TB |
查看无线网网络性能
信号强度参考值
dBm 值 | 信号质量 |
-30 to -50 | 优秀(靠近路由器) |
-50 to -60 | 良好 |
-60 to -70 | 一般 |
< -70 | 差(可能丢包) |
原因分析
指标 | /image_raw (原始图像) | /image_raw/compressed (压缩图像) |
消息大小 | 固定 614.46 KB (≈0.61 MB) | 固定 0.05 MB (≈50 KB) |
传输速率(bw) | 持续下降至 ~350 KB/s | 稳定在 ~1.55 MB/s |
消息频率 | ~9 Hz (与之前一致) | ~30 Hz (与之前一致) |
带宽效率 | 低(大消息+低频率) | 高(小消息+高频率) |
不同主机之间使用无线发布和订阅话题消息时,wlp3s0的MTU为1500Byte=1.5KB,而原始图像单个数据包就614.46KB,所有614.46/1.5=409.64个数据包进行传输,订阅段需要订阅409.64次,才能获取一个完整的数据包,就会降低订阅的频率;而经过压缩的图像单个数据包只有50KB,50/1.5=33.33个数据包,所以最终导致的订阅到的频率原始图像频率低,压缩图像频率高。
这也是订阅原始图像时,没有实时图像的原因。
bw持续降低的原因:网络数据堵塞。
TCP堵塞:网络中的数据流量超过其承载能力,导致路由器/交换机缓冲区溢出,进而引发数据包丢失、延迟增加、吞吐量下降的现象。
网络延迟:网络延迟(Network Latency)是指数据从发送端传输到接收端所需的时间,通常以毫秒(ms)为单位。
-- 数据量大--》导致堵塞(丢包)--》导致网络延迟--》带宽和频率降低。
数据的堵塞会导致数据网络延迟增加,进而导致接收的带宽和频率降低。
解决办法
链接
其实,在硬件条件固定,或者修改有限之后,有些情况下还是不能达到实时订阅sensor_msg/msg/Image图像的要求。
所以,我尝试订阅压缩之后的CompressImage,再在本地转为Image发布。
虽然性能相比于没有压缩的有所提高但是还是不能达到要求,换了性能更好的wfi也不行。
大数据传输是导致网络延迟变大是ros本身未解决的问题。
所以针对大数据传输需求,选择有线连接是最好的。
比如image发布和订阅问题:
1,同一个主机上发布和订阅,ros机制使用共享内存,所以很快;
2,即使不同主机之间,使用有线连接也可以大大提高数据传输的速度。
而我们的相机一般是直接插入机器人的控制系统,也就是相机获取图像数据之后,数据就直接进行机器人控制系统处理并进行发布,我们一般只需要在机器人本地进行订阅即可,如果真的要在不同主机之间,且机器人不要动,可以选择有限;如果机器人移动,选择wifi,那就需要选择信号强的wifi。但是如果需要无线,又需要大数据,高频率的数据交互,现在的ros怕是“有心无力”呀!