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
(text/plain)