[ros-users] Standardization of mapping interfaces

[Stéphane Magnenat]

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