diagnostic_msg/DiagnosticStatus should have "stale"?
I thought I ask this question before submitting ticket on github since I'm not yet sure 100%.
Why does msg type diagnostic_msg/DiagnosticStatus not have level of operations STALE?
DiagnosticStatus defines 3 levels of operations (from 0 to 2). But GenericAnalyzer in diagnostic_aggregator publishes level 3, or stale (I recognized this while running turtlebot_gazebo/launch/turtlebot_empty_world.launch).
Assuming it's recommended to extend GenericAnalyzer when implementing your own robot, the cleanest solution would to include stale in the msg format imho but how does this sound?
I believe
staleis when the message is not published at all, hence there is no code for it in the message, itself.This is how it is implemented (last time I checked), so it is never send by the program the diagnostic originated from. The aggregator adds this.
It's never sent from the origin, but if we're designating "3" as "STALE" then we should still enumerate it.
If that is a quasi-standard, then yes, it should be in the message before it becomes commonly used differently. The only problem is that it does not make a lot of sense for a diagnostic component to set the status to STALE.
Missing data, etc. should be a WARN or ERROR. For a supervisor it does make sense. So this should be documented properly to not get confused, i.e. STALE is not sensor stale, but component/driver stale.
@dornhege and all, looks like we've come to conclusion - to add appropriate document to avoid confusion (ie. no change to the msg type). But where? Analyzer's doc? Or msg type's?
@IsaacS, I do think it should go in the message type. Either that or to really fix this,
diagnostic_aggregatorshould do something different with stale data. I don't think we should ever be setting an enumeration mode that isn't defined as such in the message type.@jbohren oh ok, so you're on "modifying msg type" side. Then I now feel this comment area isn't the best appropriate place to continue discussion. Is it ok to start a discussion on users' ML for such a small (but not trivial) change like this?