ROS 远程控制之码率问题

前不久， 做了一个WiFi通讯的ROS控制实验。（注： 是在同一个wifi网段下，没有跨internet）. 众所周知，ROS middleware是一个分布式框架（严格来说是一个星形分布，需要一个master）。经过简单的设置便可以实现各个节点的wifi 通讯。

于是做了以下两个实验：

1》 hector slam 建立地图

2》 基于已有地图的navigation

这两个过程中， 机器人Robot和笔记本Notebook分布负责算法运行， rviz 显示 + 键盘控制。 一切都比较顺利， 但其中有一个问题引发了我的注意。 整个实验过程中码率都很高，如图所示：第一张图是机器人不动的时候， 码率峰值达到了1MB/s， 当机器人运动起来时， 码率高达2MB/s. 码率呈周期性变化。

主要的码流是由于Notebook 主要是订阅了一些消息所产生的， 于是去查询最占流量的信息， 地图。

地图的格式是

建立地图和自动导航阶段的主要数据量是 地图数据，其次是激光数据。不订阅或者降低这两个topic订阅频率,那么数据量会大幅减小。

从代码和配置信息可以发现地图的发布周期是2秒

  private_nh_.param("map_pub_period", p_map_pub_period_, 2.0);

这也映证了网络流量图的波动情况。

此外，地图数据在传送过程中没有做任何数据压缩，所以还存在很大的数据压缩空间。

1> 根据无损压缩图像的经验，在合适的计算量下，估计可以压缩5~10倍率。考虑到地图数据中有大量的相似取值，采用算术熵编码可以大幅降低码率。

2> 甚至可以考虑简化数据的方式， 将取值进一步重新量化，比如将概率取值分3个段。这样可以直接将每位8个bit降到2个bit, 数据量直接下降为原来的1/4；

如果两种方式都采用，地图数据量很有把握地肯定可以下降10倍以上。

ros是大家广为学习的middleware, 其中实时性是一大诟病，在此，我也有个小小的建议，ROS应该提供一些数据压缩和解压方式提供给有此类需求的人。我还不清楚现有的ROS究竟有没有，从我本次测试来看，应该是没用到。 如果没有的话， 年后我会做一个。希望广大网友多多支持。

我自己也发现了一个问题： 如果网络流量主要是地图形成， 而且数据如果没有压缩的话， 应该是很稳定的波动（因为地图尺寸没有变化， 如果只是传递地图有效区域，那么流量应该随着地图越来越大而增长）。不应该在小车出现移动的情况下发生变化。

 现在的现象是有变化的， 说明流量的可能受到其他因素的影响。有可能是发送延时。如果是发送延时，那么流量波动在一定窗口期内还是比较均匀的。目前好像确实比较符合。

还需要多做实验测试wifi信号好和不好的情况下的波动情况。也可以抓数据看看。

继续实验：

首先将发布周期改为5秒， 将小车从wifi 近处开到远处， 会得到下图的情况： 单位时间内（10秒为单位），总流量没有变，波形发生改变，是因为码率峰值上不去，发送延时所导致。

然后将小车遥控回来，情况是这样的：

关闭绝大部分订阅， 只保留TF的订阅（方便看到车在动），会看到码率一下子几乎到0

在上一步的基础上，增加激光雷达的数据订阅， 可以看到数据量 每秒大概是40kB,  我的激光雷达是每秒4000点， 主要数据 每个点有两个 float， 所以总数据量应该是 4K × 8Byte = 32KB.  再加上其他的头部信息和ROS开销，接近40KB 是非常准确的。 由此也可以推断出，数据在wifi传输过程中应该是没有任何压缩的。

。

最后一张是建立地图完成之后的码率情况。 整个建图面积大概有100平米左右， 与刚开始前的 10平米小房间， 没有什么码率差别。 由此可以推断ROS是整图传输的，没有使用任何稀疏表示或者区域表示的方式。也没有任何数据压缩措施。

很有必要针对ROS写一个数据压缩节点， 将数据压缩之后上传网络， 另一端从网络下载之后，在解压节点进行解压，这样可以大幅优化ROS通过网络进行监控和遥控的实时性。

本问题暂时到此告一段路。 实验结论已经明确，与代码完全吻合。