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
(text/plain)