Open mzucker opened 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.
Makes sense, and there are workarounds. Thanks.
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.
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; therobot_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 havemode=AUTO
andmotion_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.