Universal_Robots_ROS_Driver
Universal_Robots_ROS_Driver copied to clipboard
UniversalRobots
RTDE initialization error when EtherNet/IP is enabled
Problem
Following up on #191 and #195 there seems to exist a conflict between using this driver and having an EtherNet/IP fieldbus enabled.
In the driver's output this will like like this:
[ INFO] [1592729101.758609279]: Negotiated RTDE protocol version to 2.
[ INFO] [1592729101.758972147]: Setting up RTDE communication with frequency 500.000000
[FATAL] [1592729102.784572693]: Variable 'speed_slider_mask' is currently controlled by another RTDE client. The input recipe can't be used as configured
[ERROR] [1592729102.784635271]: Could not correctly initialize robot. Exiting
================================================================================REQUIRED process [ur_hardware_interface-2] has died!
process has died [pid 2239832, exit code 1, cmd /home/mauch/robot_folders/checkout/ur_rtde_driver/catkin_ws/devel/lib/ur_robot_driver/ur_robot_driver_node __name:=ur_hardware_interface __log:=/home/mauch/.ros/log/7c7af2d0-b39b-11ea-8175-54ee755e8d52/ur_hardware_interface-2.log].
log file: /home/mauch/.ros/log/7c7af2d0-b39b-11ea-8175-54ee755e8d52/ur_hardware_interface-2*.log
Initiating shutdown!
================================================================================
As enabling EtherNet/IP claims all input fields as listed in the RTDE Guide, the ROS driver cannot use any of those fields.
This driver is designed in a way, that controlling those input fields is mandatory, as certain driver functionalities are relying on these fields. As a consequence this driver cannot be used together with an enabled EtherNet/IP fieldbus.
Workaround
As a workaround you'll have to disable EtherNet/IP fieldbus on the robot. Depending on your robot version, this has to be done slightly different:
CB3 robots
Installation > EtherNet/IP > Disable
e-Series robots
Installation > Fieldbus > EtherNet/IP > Disable
Proper solution
Currently there don't exist any plans to change that. If you't like to change that, please let us know. Basically, you'd have to make setting up RTDE inputs in the RTDEClient optional (or at least allow an empty recipe. AFAIK the robot doesn't send a confirmation, then) and also change all ROS functionality relying on these recipe fields to check for those and react accordingly. This should currently be affecting setting the speed slider and setting IOs.
While for IOs we could fall back to sending URScript commands to the robot, setting the speed slider value would probably have to be disabled in that case.
We are experiencing the same issue but with a Profinet connection.
However, we were not able to reproduce it on ursim, yet. I am suggesting, that the issue only arises if a Profinet controller is actually connected.
Has anyone ran into this problem with (connected) Profinet?
Last time I looked at this, the EtherNet/IP daemon was essentially an RTDE client. It's possible the Profinet one uses the same approach.
That could be the case. As we've added this check only a while ago behavior might have been different in the past as in #56, but it actually fits the picture. Before adding this check we didn't notice that the RTDE connection was not established correctly. Therefore, it failed when expecting the actual data package as no successful data exchange was established.
Do you have an idea on how to work around this? We need the Profinet connection, but not all features of the ur_robot_driver.
How much effort is it to disable e.g. the slider info or the tool IOs in the RTDE recipe/driver?
Do you have an idea what else might pops up then?
Currently there don't exist any plans to change that. If you't like to change that, please let us know. Basically, you'd have to make setting up RTDE inputs in the RTDEClient optional (or at least allow an empty recipe. AFAIK the robot doesn't send a confirmation, then) and also change all ROS functionality relying on these recipe fields to check for those and react accordingly. This should currently be affecting setting the speed slider and setting IOs.
While for IOs we could fall back to sending URScript commands to the robot, setting the speed slider value would probably have to be disabled in that case.
Commenting out the getRTDEWriter(...) inside this code and setting res.success to true manually could be a proof of concept hack. Obviously, you would fool the user in that case when she/he tries to set the speed slider / set IOs. Then, deleting all lines in input_recipe.txt could work. I think, trying this out shouldn't be too much of a hazzle, then you would have a hacky workaround. However, as stated above, a proper solution that could be merged into master might take a bit more work. I hope, this helps to try things out, please let me know if you have any results from testing this @ipa-lth
I commented out the above parts of the c++ code and the recipe file.
Unfortunately, the problem stays.
The driver is not crashing but the ur control still does a protective Stop after starting the ur program (including the urcap) (The behaviour is idential to enabling EthernetIP/Profinet after having already launched the driver.)
Does the output_recipe.txt may also effect the ressource allocation? Is there any chance of resolving this (clean or hacky)?
Does the output_recipe.txt may also effect the ressource allocation? Is there any chance of resolving this (clean or hacky)?
I think not. From my understanding multiple clients can subscribe to the same data being sent via RTDE. Also, connection setup (including recipe verification) seems to succeed, which it wouldn't if there were resource conflicts (given that the fieldbus was activated when the driver is starting).
Edit: The popup states that fieldbus input has disconnected. As I am not really familiar with fieldbusses: Could it be necessary that this is an issue with the fieldbus itself? Does the setup work with a program NOT containing the "External Control" node (and NOT having the driver running)?
@ipa-lth
Edit: The popup states that fieldbus input has disconnected. As I am not really familiar with fieldbusses: Could it be necessary that this is an issue with the fieldbus itself? Does the setup work with a program NOT containing the "External Control" node (and NOT having the driver running)?
Any update on Felix assumptions?
Sending an empty input recipe doesn't work. We want to use the driver in an industrial setting where a plc is connected via Profinet. We don't need the full functionality of the driver. TF & script topic etc. is enough at the moment.
How could we achieve:
Basically, you'd have to make setting up RTDE inputs in the RTDEClient optional (or at least allow an empty recipe. AFAIK the robot doesn't send a confirmation, then)
Many thanks
That would require some major changes inside the code base. First of all, you would have to make sure that the RTDEClient would accept an empty recipe probably in this function.
Out of my head I would not be sure what would be happening then. I would expect things to crash at latest when you try to use one of the functionalities mentioned above.
@fmauch This might be something that we should discuss how to fix. It is also blocking the possibility to have multi ROS/External Control hosts contribution into the same robot program.
