[ros-users] Standardization of mapping interfaces

[Dave Hershberger]

For what it's worth, you don't have to settle for billboards in rviz.
 There is already a geometry shader you can choose in the PointCloud and
PointCloud2 displays which lets you display the points as axis-aligned
cubes.  You still have to set the size of the cubes manually, but you don't
have to settle for billboards.

You could also write a display plugin to display octomaps directly.

Dave

On Sat, Oct 27, 2012 at 8:49 AM, Stefan Kohlbrecher <
stefan.kohlbrecher at gmail.com> wrote:

> Hi,
>
> I'd consider it useful to make a plugin interface available within the
> map_dispatcher that gives access to the map. Implementing this
> interface, users could then create and load their custom plugins to
> retrieve information based on map data (or even update the map). We
> (Christian Dornhege, a few others and me) implemented an example of a
> similar system for a modified octomap_server at the ROS summer school
> in Graz earlier this year. We implemented a small proof of concept for
> sensor coverage mapping based on octomap, keeping track of the
> geometry seen by cameras (Video here:
> http://www.youtube.com/watch?v=JwbZegYgxzc). To do so efficiently we
> added the following plugin interface for coverage_octomap_server:
>
> https://code.google.com/p/rescue-ros-pkg/source/browse/trunk/coverage_mapping/coverage_octomap_server/include/octomap_server/CoverageOctomapServerPlugin.h
>
> The coverage sensor updater plugin (as an example) then implements
> this interface:
>
> https://code.google.com/p/rescue-ros-pkg/source/browse/trunk/coverage_mapping/coverage_sensor_updater_plugin/src/coverage_sensor_updater_plugin.h
>
> This gives the plugin full access to the the map and also allows to
> easily customize the number, types and parameters of plugins to load
> via launch files. An example yaml file looks like this:
>
> https://code.google.com/p/rescue-ros-pkg/source/browse/trunk/coverage_mapping/coverage_octomap_server/params/sensor_params.yaml
>
> Another example illustrating the advantages of this approach even
> better is probably the lookup of a single distance (e.g. raycast) into
> the map, or any other operation that is cheap, provided one has access
> to the map data. If the map_dispatcher does not provide the desired
> functionality, some other node has to retrieve a copy of the complete
> map, only to do this simple and cheap operation. Using a plugin
> interface like described before, one just has to implement a plugin
> that provides the requested functionality via a service server, making
> things much more efficient and IMHO less cumbersome.
> Most other functionality proposed for the REP could then of course
> also be implemented using plugins, making the map_dispatcher
> completely reconfigurable (which one might or might not want).
> Anyways, I just wanted to share the idea and put it up for discussion.
>
> regards,
> Stefan
>
>
>
> 2012/10/26 Stéphane Magnenat <stephane.magnenat at mavt.ethz.ch>:
> > Hello,
> >
> > It would be nice to hear some feedback from the potential users of the
> > mapper nodes. People doing semantic mapping, object recognition, etc,
> what
> > do you need? I feel that we have a fairly good idea of the requirements
> for
> > mapping itself, but not enough information on the downstream use of maps.
> >
> > Cheers,
> >
> >
> > Stéphane
> >
> > --
> > 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
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121028/b6bdfbde/attachment-0004.html>