Hi Armin,
> 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.
Yes that's fine. The idea is that the high-level discussion takes place
on the mailing list and that discussions about details go through the
pull request. It is great if you can edit the volumetric occupancy map
part and then you can simply make a pull request for me to insert it.
> 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 agree, with the reserve of the memory footprint of the message, as
discussed later in this email.
> 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
Yes, and when you are happy with it, just do a pull request.
I wrote the octree part without a lot of experience to have an initial
content, and contributions from experienced people like you are very
welcome. Probably we have to renamed the octree_map topic and services
into occupancy_map.
> 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.
I agree in principle for a 3D occupancy map, but I have a slight worry:
because of dimensionality, the need for compression is much stronger in
3D than in 2D. We could let it to the transport layer, but we have to be
conscious that if we update a 2000 x 2000 x 100 map (the size of a
typical lab at 5 cm resolution, aligned with coordinates), that message
will be 400 MB. Of course progressive updates will help, but I am
wondering whether we should have a simple RLE compression (or something
like snappy [1]) at the message level. We could provide a tiny library
to ease the compression/decompression operations for the user. I agree
that somehow this duplicates the transport job and will require multiple
implementations for Python, etc. but we also have to be realistic: if we
want people to use our specification it has to allow at least reasonable
performances. We could also imagine to add snappy support to
ethzasl_message_transport [2], which will profit other users as well,
but I am not sure we want to let a REP depend on a third-party package
(we could also tie ethzasl_message_transport more to the ROS core, but I
guess not everyone will agree).
As for the CollisionMap message (by the way, what is the field axis
for?), somehow we have to choose between it and a dense voxel map. The
dense voxel map is semantically closer to the OccupancyGrid and can hold
probabilities, while the CollisionMap is sparse. The easiest to handle
is the dense voxel map, but I would really compress it in the message
and make a library to manage this message, such as decompressing only
part of it.
I agree that the octree itself is an implementation-specific optimization.
It would be nice to have feedback from potential users on this point.
> 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."
Yes that phrasing is really bad. What I want to say is how, in case of
voxel maps, to generate a point-cloud map that is compatible, from an
application point of view, with point-cloud maps based on ICP
registration. My idea was that for each face pointing to free space,
there should be a point generated on this face with a normal in the
direction of the free space. Maybe we do not need to specify this.
> 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.
I fully agree, and this links us to the problem of the lack of
standardized channel names in PointCloud2, as only 'x','y','z' seem to
be standard. For the viewpoint, I propose something like 'camera' of
size 3 or a triplet 'camera_x', 'camera_y', 'camera_z' that is the
position of the camera in the final map from which this point would have
been observed (after corrections). During registration, points can hold
a relative vector to the camera position that can be transformed into an
absolute position before sending the cloud. Or we can keep the relative
vector if we prefer. The question is whether we want to enforce this, as
this might require some additional processing time for a feature that is
useful, but might not be required for all applications. My feeling is
that the benefit outweighs the drawbacks, so I would be ok enforcing it,
or at least having a parameter for enforcing it. If we have it, would
you see `map_dispatcher` being able of providing a voxel map out of a
point-cloud map? Should it be a `voxel_map_dispatcher`? Would it be
useful for you? Should this change the definition of profiles 3DO and
P3DO (beside naming them 3DV and P3DV)?
Thanks a lot for contributing to the REP!
Best regards,
Stéphane
[1]
http://code.google.com/p/snappy/
[2]
http://www.ros.org/wiki/ethzasl_message_transport
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
(text/plain)