[ros-users] Standardization of mapping interfaces

[Stéphane Magnenat]

Hello,

> It isn't documented, but there's a map_store[1] package that provides a
> service for storing a loading multiple maps, and uses a database
> backend; it's more of a map_server replacement with services to select
> the map, but it's probably worth looking at.

I've had a look, although it is a bit more specialized, if we reach a 
standardization point this package could reuse part of it I think.

> Also worth noting is that 2D maps in the ROS navigation stack are
> communicated in two ways; via the GetMap service, and also published on
> the /map topic. For example, gmapping can be configured to publish a
> rasterized version of its internal map at a fixed rate.

Yes, I think that it makes sense to have both the topic and the service. 
I think that having the option to publish regularly on the topic is 
good, although it should not be mandatory. I am not sure if this option 
should be part of a specification.

> Extending these services to 3D would be excellent; but I think 2.5D also
> warrants some consideration. Mike Phillips and friends[2] did a lot of
> good work on 3D path planning by using three costmaps at varying heights
> to avoid full-3D collision checking; it's worth considering his approach
> when setting up map services.

I agree, inputs from experienced people would be welcome. I like the 
idea of octomap_server to provide a projected_map. It is a feature that 
we plan to add to modular_cloud_matcher. Maybe there should also be 
support for "slices" at certain altitudes? This could be the 
generalization of the projection, considering a range of z-values 
projected on a plane. Here also I see two levels of specification: a 
light one including only the topic and its message type, and a heavier 
one describing how to fill the message.

> It may also be worth consider a service that retrieves a small region of
> interest from a larger map; this could be useful when the full map is
> too big to load into memory, or would take too long to transfer over a
> network. I've been playing with an implementation like this, but I
> haven't produced anything remotely useful yet.

How do you imagine to specify the region? For modular_cloud_matcher we 
use a kd-tree so a sphere of a given radius centered on a given point 
would be the easiest, but I guess that octree people have another 
preference. Should this call return all points, or just a certain 
number? Maybe before going into these details we should agree on which 
message types are the standard for 3D maps, for me it seems that 
PointCloud2 and a form of 3D occupancy grid (it could be an octree) 
would be a good start.

I have made a proposal so far, along with some messages:
     http://ros.org/wiki/map_msgs
     https://github.com/ethz-asl/map_msgs
I am not sure the ROS wiki is the best place to tentatively write node 
APIs, but it seemed the simplest solution.

Cheers,

Stéphane

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