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

Enable CallbackQueue in tf2_ros::MessageFilter #568

Open
DLu opened this issue Dec 2, 2022 · 1 comment
Open

Enable CallbackQueue in tf2_ros::MessageFilter #568

DLu opened this issue Dec 2, 2022 · 1 comment
Labels

Comments

@DLu
Copy link

DLu commented Dec 2, 2022

Feature request

Feature description

Implementation considerations

  • I don't know if there's any particular reason that this has not been ported yet, or whether it causing the problem I'm seeing at this exact moment, but I figured it should at least be documented.
@CursedRock17
Copy link
Contributor

I would like to pick this up, but currently I don't know if it's possible to do this. Beforehand CallbackQueue would add it's own callback, now CallbackGroup is set up at compile time:

the user does not specify any callback group when creating a subscription...

So the CallbackGroup we set up in the MessageFillter must be created before the message_filters::Subscriber or whatever callback object we use. That way we can add the CallbackGroup as an option, or another part of the constructor of that object creating callbacks. Problamatically we've got a chicken and egg situation where the MessageFilter constructor takes in that object to call connectInput.

So, either the user must create their own CallbackGroup to pair with the F & f that MessageFilter takes as a constructor parameter or the user must call connectInput in some separate function, after calling some function setupSomeCallbackGroup, which can occur after the constructor is instantiated. But the latter just seems like the former with extra steps.

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

No branches or pull requests

3 participants