Computation of the volume

[Lirone Samoun]

Hello,

I have an object point cloud and I built a tree with Octomap. Used 0.01 as a resolution.

Then, I would like to compute the volume but I have strange results. I came across this link by searching on the group before: http://answers.ros.org/question/149126/octomap-volume-estimation/

So I did the same.

    for(octomap::OcTree::leaf_iterator it = tree.begin_leafs(),end=tree.end_leafs(); it!= end; ++it)

    {

        // check whether the node is occupied

        if (tree.isNodeOccupied(*it)){

            //get the side length of the current voxel

            double size = it.getSize();

            //Compute volume voxel using formula of volume cube

            double volumeCurrentVoxel = size * size * size;

            volumeTotal = volumeTotal + volumeCurrentVoxel;

        }

As my resolution is low in order to have an accurate representation of the object, it's normal to have a little value when I do volumecurrentVoxel = 0.1*0.1*0.1.

My results is under 1. For example: 0.007578 m^3

when I visualize my tree with octoviz I see that under the screen there is the computed volume which is for example 0.55 x 0.8 x 0.58 m^3 which is very different from my result above.

Coud you please help me ?

Thank you

[Lirone Samoun]

I found something interesting: the function  getMetricSize().

I'm now able to find the same data as display in Octoviz by doing:

 tree.getMetricSize(x1, y1, z1);

So if I got it well (correct me if I'm mistaken), by using getMetricSize, we are getting the size of the entire box which include the object cloud, and by doing as above (compute for every node the volume), we are getting the proper volume of the object cloud ?

Thank you.

[Armin Hornung]

Hi Lirone,

Am 27.04.2016 um 14:38 schrieb Lirone Samoun:
> So if I got it well (correct me if I'm mistaken), by using
> getMetricSize, we are getting the size of the entire box which include
> the object cloud, and by doing as above (compute for every node the
> volume), we are getting the proper volume of the object cloud ?

Indeed, that's correct. Octovis uses the "getMetricSize" function to
determine the overall volume, which corresponds to the volume you would
need to cover with a 3D array or voxel grid (including free and unknown
space).

With your method you count the occupied volume of the individual
occupied voxels. If there's a hollow space within an object, however,
you won't use it in the volume computation.


Best regards,
Armin

[Lirone Samoun]

Thank you for your reply Armin !

"With your method you count the occupied volume of the individual 
occupied voxels. If there's a hollow space within an object, however, 
you won't use it in the volume computation. "

So What I did is not correct to compute only the volume of the free voxel ? Because as you said the size with the getMetricSize() correspond to the overall box which include unknown space, so by doing a loop only on known voxel and compute each volume and then add to volume total is not correct ?

Thank you again.

[Christoph Sprunk]

Hi Lirone,

getMetricSize() gives you the dimensions of the minimum bounding box
around all known voxels (occupied and free).

If you look at your map in octovis, the occupied voxels will be shown in
blue (make sure no option is ticked under View->View Mode). These are
the ones that your code summed over (see the if statement in your code).

If you want to look at the free voxels, activate the option under
View->Free Octree Volumes. If you want to include those voxels, too,
remove the if statement in your code.

Unknown voxels are the ones that you have no information about, no ray
tracing ever went through them. They are not shown in octovis.
Everything that is neither occupied or free is unknown.

Hope that helps,
best,

Christoph

On 29.04.2016 08:54, Lirone Samoun wrote:
> Thank you for your reply Armin !
>

> "/With your method you count the occupied volume of the individual

> occupied voxels. If there's a hollow space within an object, however,

> you won't use it in the volume computation. "/
> /
> /

> So What I did is not correct to compute only the volume of the free
> voxel ? Because as you said the size with the getMetricSize() correspond
> to the overall box which include unknown space, so by doing a loop only
> on known voxel and compute each volume and then add to volume total is
> not correct ?
>
> Thank you again.
>
>
>
> Le jeudi 28 avril 2016 22:46:45 UTC+2, Armin Hornung a écrit :
>
> Hi Lirone,
>
> Am 27.04.2016 um 14:38 schrieb Lirone Samoun:
> > So if I got it well (correct me if I'm mistaken), by using
> > getMetricSize, we are getting the size of the entire box which
> include
> > the object cloud, and by doing as above (compute for every node the
> > volume), we are getting the proper volume of the object cloud ?
> Indeed, that's correct. Octovis uses the "getMetricSize" function to
> determine the overall volume, which corresponds to the volume you would
> need to cover with a 3D array or voxel grid (including free and unknown
> space).
>
> With your method you count the occupied volume of the individual
> occupied voxels. If there's a hollow space within an object, however,
> you won't use it in the volume computation.
>
>
> Best regards,
> Armin
>

> --
> You received this message because you are subscribed to the Google
> Groups "OctoMap developers and users discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to octomap+u...@googlegroups.com
> <mailto:octomap+u...@googlegroups.com>.
> To post to this group, send email to oct...@googlegroups.com
> <mailto:oct...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/octomap.
> For more options, visit https://groups.google.com/d/optout.

[Johan E]

Sorry for digging up a really old topic.

I am interested in calculating the volume of free, occupied, and "unmapped" space in an OctoMap. As far as I've understood, "unmapped" space doesn't actually exist in OctoMaps, but if I have a known bounding box, I should be able to subtract the vol_bbx - vol_free - vol_occupied = vol_unmapped?

Would a leaf_bbx_iterator be the right choice for my problem, where the min and max are specified as coordinates? For example, if I wanted to get a cube, would I set min = (-0.5, -0.5, -0.5) and max = (0.5, 0.5, 0.5) to get an origin centered, "unit cube"?

http://octomap.github.io/octomap/doc/classleaf__bbx__iterator.html#details

Thanks for any help!

[Johan E]

I have attached a snippet of code that seems to do the job, as part of a ROS Octomap subscriber node. I simply save the vol_* variables to a .csv file and graph from there.

 

    float vol_occ = 0;
    float vol_free = 0;
    float vol_tot = (bbxMaxX-bbxMinX)*(bbxMaxY-bbxMinY)*(bbxMaxZ-bbxMinZ);

    point3d min(bbxMinX, bbxMinY, bbxMinZ);
    point3d max(bbxMaxX, bbxMaxY, bbxMaxZ);

    OcTree* octree = (OcTree*)octomap_msgs::msgToMap(msg);

    if (octree){ // can be NULL
      for(OcTree::leaf_bbx_iterator it = octree->begin_leafs_bbx(min,max), end=octree->end_leafs_bbx(); it!= end; ++it){
        double side_length = it.getSize();
        if (octree->isNodeOccupied(*it)){ // occupied leaf node
          vol_occ += pow(side_length,3);
        }
        else { // free leaf node
          vol_free += pow(side_length,3);
        }

      }
    }

    float vol_unkn = vol_tot - vol_occ - vol_free;