0
$\begingroup$

Rosanswers logo

Hello, I want to know if there is a way to get the error in a common way for ros-industrial robots, independently of the robot I use.

My actual project may use different kind of robots that's why we decided to use ROS-I, to communicate by the same way.
The problems begin when I have to deal with errors.
Example: On the Universal-robot, the robot may stop because of the "protective lock", but on the Kuka they may be others.
I actually can get the protective error by subscribing on /rosout, and filter message by name and message (but as I filter by name "/ur_driver", it's not generic).

The second problem it implies is how to handles them ? For the UR "protective lock", the only solution I found was to send a socket command to it's dashboard interface, but again, it's not generic.

Did you know how can I handle all these kind of errors in a generic way ? Or is that unsupported by ROS-industrial interfaces and I have to deal with each type of error, for each robot we want to use ?


Originally posted by matEhickey on ROS Answers with karma: 15 on 2017-10-12

Post score: 0


Original comments

Comment by matEhickey on 2017-10-12:
Also, sort of same question for the robot state ? Any way to know if the robot we use in On/Off/Ready/ etc ?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Any way to know if the robot we use in On/Off/Ready/ etc

ROS-Industrial compliant drivers will publish the RobotStatus message that should reflect the status of the controller/robot. From the documentation:

The RobotStatus message contains low level status information that is specific to an industrial robot controller

Examples of fields in such messages: mode, e_stopped, motion_possible, drives_powered and in_error.

This only works with drivers that adhere to the ROS-Industrial Driver Specification. The drivers for the UR (both ur_driver and ur_modern_driver) nor the RSI component in kuka_experimental adhere to this, so they don't publish RobotStatus messages at this time.

That could be added. If you submit an enhancement request on the respective issue trackers it should receive attention.

The second problem it implies is how to handles them ?

The specification does currently not provide a standardised interface to error handling functionality provided by robot controllers. That can be considered an omission (and it is), although remote error software reset functions/methods are certainly not ubiquitous in industrial controllers, which makes adding something like that to the specification somewhat difficult. FAULT RESET IOs (or similar, controllable via a fieldbus) are probably more generically present.

This could be a good discussion topic for the ROS-Industrial mailing list.


Originally posted by gvdhoorn with karma: 86574 on 2017-10-12

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by matEhickey on 2017-10-12:
Thank you for that quick response, too bad for me that these driver don't adhere as the specifications, I'll have a lot more work to do so. Thank you again!

Comment by gvdhoorn on 2017-10-12:
No problem.

re: work: a nice way to approach this would be to extend those drivers such that they do publish RobotState messages. That means two relatively small extensions to the drivers, while you get to reuse your error handling and introspection code.

Comment by gvdhoorn on 2017-10-12:
And if you then submit PRs with those extensions to the repositories of the drivers, that would be +3 :)

Comment by matEhickey on 2017-10-12:
That what I was planning, hope I'll have time for all of this, I know well the UR, so it shouldn't be too long, but for the Kuka.. I'll give me a try :)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.