Comments (7)
The toplevel state is not just the maximum of all the levels. Its calculated with the following algorithm
if maximum_level > ERROR and minimum_level <= ERROR
# one or more STALE, but not all of them
level = ERROR
else:
level = maximum_level
I would propose to change this to the following, because I think it's more logical.
if maximum_level == STALE and maximum_level_without_stale < ERROR
# one or more STALE, but no errors
level = STALE
else:
level = maximum_level_without_stale
This will be the difference between the two algorithms:
diagnostic1 | diagnostic2 | current | proposed |
---|---|---|---|
stale | ok | error | stale |
stale | warn | error | stale |
stale | error | error | error |
stale | stale | stale | stale |
from diagnostics.
Hi @Rayman and thank you for your comment. I agree with you that this makes more sense but, as you stated, this is a breaking change so for Noetic I do not believe it can be merged as is. I am not sure how the ros2 maintainers would see this change for the ros2 version...
from diagnostics.
Hi @Rayman. Thanks for your suggestion. Just to be clear: The stale state is set by the generic analyzer if no message was received within a given timeout:
Which can be useful information on the actuality of a state.
If I get it correctly, your suggestion is to treat it in aggregation like the other levels and aggregate it in the group. There, I would honestly have a hard time to rate it in severity between the other levels. Currently, it is level 3 which reads as the highest priority. This means you would only see stale on the highest level, even if another item in that group is in the error state. This can not be the intended behavior. Changing these levels would be a SERIOUS breaking change.
What is your take on that?
from diagnostics.
What I find counter-intuitive about the current behavior is that if you have three leaf diagnostics rolled up into a group, the discard_stale
doesn't seem to have an impact on the parent status. For example, if bar
and baz
in the example below go stale, but foo
is OK, I would intuitively think that the part
group should also be OK. However, what I'm seeing is that foo
currently gets marked as ERROR
.
diagnostics_aggregator:
ros__parameters:
pub_rate: 1.0
path: 'robot'
analyzers:
part:
type: 'diagnostic_aggregator/AnalyzerGroup'
path: 'part'
foo:
type: 'diagnostic_aggregator/GenericAnalyzer'
path: 'foo'
find_and_remove_prefix: ['/foo:']
num_items: 1
bar:
type: 'diagnostic_aggregator/GenericAnalyzer'
path: 'bar'
find_and_remove_prefix: ['/foo:']
discard_stale: true
baz:
type: 'diagnostic_aggregator/GenericAnalyzer'
path: 'baz'
find_and_remove_prefix: ['/baz:']
discard_stale: true
from diagnostics.
I did not want to propose to merge a breaking change in noetic, so I've implemented my proposed change in our fork: https://github.com/nobleo/diagnostics. Feel free to use it
I've implemented the change for the toplevel diagnostics and for the AnalyserGroup
.
from diagnostics.
I also added my implementation here: #315
from diagnostics.
Since this was a breaking change for Noetic, it probably also is for Humble and Iron?
Does it make sense to put some effort into this before ROS Jazzy?
from diagnostics.
Related Issues (20)
- Incorrect dependency export of pluginlib HOT 5
- Use Diagnostics aggregator node with other topic names HOT 1
- [Question] How to disable "individual" diagnostic messages HOT 4
- [ros2] Diagnostics aggregator base path HOT 2
- Logging error when running Python `Updater` in `verbose == True` mode HOT 1
- Python DiagnosedPublisher crashes on publishing headerless topic HOT 2
- Updater::add to take ownership of FunctionDiagnosticTask HOT 2
- CI issues with ntp_monitor test
- [Feature request] Add possibility to load further aggregator configurations after node was started HOT 1
- About the use of this diagnostic node package HOT 6
- How to implement heartbeat diagnostic in ros2 system HOT 1
- Aggregator and updater with fully qualified node name
- Migrate hd_monitor.py to ROS2 HOT 2
- Make diagnostic aggregator composable HOT 1
- ‘error_level’ may be used uninitialized HOT 1
- NTP monitor: implement diagnostic to check if synchronized to the correct source HOT 1
- diagnostic_updater binaries are not available for RHEL HOT 5
- Temporarily rolling back jazzy 4.2.0-1 update due to downstream issues. HOT 9
- Iron buildfarm problems HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from diagnostics.