The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
tldr - Here are my answers to your questions, I'll go in a bit more details after
Does this mean that ROS2 is using non-standard serialisation? Looking at the code it seems that serialisation happens independently in the ROS2 RMW layer and is then submitted as a serialized packet to a topic typed by ConnextStaticSerializedData, whatever the original type. This happens for custom types, but e.g. not for the rq/…/list_parametersRequest and other built-in types.
We are using a workaround to access the serialized code directly without deserializing to write it e.g. in rosbags. RTI Connext doesn't provide this functionality out of the box. That's why we implemented a way of type masquerading to do so - it's not really that, but it's somewhat similar. It was only implemented for topics to make pub/sub work. Therefore, you don't see that on services.
Any way to avoid this behavior? It is quite annoying from an interoperability point of view (Admin console, but also other non ROS2 DDS-based applications).
We are aware of the mismatch with RTI's Admin Console, but AFAICT there is no workaround. I am not quite sure if I understand your point on non ROS2 DDS-based applications. Our workaround is safe to use between multiple DDS vendors and is wire compatible (we run quite a few cross talking tests on the ROS2 buildfarm, e.g. Connext and FastRTPS).
Does the behavior change when I would use IDL instead of msg files? I didn't find a way to get that working although it should work on Dashing.
No. The message generation step is independent from the way we send it over the wire.
The change got introduced as a prerequisite for having Connext support rosbags. In order to speed up the write process, it's kind of necessary to obtain an incoming message without deserializing it first, then re-serialize it and write it to disk. Whereas FastRTPS made it quite easy to get access to the buffer with the serialized (CDR) data, there was no straight forward way to do so in Connext.
After discussing with RTI, we've developed that workaround together which essentially publishes a sequence of octets (shown as ConnextStaticSerializedData) which holds the CDR data. We had to patch the API of Connext in order to support that. The changes and more patch files can be found here: https://github.com/ros2/rmw_connext/blob/master/rmw_connext_cpp/resources/patch_files/connext_static_serialized_dataPlugin.cxx.patch#L42-L51
We declare the type of this message however as the actual data type of the message, e.g. std_msgs::msg::String to be wire compatible. https://github.com/ros2/rmw_connext/blob/master/rmw_connext_cpp/src/rmw_publisher.cpp#L141-L152
Needless to say, we did the same workaround for subscribers.
The patch files applied are only compatible for Connext 5.3.1. These patch files have to be modified to match Connext 6.0.0, which we haven't done yet. The patched code is used for publishing in any case, whether you publish serialized code or ROS2 message instances. We could technically refactor the code to only apply the ConnextStaticSerializedData workaround when publishing serialized code. That would however introduce another level of inconsistency.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
