-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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
Add payload tx/rx timeouts to DDS #24309
Conversation
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 672 byte (0.03 %)]
px4_fmu-v6x [Total VM Diff: 808 byte (0.04 %)]
Updated: 2025-02-14T13:44:45 |
Why not leave it enabled by default with a very conservative timeout? |
@dagar: For RX however I don't think it is would be good to enable it by default. In my case I have a setup that does only send but not receive any data via the bridge. This would thus cause a connection reset every x seconds which delays sending. |
392cc3b
to
da0f966
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, just the docs are a bit inconsistent
Solved Problem
We had certain situations where the DDS Agent did stop to send payload to the DDS client.
In that situation the DDS client could still ping the agent and thus the currently existing robustness measurements did not trigger a reconnect.
Solution
Added two new parameters:
UXRCE_DDS_RX_TO
UXRCE_DDS_TX_TO
The already existing TX/RX payload measurements are used to check if payload is still sent/received.
In addition I refactored the DDS logic into a few new methods, as the main loop got really hard to read.
Changelog Entry
For release notes:
Alternatives
dds_topics.yaml
. The timeout to set however depends on the pub rate of the topic, which could be dynamic. To avoid decreasing the robustness, the parameter allows the user to set the timeout that is actually required for the system.Test coverage