How to use sensor model parameters?

[skasperski]

I have a question regarding the sensor model used to update the Octomap from point clouds. My goal is to not trust single measurements to much, so that a couple of "hits" are required before a cell in the Occupancy-Grid changes to be occupied. (So basically an outlier rejection.) What would be the right way to do so? I used "setProbHit" to set a lower value, but that doesn't seem to work. (still every measurement results in an occupied cell) But when I set probHit lower then occupancyThres, no cell ever becomes occupied. Is this the intended behaviour?

[ahornung]

The probability for a hit must be larger than 0.5, otherwise a hit has a negative effect on occupancy. In OctoMap, anything that has been seen at least once is considered either occupied or free. If you want to maintain an "unknown" state in between you could try changing occupancyThres or work directly with the probabilities / logOdds and interpret them in your application.

By the way, Q&A are better suited for the mailing list in my opinion.

[skasperski]

Thank you for your explanation. I think I understood the probabilities and the update model now. However I am still puzzled with the results. I did some more investigation regarding the occupancy probability. All cells are either at the clamping min or clamping max (0.1 or 0.9 in my example), even after adding only a single scan to the map.

I used the following parameters, which as far as I understood should make the cells converge very slowly towards the thresholds:
occupancyThres: 0.5
probHit: 0.51
probMiss: 0.49
clampingThresMin: 0.1
clampingThresMax: 0.9

[skasperski]

I verified that I am using version 1.7.2 of octomap. I tried to switch to version 1.8.0 (current master) and devel, but with these versions no octomap is build at all, e.g. iterating over all leafs using mOcTree->begin_leafs() gives an empty list. Loading the binary octree with octovis gives:

ERROR: Tree size mismatch: # read nodes (6) != # expected nodes (16)

Normal would be ca. 5000 nodes after adding one scan to the octree.

[ahornung]

That's weird, do you have some minimal code to reproduce?

The parameters you described before should usually work as you intended.

[skasperski]

Update:
I found out that the min-max-values where because of the use of the writeBinary() method. After I changed it to writeBinaryConst() it worked as expected. Having a write-to-file method actually changing the dumped structure is a little counter intuitive, even if documented to do so.

Regarding the issue with the 1.8 version I constructed a minimal example that reproduces the error for me. Because I'm building with C++11 I had to cherrypick this in 1.7 and master.

#include <pcl/io/pcd_io.h>
#include <pcl/point_types.h>
#include <pcl/point_cloud.h>
#include <octomap/OcTree.h>
#include <iostream>

typedef pcl::PointWithViewpoint PointType;
typedef pcl::PointCloud<PointType> PointCloud;

int main()
{
    octomap::OcTree* tree = new octomap::OcTree(0.1);
    PointCloud::Ptr cloud (new PointCloud);

    if (pcl::io::loadPCDFile<PointType> ("slam3d_cloud.pcd", *cloud) == -1)
    {
        PCL_ERROR ("Couldn't read file test_pcd.pcd \n");
        return (-1);
    }

    octomap::Pointcloud octoCloud;
    int count = 0;
    for(PointCloud::iterator it = cloud->begin(); it < cloud->end(); ++it)
    {
        octoCloud.push_back(octomap::point3d(it->x, it->y,it->z));
        count++;
    }

    std::cout << "Cloud has " << count << " points." << std::endl;
    tree->insertPointCloud(octoCloud, octomap::point3d(0, 0, 0), -1, true, true);
    tree->updateInnerOccupancy();
    tree->writeBinaryConst("debug_octomap.bt");

    delete tree;
    return 0;
}

The pointcloud and the results for 1.7 and 1.8 version are attached: octomap.tar.gz

[ahornung]

I found out that the min-max-values where because of the use of the writeBinary() method. After I changed it to writeBinaryConst() it worked as expected. Having a write-to-file method actually changing the dumped structure is a little counter intuitive, even if documented to do so.

Yeah, that was broken quite some time ago, and writeBinaryConst() was the best way to mitigate it at that moment.

Running your test with 1.8 gives me exactly the correct binary file you provided (octomap_1_7.bt), I guess there must be something else going on with your codebase. Does the error occur with a clean checkout and build?

Are the unit tests running fine in your installation (make test)?

[skasperski]

I just rebuild completely with a clean checkout of devel-branch with the same result as before. The tests are running successfully. Are you using C++11? Not sure if this might be an issue.

[ahornung]

I just enabled C++11, no difference: The file is still working
correctly. Strange...

[skasperski]

I tried to remove PCL from the example to create a better reproduceable setup. I saved the pointcloud with octomap::Pointcloud::writeBinary() and tried to read it in with octomap::Pointcloud::readBinary() in the minimal example, but then the pointcloud is obviously corrupted, all coordinates are 0, 2, -2, -inf or inf.

Is there a way to check the written binary file, e.g. load it with octovis?

[ahornung]

I think there is a (unrelated?) bug in writing point cloud data. The way to test with octovis is to write a ScanGraph to file, the .graph files can be read and visualized in octovis. Although with the bug in writing point cloud data the written files will also be corrupt.

Does it work with the graph-files provided at the homepage?

[ahornung]

Pointcloud and ScanGraph binary writing is now fixed (#131). Maybe it's a similar problem?