[ros-users] Standardization of mapping interfaces

Tue Oct 23 21:24:51 UTC 2012

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