-
Notifications
You must be signed in to change notification settings - Fork 294
Description
Description
Trying to record with ros2 bag record a topic published by a DDS framework, the output bag is filled in correctly when the topic message type contains only primitive fields. However, when it is a composite message that includes custom submessage types (e.g., Pose, Header, or other user-defined structures), ros2 bag record consistently fails and exits with the following error.
[ERROR] [1767886717.258078601] [rosbag2_recorder]: Failure in topics discovery.
Error: Poseros2 topic list and ros2 topic echo perfectly work so DDS discovery, type matching, and deserialization are functioning correctly.
The ROS 2 workspace contains a minimal interface-only package that provides a msg/ directory populated exclusively with plain .idl files. Could it be related to this issue?
System
- OS: Ubuntu 22.04 LTS
- ROS 2 Distro: ROS 2 Jazzy
Additional context
- 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. - The provided 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].
Performed checks
This is a list of all checks we performed without being able to modify the undesired behavior reported in the above section:
- All relevant idl files are correctly placed in the
msgfolder inside the interface package and listed in the packageCMakeLists.txtand thus, successfully built - IDL definitions comply with ROS 2 requirements but probably using plain IDL files rather than .msg files converted internally by ROS may introduce subtle differences in the message generation pipeline
- 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_cppinstead of defaultrmw_fastrtps_cpp