-
Notifications
You must be signed in to change notification settings - Fork 86
Feature/shared resoruces #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/shared resoruces #46
Conversation
Thanks. I will look into this soon and come back to you. |
Hi @facontidavide Have you had a chance to give this a look? |
Hi I started porting this manually. Can you check this commit and see if I have forgotten anything? |
also, you will notice that the registry uses weak_ptr now, that makes the auto-destruction much easier (I wonder how I didn't realize that earlier). |
Ok, i'll have a look over the next few days and let you know! |
Background
When dealing with really big behaviour trees in the past we have found that the loading and execution becomes quite slow. (More details can be found in this issue)
In that issue it was suggested taking a singleton approach so that only one instance was created per different service/action/publisher call. At the time we were still using bt v3.8 so implemented a solution locally. We are at the stage where we want to upgrade to bt v4.0 and use this library. When looking at the code I noticed that this is a concept that had been implemented in the RosTopicSubNode but not in the RosActionNode, RosServiceNode and RosTopicPubNode.
PR contents
I have implemented a similar approach to the RosTopicSubNode for the RosActionNode, RosServiceNode and RosTopicPubNode. Making it so that if any ros interface (publisher,subscriber,service client or action client) is called from multiple places in a tree it will use the same instance.
I also created a service server (simple adding two ints together) and examples to test the service client and publisher.
I hoping that you find this functionality useful and others will benefit. More than happy for suggestions if there is a better way to implement this functionality.
To test
To test and prove this i placed a log which displays the hex value of the pointer. And in the tree had 2 instances of the same class, the pointer should match. And then if you had 2 instances of a publisher (for example) but different topic_names then two instances of the base class would be made and the log would show a different pointer.
RCLCPP_INFO(rclcpp::get_logger("test"), "%s, publisher pointer: %p", name().c_str(), reinterpret_cast<void*>(pub_instance_->publisher_.get()));
I look forward to your feedback :)