Directly publish to /diagnostics_agg on non-ok status

[MCFurry]

I relate to #48 and internally we started using a custom aggregator for this purpose.
We thought it could be useful to share this.

Moreover, this aggregator also fills the /diagnostics_toplevel_state message with the message that caused the non-ok status. We found this particularly useful to feed this to a robot operator via a display for example to have a clue about what is going on, without him needing a computer with Robot Monitor open. (Think of a display in a remote control, or a simple LCD on the robot) But also for logging purposes it could be nice to have this.

(My editor automatically removes trailing whitespaces, so sorry for those diffs..)

[g-gemignani]

Hi @MCFurry and thank you for your PR.
Please correct me if I am wrong, but the changes you are proposing are an ABI-breaking change. I am not sure how this kind of changes should be handled in the future... Maybe @trainman419 or @Karsten1987 can comment here since they were involved in a PR with the same issue in #88?

[MCFurry]

Thanks for your response.

I don't know about ABI compatibility, what is the main issue when breaking this?

Please advice if you agree on the functionality but have an idea about staying ABI-compatible.

[g-gemignani]

The main issue with ABI compatibility is that, by modifying classes onto which other packages rely on, in order to ensure a proper functioning of the downstream packages, we would have to ask everyone to rebuild such packages again. This is why, usually, ABI breaking changes are introduced when switching versions. Since noetic is the last version that will be published for ROS1, I am not sure how we should handle such changes. That is why I was asking the opinion of people more expert than me.

[MCFurry]

Ahh thanks for the explanation. I see the issue now, especially with ROS1.

I guess it will be tricky getting this feature in without ABI breaking changes then, but please advice if someone sees a way.

If the feature itself is still considered useful to others I can of course try to put this in the ROS2 version?

[g-gemignani]

The feature itself is definitely useful in my opinion. What could be maybe done is to add another class that inherits and extends the class that you are modifying. A user could, in this way, use one class or another depending on if the new behavior is wanted or not. By implementing a new class and not touching the previous one, I believe that the ABI compatibility would be kept.

[MCFurry]

That sounds like a neat solution indeed. If someone can advice whether this could indeed keep ABI compatibility I'll look into it!

[rokusottervanger]

That sounds like a neat solution indeed. If someone can advice whether this could indeed keep ABI compatibility I'll look into it!

I have time for this now, but I need confirmation that this direction will indeed lead to an acceptable PR.