Issues with interoperability with ROS2 (cyclonedds and fastrtps)

[tmayoff]

We have a system that's split between ROS2 and custom software, all the non-ROS stuff uses OpenDDS, and ROS we mainly use CycloneDDS.

When trying to subscribe to certain ROS topics with OpenDDS, we'll only get a handful of messages then nothing ever again. Currently this is happening with trying to subscribe to a low resolution depth image, but we've seen it with topics for joint states and others. With fastrtps we sometimes get more messages but it always ultimately stops. We don't seem to have issues with sending things to ROS, it's almost always when subscribing

These are the OpenDDS side QoS policies in use.

  DDS::DataReaderQos qos = DATAREADER_QOS_DEFAULT;
  qos.history.kind = DDS::HistoryQosPolicyKind::KEEP_LAST_HISTORY_QOS;
  qos.history.depth = 1;
  qos.reliability.kind = DDS::ReliabilityQosPolicyKind::BEST_EFFORT_RELIABILITY_QOS;
  qos.durability.kind = DDS::DurabilityQosPolicyKind::VOLATILE_DURABILITY_QOS;
  qos.liveliness.kind = DDS::LivelinessQosPolicyKind::AUTOMATIC_LIVELINESS_QOS;
  qos.representation.value.length(1);
  qos.representation.value[0] = DDS::XCDR_DATA_REPRESENTATION;

This is the log file with DCPSDebugLevel=1 dds.log

I tried debugging this with wireshark, but I'm not sure what I should be looking for there

[jrw972]

This has some references that may or may not be useful https://github.com/OpenDDS/OpenDDS/wiki/OpenDDS-and-Eprosima-FastDDS-(ROS2)

The log is littered with (143513|143566) ERROR: EncapsulationHeader::to_encoding: expected mutable extensibility, but got CDR/XCDR1 Big Endian Plain

The writer is sending samples using big endian CDR which is not problematic in and of itself.
However, the reader is expecting an encoding that supports mutability like an XCDR1 Parameter List (which OpenDDS doesn't support) or XCDR2.
However, you have explicitly set the allowable representation to DDS::XCDR_DATA_REPRESENTATION.
The combination of mutable and DDS::XCDR_DATA_REPRESENTATION should have caused an error when creating the DataReader.

Please try the following:

First, double check the QoS for the DataReader after you set it and/or create the DataReader.
Specifically, check that qos.representation is correct.
From the code, changes to qos.representation are ignored so this must be set when the DataReader is created.

Second, after you create the TypeSupport for the topic, print out the max_extensibility() and base_extensibility().
The base extensibility needs to agree with the publisher.
Given that it is being sent in XCDR1, this implies that the base extensibility is final so your topic type should be annotated with @final.
If your topic type is complex, you may need to annotate additional types to ensure correct serialization and deserialization.

[jrw972]

You may also want to consider upgrading everything to use XCDR2.

[tmayoff]

The solution here was to use XCDR1 so that's what we're currently using. I'm not sure if cyclonedds or the rmw_cyclonedds supports XCDR2, inspecting the qos it seems to only offer XCDR1, I'll ask over on those repos about moving to XCDR2.

That being said, I confirmed all the QoS are being applied correctly, I've also gone ahead and annotated all the types with @final, and the base_extensibility is good

[tmayoff]

I've now also noticed these errors when trying to send data to a ROS service with cyclonedds

(943123|943144) ERROR avatar_msgs::srv::dds_::Transform_Response_DataReaderImpl::dds_demarshal deserialization failed, dropping sample.

The service receives the request but then the request object seems uninitialized and on the OpenDDS receiving side I get the above error

[jrw972]

That looks like a mismatch in IDL.