[ros-users] Standardization of mapping interfaces

[Stéphane Magnenat]

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