[ros-users] Standardization of mapping interfaces

Damon Kohler damonkohler at google.com
Mon Nov 5 15:22:56 UTC 2012


I would like to see an API for accessing trajectories. Building a
trajectory externally by watching tf (e.g. hector_trajectory_server)
does not always work (e.g. gmapping).

On Fri, Nov 2, 2012 at 2:54 AM, Stéphane Magnenat
<stephane.magnenat at mavt.ethz.ch> wrote:
> Hello,
>
> Thanks for these links! Your message and the general direction of the
> discussion make me think that maybe map_dispatcher and its interfaces should
> be moved into their own REP. In the spirit of the ROS architecture, it seems
> better to have small self-contained standalone pieces than a complicated
> node/spec. What is the opinion of the community about this?
>
> So if I understand well the design you propose, map_dispatcher would be a
> map blackboard [1], right? I can imagine plugins able to register triggers
> (in the database sense) so that plugins can be notified when certain parts
> of the map change. Although I like the idea of plugins, I would keep the
> functionality currently defined in REP129 as part of the default feature
> set, as they do not consume any processing power when not used (they can
> still be implemented as plugins internally).
>
> Your description and the post of Loy raise several questions in my mind:
>
> - What type of information would you like to store in the map? Occupancy is
> one thing, but other types of data like categorical information make a lot
> of sense in the context of space segmentation for instance. Based on my
> experience with semantic mapping [2] and the post of Loy, I typically see
> several Occupancy/probabilistic maps, segmented into several categorical
> maps, processed into symbolic information that has geometric properties
> attached and links back to the maps.
>
> - Should the map dispatcher be limited to a voxel/octree representation, or
> should it also support point clouds? Processing on point clouds can be
> useful, for instance to build a mesh for display or further processing, or
> to do planning.
>
> - As plugins will manipulate voxel/octree/point-cloud data, there should be
> a library of choice to do so, but which? This question has the potentiality
> to open a Pandora's box: For instance for point clouds, on one hand PCL is
> widely used, on the other hand PCL define point-cloud channels statically
> with templates, which will force to use PointCloud2 between the map and the
> plugins, which might affect performances. I do not know the situation for
> voxel/octrees.
>
> - We should support both 2D and 3D, should it be in a single node or in two
> different nodes?
>
> - The plugin architecture you propose as the disadvantage that everything
> runs inside a single memory space. Maybe the architecture should be based on
> nodelets, letting open the choice of whether to run plugins in-process or
> out-of-process?
>
> I think that's all for now from my side,
>
> Cheers,
>
> Stéphane
>
> [1] http://en.wikipedia.org/wiki/Blackboard_system
> [2] http://www.springerlink.com/content/k55337520q7341hq/
>
>
> --
> Dr Stéphane Magnenat
> http://stephane.magnenat.net
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users



-- 
:wq

Google Germany GmbH
Dienerstr. 12
80331 München

AG Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

Tax ID:- 48/725/00206
VAT ID:- DE813741370



More information about the ros-users mailing list