为什么你的 SLAM 系统一传图像就“卡成 PPT"？搞视觉 SLAM 或远程监控开发的朋友，大概率都经历过这种崩溃瞬间：机器人本地跑得好好的，算法帧率稳定，一旦开启 WiFi 将摄像头图像和激光雷达点云传回上位机，整个系统立刻“抽风”。Rviz 里的点云更新严重滞后，控制指令延迟飙升，甚至直接断开连接。很多人第一反应是优化算法代码或升级主控 CPU，但折腾半天发现，真正的瓶颈往往在最不起眼的地方——网络带宽被原始传感器数据“吃”光了。这并非危言耸听。我们来算一笔账：一张普通的 640x480 RGB 图像，未压缩时单帧约 0.9 MB。若以 30Hz 发布，仅这一路视频流就需要约 216 Mbps 的带宽。而点云更是“带宽杀手”，一帧包含 10 万个点的sensor_msgs/PointCloud2消息，若包含 XYZ 坐标和 RGB 颜色，大小轻松突破 1.6 MB。以 10Hz 发布，就需要 128 Mbps。两者相加，总需求超过 340 Mbps。看似千兆 WiFi 绰绰有余，但现实很骨感。WiFi 的标称速率是物理层极限，受信号衰减、同频干扰及 TCP/IP 协议开销影响，实际稳定有效带宽往往只有理论值的 30%-50%。当图像和点云 Topic 启动，这条本就拥挤的“马路”瞬间被占满，导致/cmd_vel等关键控制指令排队等待甚至丢包。解决这个问题的核心思路非常清晰：先给数据“瘦身”，再修一 告别卡顿，ROS2 雷达图像传输的带宽优化全攻略
为什么你的 SLAM 系统一传图像就“卡成 PPT"？搞视觉 SLAM 或远程监控开发的朋友，大概率都经历过这种崩溃瞬间：机器人本地跑得好好的，算法帧率稳定，一旦开启 WiFi 将摄像头图像和激光雷达点云传回上位机，整个系统立刻“抽风”。Rviz 里的点云更新严重滞后，控制指令延迟飙升，甚至直接断开连接。很多人第一反应是优化算法代码或升级主控 CPU，但折腾半天发现，真正的瓶颈往往在最不起眼的地方——网络带宽被原始传感器数据“吃”光了。这并非危言耸听。我们来算一笔账：一张普通的 640x480 RGB 图像，未压缩时单帧约 0.9 MB。若以 30Hz 发布，仅这一路视频流就需要约 216 Mbps 的带宽。而点云更是“带宽杀手”，一帧包含 10 万个点的sensor_msgs/PointCloud2消息，若包含 XYZ 坐标和 RGB 颜色，大小轻松突破 1.6 MB。以 10Hz 发布，就需要 128 Mbps。两者相加，总需求超过 340 Mbps。看似千兆 WiFi 绰绰有余，但现实很骨感。WiFi 的标称速率是物理层极限，受信号衰减、同频干扰及 TCP/IP 协议开销影响，实际稳定有效带宽往往只有理论值的 30%-50%。当图像和点云 Topic 启动，这条本就拥挤的“马路”瞬间被占满，导致/cmd_vel等关键控制指令排队等待甚至丢包。解决这个问题的核心思路非常清晰：先给数据“瘦身”，再修一 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
