Two domain participants on the same domain in the same application do not communicate unless run in the debugger. #5931
Replies: 3 comments 1 reply
-
A couple other things I've messed with:
|
Beta Was this translation helpful? Give feedback.
-
I also tested just using FastDDS with none of my wrapper code. The issue remains. But, I figured it out... I had a wait between
|
Beta Was this translation helpful? Give feedback.
-
The default durability settings imply that a reader will not receive samples written by the writer before it discovered the reader. Setting the reader as TRANSIENT_LOCAL, and the reliability as RELIABLE would allow removing the wait. Another option is to wait for the writer to discover the reader before writing. You could use |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have written
DDSNode
class, which is a wrapper class for a DomainParticipant. It bundles all of the DDS communication logic needed for a containing class or application.When I create a single one of these nodes, it can communicate with itself via its publisher and subscriber. It writes some data out, and reads that data back in.
However, when I create a second
FastDDSNode
containing a new domain participant within the same application, the two cannot communicate unless I run the application in the debugger.I'm not sure the best order in which to present the relevant code, but here's my best shot:
First, I'll show you the code that sets up the publishers/subscribers/readers/writers for this
FastDDSNode
classThen, I'll show you the type erased wrapper class for writing generic IDL generated data types, and how
FastDDSNode.read()
andFastDDSNode.write()
work with this type erased class.Finally, I will show you some simple unit tests I have written that verify a single domain participant can communicate with itself, but not with other domain participants subscribed to the same topics.
1. FastDDSNode wrapper class
2. TypeErasure for reading/writing generic data with a single read/write method
And here are the read/write methods that utilize the type erasure classes:
3. Unit tests, written with GTest
The following unit test will pass in the debugger, but fail if I just run the compiled executable.
The important note is that
DataReader->take_next_sample()
returnsRETCODE_OK
andinfo.valid_data == true
... but on inspection, the read data only contains default values rather than the ones written by theDataWriter
.Additionally, if you alter the test so that
node_a
does both the writing AND reading, it will pass.Simply this line
success = node_b.read("TestSensorTopic", in_data_wrapper);
to this:
success = node_a.read("TestSensorTopic", in_data_wrapper);
Beta Was this translation helpful? Give feedback.
All reactions