ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

Memory management in callback for Octomap

asked 2019-11-02 06:02:30 -0500

KalanaR gravatar image

updated 2019-11-04 04:06:05 -0500

In the project i am working on, there is a ROS node and a C++ object pair. ROS node creates the object, listens to the subscribed topics and updates the object variables accordingly. Following is a similar class to the class of the object.

treeEvaluator.h

class treeEvaluator
{
private:
    octomap::OcTree* treeOct;

public:
    treeEvaluator();
    void update_tree(octomap::OcTree* receivedTree);
};

and update_tree function of treeEvaluator.cpp is as follows

void treeEvaluator::update_tree(octomap::OcTree* receivedTree)
{
    treeOct = receivedTree;
}

then i have to use the "treeOct" for some further calculations.

In the ROS node side i have created a object of treeEvaluator and uses callback as follows,

treeEvaluator evaluatorObject = treeEvaluator();

void mapCallback(const octomap_msgs::Octomap::ConstPtr &msg)
{
    octomap::AbstractOcTree* tree = octomap_msgs::msgToMap(*msg);
    octomap::OcTree* tree_oct = dynamic_cast<octomap::OcTree*>(tree);
    evaluatorObject.update_tree(tree_oct);
}

I found this snippet from the email thread of the octomap (tried to link but cannot find the exact thread) and modified it to my need. since i was able to get this to work, now i'm wondering whether it is legit. I was not able look into the msgToMap function to see whether it has a 'new' inside it, so this is my question,

Do i have to delete the 'tree' and 'tree_oct' pointers inside the mapCallBack manually after

evaluatorObject.update_tree(tree_oct);

line? (would it cause a memory leak if not?) In the normal case it wont be needed since those may have to be used inside the node. But i only use them to convert the msg to Map and then update the object. they are not used inside the ROS node after that. This callback gets called frequently as octomap updates frequently.

Thanks

(PS : i'm trying to run this on a Raspberry Pi, so lesser memory usage, better)

___ UPDATE 1___

It turned out to be a memory leak in the end. I had to implement two such nodes and after 1/2 hr of simulating, everything started lagging. Checking the "top" in terminal showed that one ROSNode had used around 49% of memory (7.7 GB) while other had around 42% of memory (6.6GB).

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2020-03-25 02:07:34 -0500

KalanaR gravatar image

updated 2020-03-25 02:09:23 -0500

Finally managed to solve the issue myself.

The issue was with the pointer usage of the Octree created inside the callback. It needed to be deleted but since i passed it to the "evaluatorObject" by pointer i was not sure where i had to delete it. (inside object or inside callback). Because of this, i decided to use smart pointers. "std::shared_ptr" to be exact.

i changed the callback from

void mapCallback(const octomap_msgs::Octomap::ConstPtr &msg)
{
    octomap::AbstractOcTree* tree = octomap_msgs::msgToMap(*msg);
    octomap::OcTree* tree_oct = dynamic_cast<octomap::OcTree*>(tree);
    evaluatorObject.update_tree(tree_oct);
}

to

void mapCallback(const octomap_msgs::Octomap::ConstPtr &msg)
{
    std::shared_ptr<octomap::OcTree> tree = std::shared_ptr<octomap::OcTree> (dynamic_cast<octomap::OcTree*> (octomap_msgs::msgToMap(*msg)));
    evaluatorObject.update_tree(tree);
}

and it solved the issue.

edit flag offensive delete link more

Comments

I am already using the shared pointer; however, still get the same error my callback function is

    void Planner::octomapCallback(const octomap_msgs::Octomap::ConstPtr &binary_msg)
{
    octomap::OcTree* tree_oct = dynamic_cast<octomap::OcTree*>(octomap_msgs::msgToMap(*binary_msg));
    fcl::OcTree* tree = new fcl::OcTree(std::shared_ptr<const octomap::OcTree>(tree_oct));
    // fcl::OcTree* tree =  new fcl::OcTree(std::shared_ptr<octomap::OcTree> (dynamic_cast<octomap::OcTree*> (octomap_msgs::msgToMap(*binary_msg)))); together

    // Update the octree used for collision checking
    updateOctotree(std::shared_ptr<fcl::CollisionGeometry>(tree));
    replan();
    delete tree;
    tree_oct->clear();
}
hesham gravatar image hesham  ( 2022-12-13 02:51:13 -0500 )edit

that didn't solve it for me

hesham gravatar image hesham  ( 2022-12-13 02:57:48 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2019-11-02 05:54:48 -0500

Seen: 652 times

Last updated: Dec 13 '22