fujitatomoya
commented
2 years ago 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.
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 https://github.com/ros2/design/pull/282#issuecomment-1055894950
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 supportcode 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-Filteringin 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 byTypeObjectin Fast-DDS andTypeCodein RTI Connext DDS.Tasks
Basic Design(already proposed https://github.com/ros2/design/pull/282#issuecomment-1062110693)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.)