Hi Armin, > I agree with the need for compression for the full map. In that case > (for large environments / full probabilities and free space) one can > simply build an octomap out of it and transmit it as > octomap_msgs/OctomapBinary (only requires octomap and octomap_msgs, I > would see this as sufficiently lightweight). Even large maps will be > ~10MB or less. So I don't see the PointCloud2 occupancy map as a > full representation, only as a quick common intermediate format that > can be exchanged or shown in RViz. Although, to that end, a > MarkerArray of boxes would be even better.... > > So far I had the assumption that the PointCloud2 occupancy map *is* a > sparse representation, only containing a list of occupied voxel > centers? Sorry I had misunderstood, I thought you did not want to use PointCloud2 for voxels. Now using PointCloud2 with voxels, do you plan to have constant-size voxels or let open the possibility to have them of different sizes within a single message? If the size is constant, it would be a bit strange to have one channel with a field "size" that is constant for the whole message. Also, should we define a field for "probability" of occupancy, to be consistent with OccupancyGrid? This raises again the question of standardizing field names in the PointCloud2 message. > I agree with this, although it could be that quite a few concerns and > changes pop up only by implementing the REP, causing a few > iterations of changes. Yes. > So far I changed "octree map" to "occupancy map". I'm not sure if I > see the benefit at the moment of providing voxel maps at all, besides > quick volumetric map checking e.g. in RViz by showing the occupied > voxels. It would be definitely beneficial to obtain the aligned > points clouds with their sensor origin, so a volumetric map can be > externally built e.g. in octomap_server. It would then end up in the > octree format there. Thanks for your changes. They raise one question: do you wish that a node providing mapping on voxels does not need to provide a point-cloud map? (make profile 3D optional if 3DO is present). I was thinking of requiring such a map in order to have a minimal interface to which any 3D mapper will comply. But I agree that this is matter of discussion. Kind regards, Stéphane -- Dr Stéphane Magnenat http://stephane.magnenat.net -- Dr Stéphane Magnenat http://stephane.magnenat.net