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 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@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