diagnostics concept

[fmessmer]

I can't find any code related to the ROS diagnostic concept
Is there any ongoing effort/plan to support this feature?

I'd like to - at least - track the operation status of the UR and the driver, like:

• robot operable/initialized
• safety stop active
• network connection status

Also, is there a systematic way to "recover" the driver from/after failure?
This recovery would also include resetting the controller in the controller_manager::ControllerManager::update
As we have seen super-fast movements of the UR after reconnecting the external control program after some connection drop. This seems like there are still "old" cmd values being commanded from the loaded controllers

[fmauch]

Since #141 we have an industrial_robot_status_controller included.

To recover after a failure I suggest using the set_mode action As described in the action the robot will continue moving. If you don't use a controller being aware of the robot not following the trajectory anymore (which is why we suggest using the scaled_trajectory_controller) this will lead to a fast motion. In that case the safe reset is to request a program stop (in the same action) as well. As stopping the program also stops running controllers it will be reset afterwards.

Note: The reason why this is implemented that way is because the robot is actually in a "paused" state, so resuming after an EM-Stop or protective stop can be done directly. I'm happy to put this out for discussion, though.

[fmauch]

Would the industrial_robot_status_controller together with the changes from #170 implement what you had in mind? Otherwise we might merge #170 and this together to create something that covers both issues.

[gavanderhoorn]

industrial_msgs/RobotStatus won't tell you what kind of stop is currently active though.

in_error will be TRUE whenever the robot is in an error mode and motion_possible will be FALSE, but as it's not an e-stop, the message does not have a way to encode what put it there (or at least: the error_code field is not set to anything right now).

error_code could be used for this, but I would only do it if UR has defined numerical errors for the various kinds of stops (I believe there are) and those are communicated to the driver via RTDE or the primary/secondary interface (with #171).