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.
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.
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.
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.
Hope that helps,
-Austin
[1]:
http://ros.org/wiki/map_store
[2]:
http://www.ros.org/wiki/3d_navigation
On 10/04/2012 10:49 AM, Stéphane Magnenat wrote:
> Hello,
>
> I am working on the release of our modular ICP pipeline [1] (2D and
> 3D), which provides a mapping-style interface. While doing so, I
> realized that some features are commonly available in mapping
> packages, like getting the latest version of the map or reseting it.
> However, I have not find any standard to do so. Worst, while for 2D
> there is a message nav_msgs::GetMap, there is no standard equivalent
> in 3D. To allow easy interoperability between packages doing the same
> thing, it is important to have these.
>
> So here are my suggestions:
>
> - To add a GetPointMap message similar to GetMap but taking a
> PointCloud2 instead of an OccupancyGrid. This could either be added to
> nav_msgs or to something new like nav3d_msgs or map3d_msgs within
> common_msgs.
>
> - To define a standard interface for interacting with mapping
> packages. If we consider existing packages, (for instance gmapping,
> hector_mapping), there is a "dynamic_map" service that returns the
> latest map. While this naming is strange, it is the closest thing to a
> standard that we have. Should we extend it in 3D to have a
> dynamic_point_map service? Also, should we generalize the "syscommand"
> topic, which is a bit awkward, or maybe add something like a "reset"
> service? We might also want to save and load maps.
>
> Comments welcome, I think it would be great if we could improve the
> interoperability of mapping packages.
>
> Stéphane
>
> [1] http://www.ros.org/wiki/modular_cloud_matcher
>
(text/plain)