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

Add message retention options to subscriber action #42

Closed

Conversation

tony-p
Copy link
Contributor

@tony-p tony-p commented Dec 29, 2023

Add configurable option to add retention policy for the subscribed message. Specifically configure whether a message should be cleared after first read, or latch the message until the message is replaced. This is useful for low frequency/only on change state type topics if interested in what last state is.

For backwards compatibility set READ_ONCE as default option.

Have used a template parameter due to the providedBasicPorts function being static, and therefore not able to access virtual members, and the configuration parameter needing to be the same in the tick function.

@tony-p
Copy link
Contributor Author

tony-p commented Jan 29, 2024

@facontidavide Do you have any thoughts on this?

@facontidavide
Copy link
Collaborator

it honestly looks as a feature that goes beyond the scope of this Node.
I am sure some people might find it useful but too much complexity is not good either

@tony-p
Copy link
Contributor Author

tony-p commented Jan 31, 2024

I can definitely see dropping the configurable via port option.

however for the read once vs latched, I think these are both principles that already exist in ros (1). As the current implementation already actively throws away the msg, in the implementation classes we were then naively “saving” the message again and checking it creating a lot of boiler plate. Further we ran into issues that if we reloaded the tree, the same naive implementation would often segfault. (Didn’t get to the bottom of why but guess something with shared ptr pointing to null or so/not being destructed properly).

Other alternative is to “save” on blackboard which is also a lot of boiler plate, makes the tree less readable/clear and I think bad practice.

Either way i think having a base option that doesn’t throw away the message makes a lot of sense as not all topics are high frequency sensor data.

@tony-p
Copy link
Contributor Author

tony-p commented Jan 31, 2024

I created this PR, I think it is a much better solution https://github.com/BehaviorTree/BehaviorTree.ROS2/pull/44/files

It is less overhead in the subscriber node, while allowing a lot of customisation by the implementer. If they want to make it based on a port, they can create the port and add the required logic in the overriden function implementation.

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

Successfully merging this pull request may close these issues.

2 participants