Hi all,

(indeed do not feel shy to join our conversation)

> 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.

> 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? If so, this is a very interesting problem 
and I have some ideas that would be great to discuss with the community, 
including the unification of multi-robot map reconciliation with 
robot-to-existing-map re-localisation, but this might be the subject of 
another thread (that we can start as well if there is interest).

> In that case I would skip defining the voxel output completely,
> since that now depends on the actual occupancy mapping
> implementation. In the case of octomap_server, the output is an
> octomap_msgs/Octomap (binary - only free & occupied or full
> probabilities) that can already be directly used for collision checks
> in Groovy. I would only suggest auxiliary output such as an
> MarkerArray of occupied cells for visualization for all kinds of
> volumetric mapping interfaces.
>
> In that case everything we were trying to solve with an interim
> format is already done and implemented (full probabilities for free &
> occupied space, multi-resolution, compression built-in).

I think that there are two questions:
- Do we need a voxel representation for the SLAM node?
- If yes, in which format the corresponding message should be?

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. Moreover, as we discussed some days ago this is not very 
self-documenting and quite tied to octomap. If OctomapBinary becomes the 
de-facto standard for representing 3D occupancy grid this is fine for 
me, but its lack of support for probabilities makes it a poor candidate 
(even though a version with probabilities on the same principle could be 
great). 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.

Have a nice week-end,

Stéphane

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net