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