RTDE error when starting `ur_control.launch`

[JStech]

Summary

When launching ur_control.launch as shown here, the process dies with the error, "Variable 'speed_slider_mask' is currently controlled by another RTDE client. The input recipe can't be used as configured". Here's some more context:

process[ur_hardware_interface/ur_robot_state_helper-6]: started with pid [9761]
ros.ur_robot_driver: Initializing urdriver
ros.ur_robot_driver: Checking if calibration data matches connected robot.
ros.controller_stopper: Waiting for controller manager service to come up on /controller_manager/switch_controller
ros.ur_robot_driver: No realtime capabilities found. Consider using a realtime system for better performance
ros.roscpp: waitForService: Service [/controller_manager/switch_controller] has not been advertised, waiting...
rosout: Controller Spawner: Waiting for service controller_manager/load_controller
ros.ur_robot_driver: Calibration checked successfully.
rosout: Controller Spawner: Waiting for service controller_manager/load_controller
ros.ur_robot_driver: No realtime capabilities found. Consider using a realtime system for better performance
ros.ur_robot_driver: Negotiated RTDE protocol version to 2.
ros.ur_robot_driver: Setting up RTDE communication with frequency 125.000000
ros.ur_robot_driver: Variable 'speed_slider_mask' is currently controlled by another RTDE client. The input recipe can't be used as configured
ros.ur_robot_driver: Could not correctly initialize robot. Exiting
================================================================================REQUIRED process [ur_hardware_interface-2] has died!
process has died [pid 9746, exit code 1, cmd /home/john/ws_ur5/devel/lib/ur_robot_driver/ur_robot_driver_node __name:=ur_hardware_interface __log:=/home/john/.ros/log/c2838538-ae8e-11ea-a2b3-fcaa149a77cc/ur_hardware_interface-2.log].
log file: /home/john/.ros/log/c2838538-ae8e-11ea-a2b3-fcaa149a77cc/ur_hardware_interface-2*.log
Initiating shutdown!
================================================================================
[ur_hardware_interface/ur_robot_state_helper-6] killing on exit
[controller_stopper-5] killing on exit
[ros_control_stopped_spawner-4] killing on exit
[ros_control_controller_spawner-3] killing on exit
[ur_hardware_interface-2] killing on exit
rosout: Controller Spawner couldn't find the expected controller_manager ROS interface.
rosout: Controller Spawner couldn't find the expected controller_manager ROS interface.
[controller_stopper-5] escalating to SIGTERM
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Versions

• ROS Driver version: master on commit 8e2ee63
• Affected Robot Software Version(s): URSoftware 3.7.0.40195 (Aug 22 2018)
• Affected Robot Hardware Version(s): UR5--if there's a more specific version, I couldn't figure out where to find it
• Robot Serial Number: 2017356310
• UR+ product(s) installed: none, I think
• URCaps Software version(s): don't know--I'm using the External Control program

Impact

We're working around it by using an older driver

[fmauch]

This could be related / duplicate of #191. Is there any fieldbus enabled with the robot?

[JStech]

I don't know, but I can check next time I'm in the office. How can I tell?

[fmauch]

It is in the installation tab on the teach panel: https://github.com/UniversalRobots/Universal_Robots_ROS_Driver#when-starting-the-program-on-the-tp-i-get-a-c207a0-error

[jliukkonen]

Answering on behalf of @JStech since I'm looking at the settings right now.
The EtherNet/IP Adapter is in state "running" so it is enabled. Program action upon loss of EtherNet/IP Scanner connection: None.

[gavanderhoorn]

Try disabling it.

In other issues (such as #191) we've seen that user report things start working for them after they've disabled it.

That's not a solution, but part of diagnosing the cause.

[fmauch]

I got confirmed, that enabling EtherNet/IP reserves all RTDE inputs. This basically means that this driver cannot be used eith EtherNet/IP enabled in its current state.

To change that, we would have to make all features that use those optional which is currently out of scope for me.

[gavanderhoorn]

Does this deserve its own issue, so we can track and pin it?

I've just answered another question on ROS Answers about this. We can expect quite a few support requests about this.

[fmauch]

I think, we should add it to the troubleshooting section, the least.

Do you think, an issue specifically mentioning ... IN_USE in the title would improve searchability? In the end I would still close this, once we have it in the troubleshooting section.

[gavanderhoorn]

As it is a "shortcoming" of the current implementation, and not one that will be easily or quickly fixed, I would suggest to open the issue, describe the problem, include a verbatim copy-paste of the error message (for SEO) and then pin it.

Don't close it, as it hasn't been fixed.

Any new support requests related to this should then be redirected to that issue. And if SEO gets good enough, users should be able to find it.

Tbh I find this somewhat incredible. The use of RTDE was explicitly recommended (almost required) by the people contributing to the design.

we should add it to the troubleshooting section

of course.

[gavanderhoorn]

@fmauch: will you create the issue or would you want me to do it?

[fmauch]

I'll do it

[fmauch]

Closing this in favor of #204