-
Notifications
You must be signed in to change notification settings - Fork 183
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
Aggregator: publish diagnostics_toplevel_state immediately when error is received #317
Aggregator: publish diagnostics_toplevel_state immediately when error is received #317
Conversation
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.
The changes look good. Thanks for your contribution.
Can you please additionally provide tests. See https://github.com/ros/diagnostics/pull/197/files#diff-d52d1bb554fc7e0c46c8810896296d59f4bf8902bd0eca3c8629e231989c76af for an inspiration.
2e69d78
to
9ea8c8f
Compare
a3c441e
to
b000489
Compare
bf64c5f
to
f7638ae
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.
Thanks for your contribution. This looks very nice.
@outrider-jhulas Do you have an idea what the problem is here: https://build.ros2.org/job/Hdev__diagnostics__ubuntu_jammy_amd64/31/testReport/junit/(root)/projectroot/test_test_critical_pub_py/ |
I opened this: #323. If I can't fix it i will have to revert this |
Seems like sometimes the aggregator publishes stale msg before the test starts. This should fix it. Let me know if you want me to make a new MR
|
* more info on failing comparisons * ignoring old wrong messages * fixes in ntp monitor test --------- Signed-off-by: Christian Henkel <[email protected]>
Sorry to be late to the party. But why was this done only for I would expect this to be active on all regresions. So dropping from |
To improve the
diagnostic_aggregator
, additional functionality is added to publish thediagnostics_top_level_state
as soon as a diagnostic message with anERROR
state is received.This can be particularly helpful, when using the
diagnostics_top_level_state
as a system error indicator. For example, immediately stop the robot, as soon as any error in the system is detected.With the current implementation, the error state will take up the the
1/pub_rate
seconds to be published, which is a significant delay in many robotic systems.This point was already brought up in !197 and #48.
To guarantee backwards compatibility, the functionality is disabled by default and can be enabled with the
critical
parameter set totrue
.To avoid spamming the topic, the
critical
error state message will be published only once, and only if the system is error free.