ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Diagnostic-aggregator and diagnostic-updater porting to ROS2

ros2

#1

As communicated with @Austin Hendrix, Brice Rebsamen, Our team at Persistent System is extending our help in porting diagnostic-aggregator and diagnostic-updater packages to ROS2. Please let us know if anyone has any concern or any important information that we will help us in this porting effort.


ROS 2 Collaboration Bulletin Board
ROS 2 Collaboration Bulletin Board
#2

Hi,

You can find a first port of the diagnostic-updater package for ROS2 Ardent here : https://github.com/bponsler/diagnostics/tree/ros2-devel.
I don’t know if it’s a full port of the diagnostic-updater or not though.
I did a minor update to make it compile for ROS2 Bouncy here : https://github.com/MarcTestier/diagnostics/tree/ros2-devel. Just had to change from c++11 to c++14.

Hope it can help you.


#3

@ MarcTestier, this is really helpful information and great pointer to start with. We also have additional communication with bponsler. We will check the state of the first port of diagnostic-updater and take necessary actions as required.


#4

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_ being measured in units of diagnostic_period events instead of time was somewhat disintuitive. At one point we had a similar issue with topics that update at less than 1Hz.

While ROS2 could still expose more metrics, ros2 topic hz was just implemented, so that should provide a starting point for FrequencyStatus diagnostics. However, I’m personally in favor of integrating metrics into the Publisher.

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/DiagnosticStatus could use a SKIP status level.

Some of the tests we wanted to perform required external interaction / feedback but self_test_.checkTest() 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.


#5

We have always used the diagnostics not only for monitoring hardware, but also software behavior.
You can monitor the tf topic frequency in the same way you monitor a camera topic.

In that sense hardware_id has been something inconvenient, I don’t know if it makes sense for ROS2 to rename it to something more generic.


#6

@dirk-thomas : we have created new ros2_devel branch and merged changes from bponsler:ros2-devel branch. Additionally we have updated code and port test cases as per ROS2 guidelines to support ROS2 Bouncy.
Now we want to share this development but there is no branch for ros2 development on https://github.com/ros/diagnostics , so please suggest how to move forward in this case .


#7

Create a ticket in the upstream repo asking for a `ros2 branch to be created so that you can create your PR against it.


#8

@dirk-thomas, Thanks for your feedback. @trainman419 had created a ros2-devel branch under ros/diagnostics to support ROS2. we have raised a PR request https://github.com/ros/diagnostics/pull/91 against it but CI build check has failed (as below) that seems some build env issue as it is triggering ros-indigo-catkin. We have tested it locally and build/test is successful in Bouncy. so please suggest in this case.

$ sudo apt-get install python-catkin-pkg python-rosdep ros-indigo-catkin
$ rosdep install --default-yes --from-paths ./ --ignore-src --rosdistro $CI_ROS_DISTRO

ERROR: the following packages/stacks could not have their rosdep keys resolved
to system dependencies:
diagnostic_updater: Cannot locate rosdep definition for [ament_cppcheck]

The command "rosdep install --default-yes --from-paths ./ --ignore-src --rosdistro $CI_ROS_DISTRO" failed and exited with 1 during

#9

The .travis.yml file on your branch still uses ROS 1 logic to try to build and test the code. You either need to update it to actually test ROS 2 or remote it for now.


#10

Hi dirk
thanks for your response and support .

@dirk-thomas @trainman419 Now we have successfully migrate diagnostic package to ros2 . we are looking forward for community response and suggestion for this package improvement.
pull request link is https://github.com/ros/diagnostics/pull/94