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

Fallback content filtering #982

Open
4 tasks
Tracked by #282
fujitatomoya opened this issue May 3, 2022 · 2 comments
Open
4 tasks
Tracked by #282

Fallback content filtering #982

fujitatomoya opened this issue May 3, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@fujitatomoya
Copy link
Collaborator

Feature request

Background

Content Filtering Subscription is new feature introduced in Humble, see Content-Filtering-Subscription
Currently Content Filtering Subscription depends on RMW implementation, so that if underlying RMW implementation does not support Content Filtering Subscription interfaces, user application cannot use this feature in ROS 2.
This could be problem for the application cz its behavior could not be consistent once RMW implementation is changed.
The application can still manage this situation in user space, but this would be burden for user application code.
Besides, subscriptions are the endpoints that we use mostly in application.

This has been discussed on ros2/design#282 (comment)

Feature description

We will provide fallback filtering function in rcl or else where that DOES NOT depend on rmw implementation.
Fallback filtering will conceal the rmw dependency from user perspective, so that user application can get rid of if rmw does not support code from the user space.

Implementation considerations

Performance

Fallback filtering will be only Reader-Filtering.I
It always runs executor to take out the message from rmw, and then de-serialize the message to see what's in the message for filtering.
This said that there will be no performance improvement compared to filtering in user application.
Reader-Filtering in rmw is different from above, since there is no need to take out the data using executor, besides it does not need to de-serialize the message before filtering. This is achieved by TypeObject in Fast-DDS and TypeCode in RTI Connext DDS.

Tasks

  • Basic Design (already proposed ContentFilteredTopic Design Proposal. design#282 (comment))
  • ROS 2 filtering expressions and parameters (could be subset of DDS spec, but needs to be discussed.)
  • Implementation (rcl and other repos. such as tokenizer, type support c/c++, client libraries)
  • Documentation (must be aligned and explained with fallback filtering.)
@fujitatomoya fujitatomoya self-assigned this May 3, 2022
@fujitatomoya fujitatomoya added the enhancement New feature or request label May 3, 2022
@fujitatomoya
Copy link
Collaborator Author

Some consideration as below, comments and feedback are welcome.

  • RCL filtering is opt-out. and if RMW support CFT, RCL filtering is disabled internally.
  • We will provide tokenizer and parsers for RCL filtering expression and parameters.
    • This will be checked at the 1st place regardless of underlying filtering.
    • Subset of DDS spec.
  • RMW filtering and RCL fallback filtering are exclusive. (but ROS 2 filtering expression and parameters are applied for both case)
    • with RCL filtering, if the expression and parameters cannot be applied, it will return error.
    • with RMW filtering, if the expression and parameters cannot be applied, it will print the warning but passed to RMW filtering. and RMW returns error if cannot be applied.
  • Environment value to use RCL fallback only even if RMW filtering is supported.
    • For instance, RMW supports CFT but some problems observed in RMW implementation. So we can use this flag to fallback RCL filtering in force w/o code change.

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

No branches or pull requests

1 participant