Feature request : ROS diagnostics

[haudren]

Summary

In general, hardware devices publish their status using the diagnostics system. At the moment, it seems that the ROS driver does not publish any of that information, and it makes it hard to diagnose issues from a centralized diagnostic aggregator.

Versions

• ROS Driver version: bf26ea5eca4f6c586da029abc91774481c470d28

Impact

This has no impact on the robot behavior, but impairs usability from within the ROS ecosystem.

Issue details

Use Case and Setup

• Have a fairly complex application, comprising of one or more UR robots, cameras, ...
• Bring up application
• Observe strange behavior
• Try to find the root cause from the diagnostics: nothing shows up for the robots

Project status at point of discovered

While trying to use the UR in a complex application and reproducing functionality present in Kawasaki Robots and PR2

Steps to Reproduce

• Launch the driver (simply listening to joint angles from RTDE)
• rostopic echo /diagnostics

Expected Behavior

Multiple messages about robot connection status and loop status

Actual Behavior

No messages published

Workaround Suggestion

It seems that replacing the commented-out lines here: https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/blob/4fae7361f26de3f0fb205ca295bb8d0a9c75ea36/ur_robot_driver/src/ros/hardware_interface_node.cpp#L151 With some diagnostics publishing would be enough to achieve the goal

[gavanderhoorn]

While trying to use the UR in a complex application and reproducing functionality present in Kawasaki Robots

Just an observation: I doubt the code linked to is real-time safe.

A RealtimePublisher is used, but the diagnostic_mgs are created in the loop instead of having been instantiated and initialised in the initialisation phase of the driver. In addition, regular vectors are used which is not a good idea.

I know ur_robot_driver does not make any determinism guarantees, but care should be taken to not take the hardware_interface further away from it.

[haudren]

Agreed, this is why I would like some feedback from the maintainers of this repo on where this should be added and how. I can then try to implement it myself.

[fmauch]

Do I understand correctly, that your diagnostics concerns are only regarding the control loop timings? This could be added at the top-level node but I share the concerns @gavanderhoorn raised, so we would have to take care about this a bit further.

It would be probably best to wrap this inside an own class, keep an instance of this in the main node and call an update function from the control loop.

[haudren]

Yes, I think that most of the issues I am looking at can be traced back to the control loop timings, as the hardware "problems" we seem to be having revolve around connectivity (which would show up as missed diagnostics messages) and insufficient resources (control loop misses updates). Note that this should work both when only reading the joint angles and when having remote control of the robot.

Your design seems good to me, keeping a single instance and reusing it should work fine for realtime purposes.

[fmessmer]

similar intention as #170

[fmauch]

That's why I was asking initially about the timings, as I was about to mark this a duplicate. As far as I understood, #170 has a couple of different aspects in mind, though.

[haudren]

So I think that what's in #170 is good but:

• industrial_robot_status_controller cannot be integrated the diagnostics system without implementing some custom logic to republish status messages as diagnostics (correct me if I'm wrong)
• No timing information

However, it might cover the connection errors.