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