ros(18):ros::Publisher和ros::Subscriber消息缓存队列message queue的大小分析

        本文结论：对于占用内存比较大的消息类型，可以适当减小消息缓存队列message queue的大小；对于占用内存较小的消息类型，可以适当增大消息缓存队列，这样可以获得时间戳最接近调用程序时间戳或者目标时间戳。

        发布器向话题发布消息时，如果底层来不及发布，就存储在发布器的队列里。如果底层响应速度低于发布器发布速度，消息就会存储在队列中。注意这里不是订阅器来不及响应。

        订阅器来不及响应消息会存储在订阅器的队列。消息队列如果存储满，则会以先进先出的方式最旧的消息将会被弹出。

分析起因：

        跑2.5d-ndt建图即2.5维度-正态分布变换建图的一个开源包时，程序总是运行一会就终止了；但检查程序看，没有什么太大问题啊，于是怀疑一些我自己这边可以改变的参数。

        因为2.5维度的地图和3维的点云消息所需要占用的内存很大，于是怀疑到了发布和接收话题的“消息缓存队列message queue大小”是否合适。

        程序异常终止如下：

修改发布和接收话题的“消息缓存队列message queue大小”：

修改如下所示：

        订阅部分：将消息缓存队列改为10，当消息需要占据的内存空间比较大时，可以改得更小；当然消息缓存队列大时，可以获得最靠近当前时刻的消息数据

//   ros::Subscriber sub = n.subscribe("publisher/cloud_fullSys", 1000, chatterCallback); //initial
  ros::Subscriber sub = n.subscribe("publisher/cloud_fullSys", 10, chatterCallback); //initial

        发布部分：同样是把消息队列由1000改为10

  // ros::Publisher chatter_pub = n.advertise<sensor_msgs::PointCloud2>("publisher/cloud_fullSys", 1000);
  ros::Publisher chatter_pub = n.advertise<sensor_msgs::PointCloud2>("publisher/cloud_fullSys", 10);

修改后程序可以一直运行：