-
Notifications
You must be signed in to change notification settings - Fork 332
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
Add lifecycle_subscriber #488
Comments
I'm not totally sure what you are asking about here. Are you asking for a change in the code? If so, can you explain in more detail what you would like, and how the current LifecycleNode doesn't meet your needs? |
No response in 2 weeks. I'm going to close this out for now, but please feel free to respond to my question and reopen. |
Sorry I missed the notification. It's a feature request, there are currently lifecycle publisher which can be deactivate and activated on need. It would be nice to have the same for subscribers. Currently if I want to "deactivate" subscribers I have to track a boolean myself if they are paused or not. Which as I understood was one of the goals of introducing lifecycle publishers. That you don't have to track the state of the node yourself, but can just use publisher.activate()/publisher.deactivate(). Currently this behavior doesn't exist for subscribers. Let me know if something is unclear. I can't open the question myself |
The lack of a lifecycle_subscriber is a big functionality hole, imo. Say you have an Echo Node. Something that listens for a string and replies back with that same string. This is a common (toy) example for functionality. As it stands today, with a lifecycle_publisher and a standard subscriber, we'd get "correct" external functionality, but weird internal functionality. The subscriber callback would still execute (and potentially some internal "how many echos" counter increments), but the associated publisher reply would not be performed. It should just be that when a node is Inactive, neither publisher nor subscriber do any work. https://index.ros.org/p/lifecycle/ does mention this functionality to be added in the |
There's been a very old PR (closed unmerged) where I tried to come up with a Lifecycle subscription: ros2/rclcpp#292 At the time of writing, I didn't come through with it, but the current rclcpp API has changed significantly, so we might be able to resume that work. We certainly don't bring this in for the upcoming Galactic release, but we could definitely put this back on the table for H-Turtle. |
I'm curious about this as well... I really like the concept of the lifecycle node (imho all nodes should be lifecycle nodes), but I agree it seems there are some major gaps in functionality--no lifecycle subscriber, service, actions, etc. It would be really nice to be able to activate / deactivate those instead of having to check the node status in the sub / service / action callback. Is there a techical reason these weren't implemented or is one of the things that still just needs to be done? Major packages like the ros2 nav package that add significantly to lifecycle management and it would nice to pull that in. |
I'm building a relatively simple Python-based lifecycle node, and I was wondering about this exact thing. Has there been any further development on creating and destroying lifecycle-based subscribers? |
There's an open PR to add in lifecycle subscribers in ros2/rclcpp#2254 . But as of right now, there is no equivalent one for rclpy. |
Feature request
Feature description
Currently there is no lifecycle subscriber only a lifecycle_publisher. If this question and my import discovery is to be believed: https://answers.ros.org/question/302216/ros2-subscriber-listens-to-messages-while-lifecyclenode-is-unconfigured-or-inactive/
Now it would be good to have this and not to have to resort to custom flags, because they defeat the whole purpose of a lifecycle node. If using bools is an option, I could just do away with the concept of a lifecycle node and just implement my own custom logic based on bools. Thus I think it makes sense to have an equivalent to the lifecycle_publishers on_activate on_deactivate for subscribers
EDIT: I wrote publishers twice in the end. Should be subscribers
Implementation considerations
I guess the same way it's done for the publisher. Not exactly sure, but some internal bool which gets checked periodically.
The text was updated successfully, but these errors were encountered: