Am 26.10.2012 22:37, schrieb Stéphane Magnenat:
>
>> I thought to only have one field "size" in the message, not one for
>> each point. Sorry if that wasn't clear.
>
> Ok that makes sense, although this precludes the use of bare PointCloud2
> messages, which implies some minor changes to rviz for supporting an
> extended message.
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, maybe we should backtrack one step. My point of view was from a
>> mapping perspective, while I think yours was in the SLAM perspective.
>> I was thinking more in terms of a consumer of the point clouds
>> directly after alignment, while I now understand you were thinking
>> about the first part that should, of course, provide the full point
>> clouds and registered poses.
>>
>> So why not making that clearer and moving the 3D map building into
>> its own part, or into map_dispatcher? The output of the SLAM node
>> should then be defined as tf and registered point clouds. Occupancy
>> map building can then happen on top of that e.g. in octomap_server.
>> For memory reasons, the map building part should not need to keep
>> another copy of all the point clouds after they were already
>> integrated. The occupancy mapping can happen in the same node or in a
>> separate node that consumes the point clouds.
>
> OK to backtrack one step, there is probably an architecture discussion
> here, with things that have different semantics in the minds of
> different people. If I understand correctly, your suggestion is to
> have the localization node publishing tf from map->odom and point
> clouds registered in the map frame, right?
>
> Although I find this suggestion interesting, I am not convinced that
> this architecture would be clearer/simpler/faster, because
> localization and mapping are often intertwined in a complex way. For
> instance, in RBPF SLAM such as FastSlam, the SLAM node (even if used
> only for localization) holds a map (one per particle). Moreover, even
> for ICP-based localization with no particle, upon loop closure the
> localization node must communicate a list of updated poses for the
> different scans to the mapper node, which requires a mechanism to
> bookkeep these scans. In the case of visual SLAM with bundle
> adjustment, the problem is similar.
>
> Making the split you propose is not impossible to do, but I do not see
> the advantage compared to a SLAM node. That said, maybe you were
> thinking of a map at a different level of size, like a persistent
> world map or something like this?
I think this is the kind of volumetric (global) map that I have in mind...
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.
>
> The first point is covered by the discussion in my previous paragraph.
> For the second point, I have nothing in principle against using a
> compact message, but octomap_msgs/OctomapBinary lacks support for
> probabilities.
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.
> Anyway, if we use OctomapBinary the semantics of data inside the
> message should be clearly documented. Note that in that case, instead
> of providing a MarkerArray auxiliary output, it would be better to add
> support to rviz for displaying OctomapBinary messages directly.
Afaik Julius at Willow already worked on that...
Disclaimer for all the above: My perspective is likely biased and
focused on my previous map usage for 3D and 2D collision checks
(3d_navigation) and 3D localization (humanoid_localization) with OctoMap.
Cheers,
--
Armin Hornung
Humanoid Robots Lab, Albert-Ludwigs-Universität Freiburg
Contact:
http://www.informatik.uni-freiburg.de/~hornunga
(text/plain)