[ros-users] Standardization of mapping interfaces

Wed Oct 24 16:30:44 UTC 2012

Hi Stéphane,

>
>> 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.
OK done & pull request sent:
https://github.com/stephanemagnenat/rep/pull/1

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

I agree with the need for compression for the full map. In that case 
(for large environments / full probabilities and free space) one can 
simply build an octomap out of it and transmit it as 
octomap_msgs/OctomapBinary (only requires octomap and octomap_msgs, I 
would see this as sufficiently lightweight). Even large maps will be 
~10MB or less. So I don't see the PointCloud2 occupancy map as a full 
representation, only as a quick common intermediate format that can be 
exchanged or shown in RViz. Although, to that end, a MarkerArray of 
boxes would be even better....

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

So far I had the assumption that the PointCloud2 occupancy map *is* a 
sparse representation, only containing a list of occupied voxel centers?

>
> I agree that the octree itself is an implementation-specific 
> optimization.
>
> It would be nice to have feedback from potential users on this point.
I agree with this, although it could be that quite a few concerns and 
changes pop up only by implementing the REP, causing a few iterations of 
changes.

>
>> 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)?

So far I changed "octree map" to "occupancy map". I'm not sure if I see 
the benefit at the moment of providing voxel maps at all, besides quick 
volumetric map checking e.g. in RViz by showing the occupied voxels. It 
would be definitely beneficial to obtain the aligned points clouds with 
their sensor origin, so a volumetric map can be externally built e.g. in 
octomap_server. It would then end up in the octree format there.

Best,
Armin

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