Concerns over ROS messages overhead
Hi all,
I am writing a topological mapping and navigation system that runs on top of gmapping. One of the main goals is to make it scale very well for very large map sizes.
My concern is now, is that the publishing of messages to topics will generate unnecessary and substantial overhead.
It seems to me like gmapping publishes the full map message (nav_msgs/OccupancyGrid) every update (which is at 0.2Hz in my configuration). That seems to mean, that every 5 seconds, the full map is copied (not referenced) over the wire of ROSs communication system (tcpros or something like that I believe). While theoretically, only changes to the map could to be sent over the wire to limit the amount of copying in the computers memory. I found that messages are only published if there is a subscriber to the topic, but as I use rviz to visualize /map, I figure that that would trigger the nav_msgs/OccupancyGrid for /map to be published and thus completely copied at least every 5 seconds.
Are the above described presumptions about the working of ROS right? Is there anyway to circumvent it? Rewriting parts of gmapping wont make a difference: to update /map it needs to get an updated occupancy grid map message. And as every cycle something small will always change in /map (due to noise), that means that for making even the smallest update, /map needs to be supplied with a full new copied nav_msgs/OccupancyGrid message....
Now the second concern: In my node I have two object vectors: one with all the nodes (points) and one with all the edges (links) of my topological map. I publish them as markers to a MarkerArray which is visualized in rviz. I want to be able to remove the markers, in case a node or edge gets deleted. So I specified a lifetime duration of 1 second. To publish, I publish all the nodes and edges every spin of my node. In this case, deleted nodes and edges disappear after 1 second, and updated nodes or edges get updated too (at each spin). I suspect this to give overhead as well, as for an large map, this would mean most of the nodes and edges will get republished unnecessary (generating processing and copying overhead) every cycle.
Is this true? If so, am I right that the best solution is to add some "last updated" variable to my nodes and edges objects, remove the lifetime limitation of the markers, and figure out some code that efficiently returns a vector of updated nodes and edges since the last ros spin cycle and use that filtered vector to visualize them? And I should delete the markers belonging to deleted edges and nodes using visualization_msgs::Marker::DELETE I guess?
