[ros-users] Standardization of mapping interfaces

[Stéphane Magnenat]

> +1 to the initiative, I agree that there should be more standardized
> interfaces for both 2D and 3D! This probably calls for a REP "2D and 3D
> mapping interfaces", or similar?

It would be good indeed. I have asked people around here at Willow 
Garage, and it seemed that the topic was too specific for a REP, which 
is the reason why I started working on the Wiki. Now if the topic 
interests a large part of the community, a REP might make more sense.

> This probably needs a clearer definition, what is a point map? Is it
> only aggregated end points after scan matching point clouds from a
> sensor? Another possibility would be the center points of voxels e.g.
> from octomap_server (in line to OccupancyGrid in 2D). Then the points
> alone are not sufficient since they are sparse and infinitely small. A
> resolution property like in the 2D case is needed for that.

I think that both raw data (in my case aggregated end points, typically 
after some filtering) and processed data (for instance equivalent to an 
occupancy-grid map in 3D, either implemented through a quadtree or 
through a point map of centers of voxels (with additional information 
such as density? normals? tensors?)) make sense. The selection of a good 
message data structure is a delicate question. PointCloud2 is good 
because it provides arbitrary field (for things like tensity, etc.) but 
as you point some meta information like the resolution would be welcome. 
However, meta information would probably not change from message to 
message, so maybe it should not be part of these, but rather lie in 
another part of the specification, which should be about the content of 
the message data, answering the question "what is a point map".

> ROI-like queries to the map server as a service call would be a welcome
> addition (e.g. give me all occupied cells in an axis-aligned bounding box).

I agree, the question is the shape of the region. The performance of the 
query depends on the underlying implementation: for kd-tree sphere-like 
ROI are better while for octree AABB are better.

Cheers,

Stéphane

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net