I am trying to interface our ROS2 project with a third party that wants to communicate using DDS. The third party is providing me with IDL files for the messages. These IDL files include features like enums and inheritance that aren’t supported in the ROS message format. Is there an easy way to get the ROS2 system to build messages into a package directly from IDL, instead of having to start with .msg files?
1 Like
No, not currently.
We have talked in the past about supporting an IDL->.msg workflow to support your use case, but because we’ve not had to do it yet, we haven’t implemented it. Also, I always operated under the assumption that extra features like enum and inheritance would not be supported in this workflow.
You should also be aware, that our use of topics and partitions within DDS will change soon (proposal has been accepted, we’re in the process of implementing it now), see:
And some examples of that:
http://design.ros2.org/articles/topic_and_service_names.html#examples-of-ros-names-to-dds-concepts
This will likely affect your ability to subscribe to an existing DDS topic from ROS, and perhaps your ability to create a publisher in ROS with the exact characteristics you’d like on the DDS side. We’re aware of this use case, however, and have some ideas about how to allow you to publish and subscribe to “native” DDS topics without any of the ROS specific mangling:
http://design.ros2.org/articles/topic_and_service_names.html#communicating-with-non-ros-topics
Breaking the ability for “native” DDS communication seems harmful. That seems like a helpful feature for adoption on production systems. I see the proposal for partitions/topics has ideas for fixing “native” DDS comms, but nothing has been settled on. I also have seen your proposed Roadmap for releases, including V1 in Dec. Does the current Roadmap include resolving this incompatibility?
@SecretaryBirds, I agree and that’s why we spent some time thinking about it with respect to the topic name and partitions.
The current proposal has the benefit that so long as the target DDS configuration doesn’t require a partition that violates our topic name rules (e.g. contains invalid characters like .), then all we need is an option to avoid putting the ROS specific prefix on the topic, which should be easy to do, and it’s my intention to do that on the first implementation pass (since it’s easy to do).
We didn’t settle on a way to pass “exact” topic name and partitions as described as possibilities in the design document. For features beyond “avoid the ROS prefix in the partition name” I do not believe they are on our roadmap. But they could be points where community contributions would be tractable.
If you need a very specific partition name or multiple partition names, then it gets harder to support that through the ROS API. An alternative which makes lots of things possible, but also addresses this issue, is to implement the ros_to_<dds impl> packages, which allow you to get access to the underlying DDS objects for various ROS primitives. For example, if you create a ROS subscription, then with this package (say ros_to_fastrtps for example) you could get the underlying DDS::DataReader’s, DDS::Subscriber’s, DDS::Topic’s, etc. and do to them whatever you want, including creating additional DataReaders. There may be consequences you have to deal with when you do this (it might change ROS API behavior), but it gives you full control to do what is required in various cases.
Unfortunately, I see the mismatched IDL types on the topics to be a larger barrier to this working than the topic names and partitions being used.
I must say the idea to define a custom non compatible naming scheme that hinders the communication with non ROS2 DDS nodes shocks me a little bit. What is the point of using a standard communication system if you do not intend to use it in a standard way?
Wasn’t the broader idea behind using a proven standardized communication protocol to make ROS2 more compatible and wider accepted? To me the whole idea of designing a middleware agnostic system seem not to be really smart - it creates incompatibilities and does not allow to really embrace the underlying system nor to use its specific features. It would be like using TCP/IP but not letting details like IP addresses and DNS appear at the surface but instead do all kinds of name-mangling and concept translations.
The ROS2 design team should be aware of the rise of IoT. I personally would suggest to design ROS2 as compatible as possible. Otherwise I see the danger for ROS to be superseded by successful IoT systems that can be used for the robotic use-case as well…
After reading more of the ROS2 design documents some points become clearer to me.
Please correct me if I got something wrong:
- ROS2 only uses a subset of the DDS functionality while hiding all of the middleware implementation details (e.g. IDL definitions) to the package author (who creates ROS specific msg, srv files etc.).
- The protocols on top of DDS used by ROS2 for services and actions (preemptable serices) are ROS specific.
- It was decided to completely hide the fact that DDS is used in order to keep the way open for non-DDS middleware implementations.
- Non-ROS DDS nodes could subscribe to ROS2 nodes but the other way round is only possilbe if the DDS node would restrict itself to the ROS2 compatible feature/type subset and adhere to the ROS2 naming-rules.
- All ROS2 messages are effectively serialized twice. First from language specific ROS2 message classes to a representation that can be processed by the selected DDS middleware library and then from the DDS library to a format that goes over the wire.
- Interop with non-ROS DDS nodes was not the driving factor for the ROS2 design. Relevant points for the choice of DDS were standardization, stability, security, professional impls etc.
So it seems the DDS<->ROS2 interop is mostly a one-way thing by design, e.g. it is not possible to access all DDS featues via the ROS2 API. A ROS2 node that had to communicated with DDS nodes usind complex IDL definitions had to interact with a concrete DDS implementation beside of the ROS libs (middleware implementation specific).
Is it now possible to communicate with the ROS2 idl messages to an external tool (Non-ROS topics) ?
Moderator edit: Duplicate of https://answers.ros.org/question/293158/how-can-i-use-the-ros2-idl-files-to-connect-with-a-non-ros-machine/ please follow up there.
On the other hand, contaminating a namespace with foreign objects/messages is also fraught with peril. You may be better off to write a bridge node for this type of application.