Revision history [back]

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 point for the ROS-Industrial mailing list.

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 point topic for the ROS-Industrial mailing list.