[ros-users] [Discourse.ros.org] [Next Generation ROS] Diagnostic-aggregator and diagnostic-updater porting to ROS2

[Austin via Discourse.ros.org]

Sorry; I've been out of the loop here for a while (my discourse.ros.org subscription does not work very well).

The PR at https://github.com/ros/diagnostics/pull/94 seems like it has gotten out of hand; it's over  160 files changed and over 65k lines of diff, and the CI has been removed. It's unclear if it's an update of the existing code, or a complete rewrite at this point.

As has been my feedback since the first PR, more than anything else, I'd like to see CI set up for this project, so that we can have some confidence in what works, and what still needs work.

I've haven't seen any attempts to do that yet. I did some searching and found https://github.com/ros2/ci , https://ci.ros2.org/ and http://design.ros2.org/articles/changes.html . All of these mention CI, but none of them describe how to register the new ros2-devel branch with the ROS build farm or Travis.CI. I also found https://github.com/erlerobot/ros2_travis , but it seems very out of date and doesn't seem to support testing on Windows (Since Windows is a first-class citizen in ROS2, I'd like to have some CI run on it).

@dirk-thomas: can you provide any references or tutorials on how to set up CI for ROS2 packages?

@vaibhavbhadade thank you for all of your hard work on this so far. I think to move forward, we need to break the current PR down into smaller pieces that can be reviewed incrementally. The obvious way to do that is:
 * Renames and code changes in separate pull requests.
 * Separate pull requests for each package within the diagnostics repository.

If you have functional or structural changes that you're making, let's discuss those before we discuss the details of the code changes.

@LucidOne suggests a common system for reporting sensor information (serial number, part number, etc). I do not know much about ROS2, but if the logger supports capturing parameters like that, then that would be an excellent feature to add, and would probably be good for it to replace the old hardware_id .

If ROS2 has support for embedding a generic message within another message type, it would be worth looking into ways to use that to replace the existing KeyValue message type with more structured data (trying to extract data from the ROS1 diagnostic messages is very painful).





---
[Visit Topic](https://discourse.ros.org/t/diagnostic-aggregator-and-diagnostic-updater-porting-to-ros2/6382/11) or reply to this email to respond.