revive from Content Filtering Topic,
comments here or on PR are always welcome
Problems
Parameter Event Topic
Each node will publish and subscribe parameter events topic (this is configurable via node option). This topic is to support monitoring parameters for change. It is expected that client libraries will implement the ability to register a callback for specific parameter changes using this topic. there is an internal subscription for each node for /parameter_evetns topic to handle the TimeSource via âuse_sim_timeâ parameter. rclcpp::ParameterEventsFilter
is used to filter the parameter with specific names such as âuse_sim_timeâ. As user interface, AsyncParametersClient::on_parameter_event
is provided to handle parameter events.
there will be all of the parameter activity. That said everyone publishes and subscribes all of the events with this giant topic /parameter_events
. This leads to a lot of unnecessary message transmission over the network.
Action Topics
Each action server will provide two topics named feedback
and status
as followings,
feedback
and status
are topics each mapped with action name and published by action server, and action clients subscribe those topics to get feedback and status. When there are many goals from many clients, the choice to have a single feedback
and status
topic per action server is suboptimal in terms of processing and bandwidth resource. It is up to clients to filter out feedback/status messages that are not pertinent to them. In this scenario, M goals are sent to N clients there is an unnecessary use of bandwidth and processing. especially in extreme cases where M and N are large. (each goal is identified by goal ID based on uuid, filtering out the goal id is done by client library so user application does not need to care.)
ContentFIlteredTopic
ContentFilteredTopic describes a more sophisticated subscription that indicates the subscriber does not want to necessarily see all values of each instance published under the Topic. Rather, it wants to see only the values whose contents satisfy certain criteria. This class therefore can be used to request content-based subscriptions.
Whatâs in it for us?
You can get what you need to receive and that will conserve network resource.
Implementation Consideration
- ContentFilteredTopic interfaces can be used only if implementation supports.
- If rmw implementation does not support ContentFilteredTopic interfaces, filtering will be done internally on subscriber side in
rcl
. - It can create/destroy ContentFilteredTopic based on parent topic.
- It can set/get the filter_expression and expression_parameters for ContentFilteredTopic.
- Filtering expression and expression parameters can be set and get at runtime.
- As decribed above, according to DDS specification, it implies that filtering expression may not be able to be changed dynamically. But to support requirements in ROS2, it must support dynamic reconfiguration for filtering expression and paramter.
- Filtering goal id for action
feedback
andstatus
will be done ROS2 system. - User can specify node name and parameter name to filter the parameter evetns.
- Filtering expression and parameter grammer will be the same with DDS standard between
rcl
andrmw
.