Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic Type Distribution Doesn't Work For Nested Structs (with minimal example) #2984

Closed
1 task done
methylDragon opened this issue Sep 27, 2022 · 2 comments
Closed
1 task done
Labels
bug Issue to report a bug

Comments

@methylDragon
Copy link
Contributor

methylDragon commented Sep 27, 2022

⚠️ This is a blocker for demoing a ROS 2 REP reference implementation including FastDDS for ROSCon 2022 ⚠️

Is there an already existing issue for this?

  • I have searched the existing issues

Expected behavior

With a modified form of the HelloWorld dynamic data example that publishes a message like:

HelloWorld:
  string string_field
  bool[5] bool_static_array_field
  inner nested_field

inner:
  bool nested_bool_field

Attempt to publish and subscribe. It should work, and the eprosima::fastrtps::types::DynamicType_ptr that gets passed to the SubListener's on_type_discovery method should match the DynamicType that was constructed on the publishing process.

Current behavior

The DynamicType does not match.

Printing the type members (with names) shows that the nested member is MISSING. This causes the subscriber to not be able to receive messages because the type matching fails.

GENERATED TYPE:
bool_static_array_field:0x55c960c07240
nested_field:0x55c960c07380  <--- MISSING IN TYPE RECEIVED BY SUBSCRIBER
string_field:0x55c960c07100

RECEIVED TYPE:
bool_static_array_field:0x7fec600454b0
string_field:0x7fec60045370

Additionally, if you deliberately construct the type on the subscriber (with the same code used in the publisher), the publishing works as expected. So this issue is localized to the transmission of the type information but not the data itself.

The relevant log for this behavior is here:

$ ./src/nested-field-type-registration-bug/pub 

GENERATED TYPE:
bool_static_array_field:0x559467f82240
nested_field:0x559467f82380
string_field:0x559467f82100

Publisher running. Please press enter to stop the Publisher at any time.
Publisher matched

== SENT ==
string_field: A message!
bool_static_array_field: [true, true, true, true, true]
nested_field: <struct/bitset>
	nested_bool_field: true

== SENT ==
string_field: A message!
bool_static_array_field: [false, false, false, false, false]
nested_field: <struct/bitset>
	nested_bool_field: false
$ ./src/nested-field-type-registration-bug/contrived_sub  <--- CONTRIVED SUB
Subscriber running. Please press enter to stop the Subscriber
Discovered type: HelloWorld from topic DDSDynHelloWorldTopic

RECEIVED TYPE:
bool_static_array_field:0x7f76c00453e0
string_field:0x7f76c00452a0

Subscriber matched
Received data of type HelloWorld
string_field: A message!
bool_static_array_field: [true, true, true, true, true]
nested_field: <struct/bitset>
	nested_bool_field: true
Received data of type HelloWorld
string_field: A message!
bool_static_array_field: [false, false, false, false, false]
nested_field: <struct/bitset>
	nested_bool_field: false

Steps to reproduce

I've prepared a minimal example:
methylDragon/fastdds-pr-minimal-examples

Once built, run:

cd build

# On separate terminals
./src/nested-field-type-registration/pub
./src/nested-field-type-registration/sub

The relevant code can be found here

For the deliberate construction example, instead run:

cd build

# On separate terminals
./src/nested-field-type-registration/pub
./src/nested-field-type-registration/contrived_sub

Fast DDS version/commit

FastDDS 2.8.x: 78473a0

The examples workspace is using that specific SHA in the submodule, for convenience.

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

This is on 22.04.
I don't know what the cause of the problem is, I haven't been looking into it.

This bug is hampering the progress of the dynamic types and type introspection reference implementation for ROS 2 as proposed in REP 2011, to be presented in ROSCon 2022, and for implementing the actual feature.

It is essential that type description distribution on the XTypes/DDS layer works for detecting type mismatches. So this is quite critical, especially as FastDDS is currently the default for ROS2 and the feature being implemented would be very impactful/life in the core of ROS2.

XML configuration file

No response

Relevant log output

$ ./src/nested-field-type-registration-bug/pub 

Generated type:
bool_static_array_field:0x55c960c07240
nested_field:0x55c960c07380
string_field:0x55c960c07100

Publisher running. Please press enter to stop the Publisher at any time.
$ ./src/nested-field-type-registration-bug/sub 
Subscriber running. Please press enter to stop the Subscriber
Discovered type: HelloWorld from topic DDSDynHelloWorldTopic

RECEIVED TYPE:
bool_static_array_field:0x7fec600454b0
string_field:0x7fec60045370


### Network traffic capture

_No response_
@methylDragon methylDragon added the triage Issue pending classification label Sep 27, 2022
@JLBuenoLopez
Copy link
Contributor

There are several known issues related with Dynamic Types in Fast DDS. Thus, a refactor is being undertaken in order to fix the Dynamic Types implementation. It is expected to be released with Fast DDS v2.11.0 scheduled for June 2023.

@JLBuenoLopez JLBuenoLopez added bug Issue to report a bug and removed triage Issue pending classification labels Apr 13, 2023
@JLBuenoLopez JLBuenoLopez linked a pull request Apr 13, 2023 that will close this issue
13 tasks
@elianalf
Copy link
Contributor

The Dynamic Type Refactor has been integrated in Fast DDS v3.0.0 which will be released soon. This issue may be solved in the new version of Fast DDS, so I will close this issue for now. If the issue persists, feel free to reopen it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue to report a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants