Difference between octree->clear and iterating over all nodes and a octree->deleteNode(it.getKey())

[Rein Appeldoorn]

Hi,

I'm currently working on a local octomap representation and I would like to clear my octomap at every new incoming sensor reading. I do this for one sensor as follows:

>> octree->clear()

>> insertCloudIntoOctree()

>> VisualizeOctree()

This works perfectly. However, if I use this for multiple sensors I would like to only clear the nodes corresponding to that sensor. I implemented this as follows

>> iterate over all nodes and do:

if(it->getTimestamp() == sensor_id) {

     octree->deleteNode(it.getKey());

}

>> iterate over all sensor points and do:

for (pcl::PointCloud<pcl::PointXYZ>::const_iterator it = cloud->begin(); it != cloud->end(); ++it){
     octomap::OcTreeNodeStamped* node = octree_->updateNode(it->x,it->y,it->z, true);
     node->setTimestamp(id);
}

>> VisualizeOctree()

This second method does not work properly; at my visualization, it appears that my octree is empty. So what is the exact difference between iterating over all nodes and do a deleteNode() for every node and a octree->clear()?
What is the proper way of implementing this behavior when multiple sensors are used?

Thanks,

Rein

[Rein Appeldoorn]

Any ideas on this? I have tried to do a lazy update (octree_->updateNode(it->x,it->y,it->z, true,true);) together with the deleteNode(it.getKey()) but then some other weird phenoma appears (see attachment).

Can anybody explain how to properly remove items from an octree?

Kind regards,

-Rein

--
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.
To post to this group, send email to oct...@googlegroups.com.
Visit this group at http://groups.google.com/group/octomap.
For more options, visit https://groups.google.com/groups/opt_out.

[Armin Hornung]

On 2013-11-01 14:07, Rein Appeldoorn wrote:
[...]

This works perfectly. However, if I use this for multiple sensors I would like to only clear the nodes corresponding to that sensor. I implemented this as follows

>> iterate over all nodes and do:

if(it->getTimestamp() == sensor_id) {

     octree->deleteNode(it.getKey());

}

You should not iterate over all nodes, but only over leaf nodes for this. Then it should work as you describe it, given that there are no pruned nodes. OcTreeKeys are only valid for a certain level. So for a delete, you should also specify the tree level of the iterator (otherwise the lowest level=16 is assumed).

This second method does not work properly; at my visualization, it appears that my octree is empty. So what is the exact difference between iterating over all nodes and do a deleteNode() for every node and a octree->clear()?

It should be the same, only less efficient to delete every single node. The outcome in both cases is an empty tree, but I guess that's not what you want...

What is the proper way of implementing this behavior when multiple sensors are used?

It should work like that if you take care of properly updating not only the leaf nodes but also the inner nodes (=parents of updated nodes). Without more information, I'm guessing that you're either iterating over all nodes including inner nodes, or that you're not updating the inner nodes properly according to your sensor setup. The problem is that inner nodes should somehow contain the information of their children (max occupancy for OcTree). When a node's children are updated from two different sensors then you need to find a consistent way of encoding that in your special setting, or ignoring it.

I suggest creating a minimal working example first with just a few manually inserted nodes, and verifying that everything works there.

On 2013-11-06 13:34, Rein Appeldoorn wrote:

Any ideas on this? I have tried to do a lazy update (octree_->updateNode(it->x,it->y,it->z, true,true);) together with the deleteNode(it.getKey()) but then some other weird phenoma appears (see attachment).

Are you calling updateInnerOccupancy() after you're done using lazy update? Missing that step could have weird side effects. Otherwise I'm not sure what phenomena you mean besides the strange visualization. On the other hand I don't even know what you use for visualization, it doesn't look like octovis to me.


Cheers,
Armin

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