[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ros-users
Subject:    [ros-users] Standardization of mapping interfaces
From:       hersh () willowgarage ! com (Dave Hershberger)
Date:       2012-10-29 0:04:33
Message-ID: CABc9=uPOYhbJmOc+85W=YeNLi0C9p3vRmH+iiHy0SwQygsOSmg () mail ! gmail ! com
[Download RAW message or body]

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: </lurker/list/ros-users.html/attachments/20121028/b6bdfbde/attachment.html>


[prev in list] [next in list] [prev in thread] [next in thread]