[ros-users] Standardization of mapping interfaces

Fri Oct 26 10:07:14 UTC 2012

On 26.10.2012 07:13, David Lu!! wrote:
> Would this also be a good place to standardize what the data in
> OccupancyGrid actually means? The comments in the .msg file specify...
> # The map data, in row-major order, starting with (0,0).  Occupancy
> # probabilities are in the range [0,100].  Unknown is -1.
> int8[] data
>
> However, this standard is not respected in the navigation stack,
> specifically costmap_2d, which also specifies costs with 8bits, but as
> unsigned chars, leading to costs [0, 254] with 255 being the unknown
> value (sometimes).
>
> The costmap_2d wiki page (http://ros.org/wiki/costmap_2d#Inflation)
> specifies that values [0,127] have ZERO probability of being in
> collision, which conflicts with the above "occupancy probabilities"
> definition.
>
> Personally I'd like a combination of the two...
> [-128, -1] special values (-1 is unknown)
> [0, 50] definitely not in collision
> [51, 99] possibly in collision (depending on orientation)
> [100, 100] definitely in collision
> [101, 127] ???
>
> What do other people think?

I would prefer to keep the values in the occupancy grid actual 
occupancies without special meaning. Obstacles can then be determined by 
an occupancy threshold (default: 50). The range [0, 100] seems
enough for that and would allow other special values like -1 for unknown.

I think costmap and occupancy map do have slightly different semantics. 
The occupancy map only gives world geometry (which needs to be 
interpreted). The costmap tries to give costs for a specific robot at 
the cell location and thus costmap_2d does all those extra values.

Maybe there could be something like an extension that allows to reuse 
the message and values outside the occupancy values -1 and [0, 100] can 
be used freely. Nevertheless even the costs in the costmap can be very 
different from the occupancies, so I'm not sure if it makes sense to 
merge the two.

Best,
   Christian

> -David!!
>
> P.S. I'm currently working on a version of costmap_2d that takes some
> of these considerations into account.
>
> On Wed, Oct 24, 2012 at 3:19 PM, Stéphane Magnenat
> <stephane.magnenat at mavt.ethz.ch> wrote:
>> Hi Armin,
>>
>>> 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....
>>>
>>> So far I had the assumption that the PointCloud2 occupancy map *is* a
>>>   sparse representation, only containing a list of occupied voxel
>>> centers?
>>
>>
>> Sorry I had misunderstood, I thought you did not want to use PointCloud2
>> for voxels.
>>
>> Now using PointCloud2 with voxels, do you plan to have constant-size
>> voxels or let open the possibility to have them of different sizes
>> within a single message? If the size is constant, it would be a bit
>> strange to have one channel with a field "size" that is constant for the
>> whole message.
>>
>> Also, should we define a field for "probability" of occupancy, to be
>> consistent with OccupancyGrid? This raises again the question of
>> standardizing field names in the PointCloud2 message.
>>
>>
>>> 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.
>>
>>
>> Yes.
>>
>>
>>> 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.
>>
>>
>> Thanks for your changes. They raise one question: do you wish that a node
>> providing mapping on voxels does not need to provide a point-cloud map?
>> (make profile 3D optional if 3DO is present). I was thinking of requiring
>> such a map in order to have a minimal interface to which any 3D mapper will
>> comply. But I agree that this is matter of discussion.
>>
>> Kind regards,
>>
>> Stéphane
>>
>>
>> --
>> Dr Stéphane Magnenat
>> http://stephane.magnenat.net
>>
>> --
>> Dr Stéphane Magnenat
>> http://stephane.magnenat.net
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>

-- 
Albert-Ludwigs-University
Institute of Computer Science
Research Group Foundations of Artificial Intelligence
Georges-Köhler-Allee 52
79110 Freiburg
Phone: +49 761 203 8225