On 2012-10-05 02:25, Stéphane Magnenat wrote:
>
>> 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.
It would certainly be desirable to follow the mapping process e.g. in
RViz, that's only possible with a regularly updated topic.
>
>> 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.
Have a look at the octomap_server_multilayer node in the octomap_server
package. It is straight from the "3d_navigation" approach and builds a
set of 2D projected slices, with support for incremental updates of the
2D map data. It's currently hard-coded for the PR2, but should be easy
to generalize to an arbitrary set of layers or slices, all configurable.
Cheers,
Armin
--
Armin Hornung
Humanoid Robots Lab, Albert-Ludwigs-Universität Freiburg
Contact:
http://www.informatik.uni-freiburg.de/~hornunga
(text/plain)