UniversalRobots / Universal_Robots_ROS_Driver

Universal Robots ROS driver supporting CB3 and e-Series
Apache License 2.0
767 stars 405 forks source link

Ability to detect program pause on teach pendant via ROS topics #478

Open mzucker opened 3 years ago

mzucker commented 3 years ago

Summary

When the program on the teach pendant is running but paused, there seems to be no indication that robot motion is not possible via the /ur_hardware_interface/robot_program_running topic or the /robot_status topic.

Versions

Impact

Sending position setpoints to the robot controller while the program is paused may lead to sudden jerks when it is unpaused. However, other ROS nodes have no way of knowing that the robot will be unresponsive while paused, so they may continue to send them.

Issue details

It is possible to detect normal running of the external control program by subscribing to the /ur_hardware_interface/robot_program_running topic. So for example if the program is stopped, ROS clients can avoid sending trajectories to the robot.

It is also possible to see if the robot is e-stopped via the /robot_status topic, which clients can also subscribe to.

However, I can't find a way to see if the robot program is running but paused. This is unfortunate because re-starting the robot after an e-stop leaves the program in a paused state. So there is a period when it looks like the robot is ready to go but the program still needs to be restarted.

Steps to Reproduce

Power up the robot. Launch the robot driver and monitor the /ur_hardware_interface/robot_program_running and /robot_status topics.

Press play on the teach pendant. Nothing significant changes in the /robot_status topic; the robot_program_running topic toggles from False to True.

Pause the teach pendant. Nothing significant changes in either topic.

Expected Behavior

Some indication that the robot is not ready to move/receive position commands.

Actual Behavior

No indication that the robot is not ready to move.

Workaround Suggestion

It might be possible to poll the /ur_hardware_interface/dashboard/program_state service to get the current program state, but that is inefficient compared to topic subscription.

Could the driver be modified so that /ur_hardware_interface/robot_program_running is only True if the program is running AND unpaused?

Also could the robot status reporter be modified so that the /robot_status topic does not have mode=AUTO and motion_possible=TRUE unless the program is running and unpaused? From the perspective of a ROS client sending position commands, motion_possible is totally dependent on the program state.

fmauch commented 3 years ago

I can follow your argumentation and the relevant information is probably available in the used interfaces. I'll mark this as "enhancement", so I see that as a feature request. I cannot promise that I find any time working on that soon, though.

mzucker commented 3 years ago

Makes sense, and there are workarounds. Thanks.

gavanderhoorn commented 3 years ago

Just for context, the PR which ported robot_status publishing (or really: extended the hw iface) from ur_modern_driver: https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/141.

Note the discussion around mode and motion_possible.


Edit: and the obligatory "we can add program status later": https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/141#pullrequestreview-396408856.