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