How is the process designated to go from here - should we propose 
changes by branching from Stéphane's files and discuss at Github? To 
summarize, I started branching and put my comments below.

On 2012-10-20 01:00, Stéphane Magnenat wrote:
> Hello,
>
> The first draft of REP 129, Node API for SLAM Packages, is available 
> for review:
>     https://github.com/ros-infrastructure/rep/pull/6/files
>
> Your comments and contributions are warmly welcome,

I propose to get rid of the reference to octree and octree maps in the 
REP. This is an implementation detail that depends on the underlying 3D 
map structure. Similarly, you could compress a 2D map in a quad-tree, 
but the common map format remains an OccupancyMap msg.

I started changing this at the beginning of "Specification", should I go 
on and propose a complete change of the file?
https://github.com/ahornung/rep/commit/2d3ecd2a90a9c73df8915b19998e0d9cd805ae43

The idea is that the common format for occupied cells in 3D are voxels, 
an octree can be used to store and maintain them efficiently (e.g. in 
OctoMap) but that should not affect the exchange format. After all, for 
small areas, a VoxelGrid may work just as well as map representation. So 
the 3D profiles should only specify volumetric 3D occupancy maps, 
encoded as centers of voxels and only one (homogeneus) size parameter 
for the map (this is completely analogous to the 2D case, minus the free 
space). If an octree structure is explicitly desired, it can be 
exchanged as octomap_msgs including full probabilities and free space. I 
don't think it makes sense to try and replicate the structure halfway 
with a PointCloud2 (that is missing essential parts of the tree 
structure anyways). Alternatively, only if differently-size voxels are 
permitted (which I think can only come from an octree), it may be useful 
to the store per-voxel cube size (essentially a CollisionMap from 
arm_navigation_msgs / moveit_msgs). In any case, since it's axis-aligned 
boxes, origin information is required.

In 3D Node API, I don't understand the following part or why it's there: 
"For algorithms working with octrees, one point shall be returned for 
every face of the cuboids pointing to the sensor."

In general, what I'm missing is viewpoint information in the final point 
cloud map (and incremental update), associated to each single point 
cloud after aligning it with SLAM. I'm thinking of the following 
scenario: You build a 3D map with a number of point clouds from the 
sensor, register them properly, and then want to build a 3D occupancy 
map e.g. in OctoMap. To clear the space and fill free space information, 
you will need the sensor origin for each single point cloud.

Best,
Armin

-- 
Armin Hornung
Humanoid Robots Lab, Albert-Ludwigs-Universität Freiburg
Contact: http://www.informatik.uni-freiburg.de/~hornunga