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?
-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@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>