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

[LucidOne]

Is this planned to be a direct port or is there a design document for review somewhere?

We had some issues with `FrequencyStatus` diagnostics not matching `rostopic hz`, but much of that seemed intrinsic to ROS1. The [ window_size_](http://docs.ros.org/melodic/api/diagnostic_updater/html/structdiagnostic__updater_1_1FrequencyStatusParam.html#a30fb0c936798afb6f3b2bad118052182) being measured in units of `diagnostic_period` events instead of time was somewhat disintuitive. At one point we had a [similar issue](https://github.com/ros/diagnostics/issues/45) with topics that update at less than 1Hz. 

While ROS2 could still expose more [metrics](https://community.rti.com/static/documentation/connext-dds/5.3.1/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/index.htm#UsersManual/Statuses_for_DataWriters.htm?Highlight=metrics), `ros2 topic hz` was just [implemented](https://github.com/ros2/ros2cli/issues/132), so that should provide a starting point for `FrequencyStatus` diagnostics. However, I'm personally in favor of integrating metrics into the [Publisher](https://github.com/ros2/ros2cli/issues/132#issuecomment-432520837).

On a previous project, we could have used better status filtering for some devices. In particular we had a FLIR camera that would do it's own self-test / running recalibration if, for example, the ambient temperature changed by 0.1C it would drop 1-3 frames while closing a shutter to recalibrate. Ideally we would have a way to escalate the status level when the topic frequency drops below `min_freq` over a given period of time. Sonar sensors may be a similar aperiodic use case.

It was never clear to me if `hardware_id` should be a UUID, serial number, VID/PID, mac address, etc.
Does information such as the vendor, model number, hardware/firmware version and/or ip address belong in diagnostics if it does not produce a status level change? I'm not sure it was the right choice but we ended up making separate topics to log introspected information to rosbags to track hardware changes. Much of the data really just needed to be stored once per bag file but the lack of metadata in ROS1 bag files prevented this from being a viable option given development resource constraints.

Does it make sense to implement a `metadata`/`hardware_introspection`/`diagnostic` group in the parameter server and have rosbag2 write everything from that parameter group into a chunk at the beginning of each bag? or a `/metadata` service that rosbag calls on a logged topic when the log rotates?

Our team also had questions about handling self_test when some of the tests should only be run when the system is not moving. Perhaps, [diagnostic_msgs](http://docs.ros.org/api/diagnostic_msgs/html/index-msg.html)/DiagnosticStatus could use a SKIP status level.

Some of the tests we wanted to perform required external interaction / feedback but [self_test_.checkTest()](https://github.com/ros/diagnostics/blob/indigo-devel/self_test/src/selftest_example.cpp#L178) appears to block `spin()`. One way of looking at the problem is that much of what is needed for interactive testing is similar to a generic sensor calibration manager interface. Use cases include controlling rotating platform for IMU testing, dynamometer feedback, external pose estimation, calibration maneuvers (driving in circles, moving objects), etc.





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