Description
We are running a custom middleware framework built on top of eProsima Fast DDS inside a Docker container, and we are attempting to consume and record topics from a ROS 2 Jazzy system running in a separate Docker container on the same host.
The two systems are configured to interoperate via Fast DDS Discovery Server, with both ROS_DISCOVERY_SERVER and ROS_SUPER_CLIENT correctly set on the ROS 2 side.
On the ROS 2 side, the workspace contains a minimal interface-only package that provides a msg/ directory populated exclusively with plain .idl files.
These IDL files are duplicates of the IDL definitions used by our native DDS framework, except for minor modifications required to ensure compatibility with the subset of the OMG IDL 4.2 specification supported by ROS 2 [source1, source2].
With this setup:
ros2 topic list correctly reports all DDS-published topics,ros2 topic echo <topic_name> consistently produces valid and expected output,
indicating that DDS discovery, type matching, and deserialization are working as intended.
As a concrete example, consider the topic /state with message type interface/msg/State.
When State is a simple message (i.e., composed exclusively of primitive fields such as string, numeric types, or flat sequences), the command ros2 bag record /state executes successfully and produces a valid, populated bag file.
However, when State is a composite message (i.e. it contains one or more fields whose types are custom message definitions, such as Pose, Header, or other user-defined structures), invoking ros2 bag record /state consistently fails and terminates with the following error:
[ERROR] [1767886717.258078601] [rosbag2_recorder]: Failure in topics discovery.
Error: Pose
In order to further clarify, please consider the State.idl message type declaration as follows:
#include "Pose.idl"
module interface
{
module msg
{
struct State
{
string robot_name;
interface::msg::Pose pose;
};
};
};and please note that Pose.idl message is displayed in the following and both messages are correctly placed in the msg folder inside the interface package and listed in the package CMakeLists.txt and thus, successfully built.
module interface
{
module msg
{
struct Pose
{
double position[3];
double orientation[4];
};
};
};We believe our IDL definitions comply with ROS 2 requirements, as several ROS 2 CLI tools (e.g., ros2 topic list and ros2 topic echo) behave correctly. That said, we are open to the possibility that using plain IDL files rather than .msg files converted internally by ROS may introduce subtle differences in the message generation pipeline.
While we suspect such differences could be related to the issue we are observing, we have not been able to identify the exact cause. We would therefore appreciate any clarification on known limitations or behavioral differences when using plain IDL interfaces in ROS 2, particularly in relation to rosbag2.
Performed checks
This is a list of all checks we performed without being able to modify the undesired behavior reported in the above section:
- Containers network issue: both containers are launched with --net=host and the discovery server should is reachable from both sides
- Not using any XML for extended configuration settings on DDS side
- QoS yaml override on ROS side
- Introspection-related files are as expected on ROS side
- Exporting
RMW_IMPLEMENTATION=rmw_fastrtps_dynamic_cpp instead of default rmw_fastrtps_cpp
System info:
- OS: Ubuntu 22.04 LTS
- ROS Distro: ROS 2 Jazzy
Description
We are running a custom middleware framework built on top of eProsima Fast DDS inside a Docker container, and we are attempting to consume and record topics from a ROS 2 Jazzy system running in a separate Docker container on the same host.
The two systems are configured to interoperate via Fast DDS Discovery Server, with both
ROS_DISCOVERY_SERVERandROS_SUPER_CLIENTcorrectly set on the ROS 2 side.On the ROS 2 side, the workspace contains a minimal interface-only package that provides a
msg/directory populated exclusively with plain.idlfiles.These IDL files are duplicates of the IDL definitions used by our native DDS framework, except for minor modifications required to ensure compatibility with the subset of the OMG IDL 4.2 specification supported by ROS 2 [source1, source2].
With this setup:
ros2 topic listcorrectly reports all DDS-published topics,ros2 topic echo <topic_name>consistently produces valid and expected output,indicating that DDS discovery, type matching, and deserialization are working as intended.
As a concrete example, consider the topic
/statewith message typeinterface/msg/State.When
Stateis a simple message (i.e., composed exclusively of primitive fields such as string, numeric types, or flat sequences), the commandros2 bag record /stateexecutes successfully and produces a valid, populated bag file.However, when
Stateis a composite message (i.e. it contains one or more fields whose types are custom message definitions, such asPose,Header, or other user-defined structures), invokingros2 bag record /stateconsistently fails and terminates with the following error:[ERROR] [1767886717.258078601] [rosbag2_recorder]: Failure in topics discovery. Error: PoseIn order to further clarify, please consider the
State.idlmessage type declaration as follows:and please note that
Pose.idlmessage is displayed in the following and both messages are correctly placed in themsgfolder inside theinterfacepackage and listed in the packageCMakeLists.txtand thus, successfully built.module interface { module msg { struct Pose { double position[3]; double orientation[4]; }; }; };We believe our IDL definitions comply with ROS 2 requirements, as several ROS 2 CLI tools (e.g., ros2 topic list and ros2 topic echo) behave correctly. That said, we are open to the possibility that using plain IDL files rather than .msg files converted internally by ROS may introduce subtle differences in the message generation pipeline.
While we suspect such differences could be related to the issue we are observing, we have not been able to identify the exact cause. We would therefore appreciate any clarification on known limitations or behavioral differences when using plain IDL interfaces in ROS 2, particularly in relation to
rosbag2.Performed checks
This is a list of all checks we performed without being able to modify the undesired behavior reported in the above section:
RMW_IMPLEMENTATION=rmw_fastrtps_dynamic_cppinstead of defaultrmw_fastrtps_cppSystem info: