[ros-users] Standardization of mapping interfaces

[Armin Hornung]

Hi all,

(as I hope we get more feedback from other users as well)

>
>> 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.

I thought to only have one field "size" in the message, not one for each 
point. Sorry if that wasn't clear.


>
> 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.

See below.


>
>> 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.


OK, maybe we should backtrack one step. My point of view was from a 
mapping perspective, while I think yours was in the SLAM perspective. I 
was thinking more in terms of a consumer of the point clouds directly 
after alignment, while I now understand you were thinking about the 
first part that should, of course, provide the full point clouds and 
registered poses.


So why not making that clearer and moving the 3D map building into its 
own part, or into map_dispatcher? The output of the SLAM node should 
then be defined as tf and registered point clouds. Occupancy map 
building can then happen on top of that e.g. in octomap_server. For 
memory reasons, the map building part should not need to keep another 
copy of all the point clouds after they were already integrated. The 
occupancy mapping can happen in the same node or in a separate node that 
consumes the point clouds.

In that case I would skip defining the voxel output completely, since 
that now depends on the actual occupancy mapping implementation. In the 
case of octomap_server, the output is an octomap_msgs/Octomap (binary - 
only free & occupied or full probabilities) that can already be directly 
used for collision checks in Groovy. I would only suggest auxiliary 
output such as an MarkerArray of occupied cells for visualization for 
all kinds of volumetric mapping interfaces.

In that case everything we were trying to solve with an interim format 
is already done and implemented (full probabilities for free & occupied 
space, multi-resolution, compression built-in).


-- 
Armin Hornung
Humanoid Robots Lab, Albert-Ludwigs-Universität Freiburg
Contact: http://www.informatik.uni-freiburg.de/~hornunga