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