Hello everyone!
> On the contrary, I think that these could be directly displayed in RViz
> by picking the bare PointCloud2 contained in the message, and manually
> setting the correct size for the Billboard voxels. It's not optimal, but
> should work for a quick visualization.
Ok, this works for visualization, but is a bit limiting for other types
of use; anyway, I think that given the rest of the discussion this
question is not critical right now.
> Although what I meant was just to not enforce a certain output for *all*
> 3D SLAM nodes, just the least common denominator (registered point
> clouds). Otherwise all of them needed to create voxel maps that not
> everyone has a use for... with point clouds you could always plug the
> output into a (voxel) mapper (with known poses) node to create the
> desired output if needed.
I was never imagining to force all SLAM nodes to create a voxel map,
that is why I introduced the notion of profiles. I was imagining to
force all SLAM nodes to produce a point map consisting of points on the
edge of the occupied space (i.e. what scans contain), to have a common
interface, but even this I am not completely sure yet whether it should
be mandatory.
So if I understand correctly, even in your SLAM system, the octomap is
not used for registration itself, but for processing data afterwards? I
added the "3D occupancy map" profile to allow SLAM systems that natively
use this form of representation for registration to be able to transmit
it further in a standard way. For instance 3DTK [1] does this, maybe we
should contact Andreas Nüchter for feedback on this specific point.
> Just to clarify: The message can contain either .bt and .ot octomap
> files, the former stores only occupied / free while the latter stores
> full probabilities. The message was ill-named in fuerte (binary for the
> serialization into binary data) but that will be fixed in Groovy:
> http://alufr-ros-pkg.googlecode.com/svn/branches/octomap_stacks-groovy-devel/octomap_msgs/msg/Octomap.msg
>
> Here the header explicitly contains all the information instead of
> hiding it in the binary stream.
Ok, good.
All the best,
Stéphane
[1]
http://slam6d.sourceforge.net/
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
(text/plain)