Skip to content
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

Option to Destroy Subscription in terminate #218

Open
amalnanavati opened this issue Sep 16, 2023 · 0 comments
Open

Option to Destroy Subscription in terminate #218

amalnanavati opened this issue Sep 16, 2023 · 0 comments

Comments

@amalnanavati
Copy link
Contributor

Currently, once you run setup on any behavior in py_trees_ros/subscribers.py, that subscription is active and accepting messages until the code terminates and it is garbage-cleaned. This means it stays on the wait set and consumes resources from the callback group, even at times we don't need it. For example, if we have a large tree and only want to subscribe to a topic in one particular behavior, we can destroy the subscription afterwards to save resources.

I'd propose the following implementation:

  • Pass a boolean flag, unsubscribe_on_terminate, to all subscription behaviors. Have it default to False (current behavior).
  • In setup(), we store self.node. Further, if unsubscribe_on_terminate is False, we create the subscription.
  • In initialise(), if unsubscribe_on_terminate is True, we create the subscription.
  • In terminate(), if unsubscribe_on_terminate is True, we destroy the subscription.
  • In shutdown(), if unsubscribe_on_terminate is False, we destroy the subscription.

Let me know what you think. We have certain subscribers that we only need at particular parts of the tree (e.g., only subscribe to object detection after the robot has moved to a pre-grasp pose) and we don't want it consuming callback resources during the rest of the tree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant