content-based topic subscriptions?

[G.A. vd. Hoorn - 3ME]

Hi all,


Not normally into cross-posting, but figured this list might be
frequented by more ppl in-the-know.

For convenience, the main text of the question on ROS Answers ([1]):

__________________________________________________________


Seeing as ROS2 will be using DDS as its middleware of choice, I was
wondering if it would also support content filtered topic subscriptions
next to the normal (ROS1) topic subscriptions.

Being able to filter messages on topics by content is a very powerful
capability (especially with writer-side filtering), making bus-like
topologies much more feasible in ROS applications without requiring each
node to implement some kind of filtering mechanism itself.

Is this something that will be supported through the 'standard' ROS2-DDS
API (I did not find anything in the design docs, but perhaps I've missed
it), or will this require node implementors to bypass the API and reach
into the underlying DDS implementation (if possible)?

The RTI community site has an example here.

__________________________________________________________


The example on the RTI site is at [2].


Gijs


[1]
http://answers.ros.org/question/209935/ros2-content-based-topic-subscriptions/
[2] https://community.rti.com/kb/example-code-custom-content-filter

[Dirk Thomas]

Hi Gijs,

content-based subscriptions are a really interesting feature.

The current ROS 2 prototype only uses it internally to implement request/reply on top of publish/subscribe in OpenSplice (https://github.com/ros2/rmw_opensplice/blob/e78a44c3a3b29e261d8ed63bcb8a4ea06e65df67/rosidl_typesupport_opensplice_cpp/include/rosidl_typesupport_opensplice_cpp/requester.hpp#L107-L110).

The current RMW interface does not offer an API for specifying a filter criteria though.

But since the feature would be pretty useful it might be added in the future to allow custom filters as well.

We would need to ensure that it is possible to specify the filter criteria in a vendor agnostic way.

Cheers,

- Dirk

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[G.A. vd. Hoorn - 3ME]

On 31/05/15 19:25, Dirk Thomas wrote:
> Hi Gijs,
>
> content-based subscriptions are a really interesting feature.
>
> The current ROS 2 prototype only uses it internally to implement
> request/reply on top of publish/subscribe in OpenSplice (
> https://github.com/ros2/rmw_opensplice/blob/e78a44c3a3b29e261d8ed63bcb8a4ea06e65df67/rosidl_typesupport_opensplice_cpp/include/rosidl_typesupport_opensplice_cpp/requester.hpp#L107-L110
> ).

ok.

As far as I'd understood, the DDS spec was recently extended to include
proper support for the client/server interaction style. Is what you
linked a temporary solution, just for OpenSplice or is that actually how
it's supposed to be done?

> The current RMW interface does not offer an API for specifying a filter
> criteria though.
> But since the feature would be pretty useful it might be added in the
> future to allow custom filters as well.
> We would need to ensure that it is possible to specify the filter criteria
> in a vendor agnostic way.

Most examples I've seen use a string to encode the filter expression.
That would seem rather portable, as the expression refers to fields on
the IDL level which should be the same across all vendors.

Do you expect difficulties implementing this for the different vendors?


Gijs

[William Woodall]

On Fri, Jun 5, 2015 at 7:09 AM, G.A. vd. Hoorn - 3ME <g.a.van...@tudelft.nl> wrote:

On 31/05/15 19:25, Dirk Thomas wrote:

Hi Gijs,

content-based subscriptions are a really interesting feature.

The current ROS 2 prototype only uses it internally to implement
request/reply on top of publish/subscribe in OpenSplice (
https://github.com/ros2/rmw_opensplice/blob/e78a44c3a3b29e261d8ed63bcb8a4ea06e65df67/rosidl_typesupport_opensplice_cpp/include/rosidl_typesupport_opensplice_cpp/requester.hpp#L107-L110
).

ok.

As far as I'd understood, the DDS spec was recently extended to include proper support for the client/server interaction style. Is what you linked a temporary solution, just for OpenSplice or is that actually how it's supposed to be done?

The additional specification for request/reply on top of DDS is still in the process of being ratified, or if it has been ratified since I last checked, it is still in the process of being adopted by the DDS implementations available to us. Both RTI and PrismTech had their own versions of request/reply and have yet to release a version with the API which goes with the new specification.

The specification describes two possible ways to do request/reply on top of DDS's pub/sub, the so called "basic" and "enhanced" profiles. The "basic" profile is built entirely on top of the existing API's and requires no additional changes to the underlying system. The "enhanced" profile is more elegant but it requires additional features in the basic DDS implementation to be implemented. At least that's how I've interpreted the state of affairs.

We essentially implemented the "basic" profile on top of OpenSplice for our request/reply using topic filtering.

 

The current RMW interface does not offer an API for specifying a filter
criteria though.
But since the feature would be pretty useful it might be added in the
future to allow custom filters as well.
We would need to ensure that it is possible to specify the filter criteria
in a vendor agnostic way.

Most examples I've seen use a string to encode the filter expression. That would seem rather portable, as the expression refers to fields on the IDL level which should be the same across all vendors.

It should be, but we've found that even things that should be portable is often not in some subtle way. Also, we've strived to hide any DDS specific details from the ROS user space to remain untethered to their API's. So for both reasons, we'd probably want to come up with a DDS agnostic way to express this in the ROS 2 API. It's definitely a feature that we're excited to try out.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/