> It would certainly be desirable to follow the mapping process e.g. in
> RViz, that's only possible with a regularly updated topic.
Of course ; the question was whether the node should re-publish a map
that has not changed or only publish it next time it changes. When maps
are huge (our search-and-rescue mapping using modular_cloud_matcher has
maps of 600k points), repetitive updates of similar maps is a waste of
bandwidth. I have added a "~republish_map" service to do on-demand
republishing, which is useful, for instance if rviz was loaded after the
map was published.
> Have a look at the octomap_server_multilayer node in the octomap_server
> package. It is straight from the "3d_navigation" approach and builds a
> set of 2D projected slices, with support for incremental updates of the
> 2D map data. It's currently hard-coded for the PR2, but should be easy
> to generalize to an arbitrary set of layers or slices, all configurable.
I've had a look, it makes sense. I propose to have the topics
"projected_map_$i". Then, we should have a service to retrieve the
information about the projected maps, giving the range of the values
considered to create each slice. I have added this to the wiki page.
Cheers,
Stéphane
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
(text/plain)