Open felixvd opened 4 years ago
root@ur:~/catkin_ws# rosrun robotiq_2f_gripper_control Robotiq2FGripperRtuNode.py /tmp/ttyUR_b /root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py:65: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information. pub = rospy.Publisher('Robotiq2FGripperRobotInput', inputMsg.Robotiq2FGripper_robot_input) Traceback (most recent call last): File "/root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 89, in
mainLoop(sys.argv[1]) File "/root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 75, in mainLoop status = gripper.getStatus() File "/root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/src/robotiq_2f_gripper_control/baseRobotiq2FGripper.py", line 107, in getStatus status = self.client.getStatus(6); File "/root/catkin_ws/src/robotiq/robotiq_modbus_rtu/src/robotiq_modbus_rtu/comModbusRtu.py", line 95, in getStatus output.append((response.getRegister(i) & 0xFF00) >> 8) AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
I've seen that one with our 3 finger gripper, as well. Restarting the Rtu node always helped there. So far I had been blaming a non-robust implementation of the robotiq driver as I think, I've also seen that when connecting the gripper to a RS485 converter on the ROS pc directly. However, I am not sure about this and we currently have a setup where it is directly connected and is working reliably, so I might be wrong there.
I mean, looking at the error, it seems that the (robotiq) driver itself is faulty, as it tries to access the ModbusIOException
wrong. However, the source of the problem probably lies in the tool_communication. Especially the other two failures you posted indicate that there is data missing.
To further debug this, I think it would be required to know the expected communication and then use a tool like wireshark to see the actual data being transferred.
From the tracebacks shown I believe @felixvd is running this in Docker containers. Can you confirm @felixvd?
Possibly related: #108. no, it isn't.
And I would suggest to run just ur_tool_communication
to test this part of the driver and/or manually run socat
on your ROS PC (ie: the client side). The command is printed as an INFO
line as you can see.
re: modbus: you should really treat the forwarded RS-485 port as a local one (local to the ROS PC, that is). The UR controller cannot also use the RS-485 in the flange, nor can any URCaps. It's as-if you'd have an external cable running along the robot and connects your ROS PC directly to your gripper -- it's just there is no cable, and we're using socat
to run a serial-port-over-TCP/IP.
I would also not expect anything to show up in the modbus tab of the UR controller, as it should be completely out-of-the-loop. ur_tool_communication
is not using modbus at all.
From the tracebacks shown I believe @felixvd is running this in Docker containers. Can you confirm @felixvd?
Yes. But the network is bridged and it does not seem to work from the host PC either.
I've seen that one with our 3 finger gripper, as well. Restarting the Rtu node always helped there. So far I had been blaming a non-robust implementation of the robotiq driver as I think, I've also seen that when connecting the gripper to a RS485 converter on the ROS pc directly. However, I am not sure about this and we currently have a setup where it is directly connected and is working reliably, so I might be wrong there.
I mean, looking at the error, it seems that the (robotiq) driver itself is faulty, as it tries to access the
ModbusIOException
wrong. However, the source of the problem probably lies in the tool_communication. Especially the other two failures you posted indicate that there is data missing.
Yes, there's a TODO about adding a try/except block in that part of the code, but if you print that ModbusIOException
, it reads Modbus Error: [Input/Output] No Response received from the remote unit
or Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received)
for me, so it seems to be a connection issue.
The robotiq driver uses pymodbus for both the TCP and RTU versions of its controller. I made a little script to test with outside of ROS (and my container) here.
Do you mean your 3-finger gripper is directly connected via USB and not through the UR tool communication?
To further debug this, I think it would be required to know the expected communication and then use a tool like wireshark to see the actual data being transferred.
If you have instructions I am happy to execute them :)
And I would suggest to run just
ur_tool_communication
to test this part of the driver and/or manually runsocat
on your ROS PC (ie: the client side). The command is printed as anINFO
line as you can see.
I saw the socat
command, but I figured that connecting directly to the TCP address and port would remove a link that can fail.
The UR controller cannot also use the RS-485 in the flange, nor can any URCaps.
I tried uninstalling the URCap completely, and right now it seems like the Robotiq RTU node is working, but not the TCP node. Not having the URCap would be a major pain, so I'll see if there's a way to disable it instead of reinstalling every time.
I saw the
socat
command, but I figured that connecting directly to the TCP address and port would remove a link that can fail.
There still seems to be some misunderstanding I believe: ur_tool_communication
essentially relays the RS-485 port from the controller to your ROS PC using socat
.
You cannot connect a modbus client "directly" to the socat
server. That won't work.
The UR controller cannot also use the RS-485 in the flange, nor can any URCaps.
I tried uninstalling the URCap completely, and right now it seems like the Robotiq RTU node is working, but not the TCP node.
As I wrote earlier: you cannot connect with anything that expects a regular modbus server to the socat
server on the UR controller.
Only an socat
client (or a program which knows how to pretend to be such a client) can connect to it.
At that point, the RS-485 port on the flange cannot be used by anything running on the controller any more. Only the virtual serial port on the ROS PC can be used, and only as a serial port.
Not having the URCap would be a major pain, so I'll see if there's a way to disable it instead of reinstalling every time.
Either the controller itself (or a URCap running on it) can use the RS-485 port or the socat
server.
While inconvenient, this seems straightforward to me: if this was a serial port directly attached to your ROS PC, you would not expect to be able to use different programs with the same port at the same time either, correct?
Edit: I'm not suggesting you need to uninstall the URCap btw. I don't know how it works, perhaps it's not needed to completely remove it.
But I do believe you need to make sure there is only a single process opening the RS-485 port on the controller, otherwise you can run into issues like you've reported.
There still seems to be some misunderstanding I believe:
ur_tool_communication
essentially relays the RS-485 port from the controller to your ROS PC usingsocat
. You cannot connect a modbus client "directly" to thesocat
server. That won't work.
I understand that socat
connects two ports (through magic). I admit that I'm not familiar with any of the protocols - I just saw that there is a Modbus TCP interface that pymodbus (and the robotiq driver) offer, so I figured that they would be able to talk through it directly.
As I wrote earlier: you cannot connect with anything that expects a regular modbus server to the
socat
server on the UR controller. Only ansocat
client (or a program which knows how to pretend to be such a client) can connect to it.
Yes. I assumed that those modules expect a Modbus server to sit behind the TCP address and port.
At that point, the RS-485 port on the flange cannot be used by anything running on the controller any more. Only the virtual serial port on the ROS PC can be used, and only as a serial port.
Either the controller itself (or a URCap running on it) can use the RS-485 port or the
socat
server.While inconvenient, this seems straightforward to me: if this was a serial port directly attached to your ROS PC, you would not expect to be able to use different programs with the same port at the same time either, correct?
No, but I would expect to be able to keep the program installed on my computer and start it up when I need it :)
I will update if I find out more about disabling the URCap. Thanks for the help and explanations <3
No, but I would expect to be able to keep the program installed on my computer and start it up when I need it
Sure, but something to keep in mind: the Robotiq URCap developers probably did not take into account the sort of setup you now have.
There's a possibility the URCap always tries to open the RS-485 port if it's active.
If you uninstall the URCap and things work, this points to a conflict between the Robotiq URCap and the one used for forwarding the RS-485 port with the driver in this repository.
Perhaps a post on the Robotiq forum would be an idea here.
It could be other URCaps which could also use the RS-485 port on the flange and the Robotiq URCap also conflict.
I got a bit lost her which URCap was uninstalled where... Do you have the robotiq-URCap installed (It was not noted in the OP)? As far as I remember, that tries to connect to an attached device through the URCap's installation contribution, meaning that it will be added to the preamble of every program being created on the TP. If this is the case, this could indeed lead to conflicts of the output device.
URCaps aren't just programs that you install and then run if you need them. There may be parts that get injected into each program. Therefore you can disable the RS485 daemon in the installation settings of the rs485-URCap.
@fmauch wrote:
Do you have the robotiq-URCap installed (It was not noted in the OP)?
It sort-of was:
@felixvd wrote:
they also match what the Robotiq Gripper URCap sets for the interface on the pendant
And I guess in
In the Tool I/O menu, I tried changing the URCap to "User" instead of "Robotiq Grippers"
but it's true that I didn't think to mention it explicitly, since I had it in my mind as "something you need to install to make the grippers work". I also expected them to be integrated well enough not to make tool communication impossible.
Anyway, it seems very likely that the URCap does hog the RS-485 port and there's no way around uninstalling it if you want to use the tool communication at the moment. I will mention it on the forum or to support.
In the meantime, if you have a good idea for a dead simple option to make a GUI with Open/Close buttons to replace the URCap interface, I am all ears. Thanks again :)
PS, while I have your attention: How hard would it be to add a socket to receive gripper commands to the ROS_external_control
script? That was the other alternative I have been thinking about.
In the meantime, if you have a good idea for a dead simple option to make a GUI with Open/Close buttons to replace the URCap interface, I am all ears. Thanks again :)
In one of our applications we use an RQT gui where two buttons are mapped to send specific commands the the gripper node. It's a bit hacky, but it does the job if you just want to open and close. In fact, we have a second wrapper node that wraps the gripper into a control_msgs/GripperCommand.action as an abstraction.
PS, while I have your attention: How hard would it be to add a socket to receive gripper commands to the
ROS_external_control
script? That was the other alternative I have been thinking about.
That shouldn't be too hard. You can open a socket in URScript, create a thread that reads from that socket and execute according script code (I think, the Robotiq URCap provides a couple of functions). On the ROS side you would need something to write to that sockets, which should also be quite simple using sockets. However, I think that this isn't the optimal solution as you would have to take care about sending success status messages through the socket manually, as well to make it a usable interface.
Very nice. Would love to copy it if it's open somewhere :)
That shouldn't be too hard. You can open a socket in URScript, create a thread that reads from that socket and execute according script code (I think, the Robotiq URCap provides a couple of functions). On the ROS side you would need something to write to that sockets, which should also be quite simple using sockets. However, I think that this isn't the optimal solution as you would have to take care about sending success status messages through the socket manually, as well to make it a usable interface.
I'm familiar with the URScript functions and have adapted the Robotiq driver to work through URScripts before, so the interface would be alright. I'm not very familiar with socket communication, but maybe you could point out where it is happening in the UR driver, so I can study it. I found this on the URScript side, but this RTDE stuff is different I believe?
Also this seems to be getting off-topic, so I renamed the issue to be relevant for people trying to use Robotiq grippers on URs in ROS. It seems like there's no ideal solution yet.
I'm not very familiar with socket communication, but maybe you could point out where it is happening in the UR driver, so I can study it. I found this on the URScript side, but this RTDE stuff is different I believe?
It doesn't have to go through the driver, as socket connections can be used independently.
In the script code you have to connect to a socket like here and then you can send data to that socket like here read data from the socket like here
It should also be possible to open the socket on the robot controller instead of connecting to a remote socket. Then, you can write any node on ROS side that communicates with that socket. See the URScript manual for more details on socket communication. It's actually quite straight forward.
Thanks. Which part of the ROS-PC-side code is that urscript talking to? I didn't manage to find it yet.
root@ur:~/catkin_ws# rosrun robotiq_2f_gripper_control Robotiq2FGripperRtuNode.py /tmp/ttyUR_b /root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py:65: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information. pub = rospy.Publisher('Robotiq2FGripperRobotInput', inputMsg.Robotiq2FGripper_robot_input) Traceback (most recent call last): File "/root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 89, in
mainLoop(sys.argv[1]) File "/root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 75, in mainLoop status = gripper.getStatus() File "/root/catkin_ws/src/robotiq/robotiq_2f_gripper_control/src/robotiq_2f_gripper_control/baseRobotiq2FGripper.py", line 107, in getStatus status = self.client.getStatus(6); File "/root/catkin_ws/src/robotiq/robotiq_modbus_rtu/src/robotiq_modbus_rtu/comModbusRtu.py", line 95, in getStatus output.append((response.getRegister(i) & 0xFF00) >> 8) AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
Not sure if this will be helpful but I've had similar issues with Robotiq grippers in the past. Our set up was using the gripper plugged directly into the PC and not the UR. I've found that the issue was that sometimes the returned value from a specific line wasn't what was expected. However, simply wrapping a try/except fixed the issue for us. For us, this issue was specifically in robotiq_2f_gripper_rtu.py
This was our fix: ` try:
rr = self.client.read_holding_registers(INPUT_REG, 3, unit=self.id,timeout=2)
retries = 50
# To get around spuratic - object has no attribute 'registers'
while not isinstance(rr, ReadHoldingRegistersResponse):
rr = self.client.read_holding_registers(INPUT_REG, 3, unit=self.id)
retries -= 1
time.sleep(0.01)
if retries <= 0: raise TypeError("Failed to get status after 50 tries")
except TypeError as e:
print(e)
return None`
perhaps the URCaps version is facing similar issues?
I uninstalled robotiq urcap, and followed instructions to setup tool communication. I have running into the following error,
rosrun robotiq_2f_gripper_control Robotiq2FGripperRtuNode.py /tmp/ttyUR
Traceback (most recent call last):
File "/home/ur/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 89, in <module>
mainLoop(sys.argv[1])
File "/home/ur/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 60, in mainLoop
gripper.client.connectToDevice(device)
File "/home/ur/catkin_ws/src/robotiq/robotiq_modbus_rtu/src/robotiq_modbus_rtu/comModbusRtu.py", line 57, in connectToDevice
if not self.client.connect():
File "/usr/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 330, in connect
baudrate=self.baudrate, parity=self.parity)
File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 180, in __init__
self.open()
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 311, in open
self._update_dtr_state()
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 605, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
IOError: [Errno 22] Invalid argument
It seems like not the modbus communication issue,,, Any solutions? I fixed this problem by updating pyseria to vresion 3.4 https://github.com/pyserial/pyserial/issues/59
But, now the same erros with @felixvd
AttributeError: 'ModbusIOException' object has no attribute 'getRegister'
I deleted robotiq urcap, my TP only contains rs485 urcap and external_control urcap
Following the comments by @felixvd :
I tried uninstalling the URCap completely, and right now it seems like the Robotiq RTU node is working, but not the TCP node. Not having the URCap would be a major pain, so I'll see if there's a way to disable it instead of reinstalling every time.
My current configuration should work?
A quick report about the fix:
I can now control the gripper by installing rs485 and external_control URCaps, and using tool_communication of the driver. The gripper is directly connected to the UR.
My fix is:
I have not tried with Robotiq URCap installed in TP. I will report if any progress.
I am uncertain how relevant my use case is, or what I am suggesting is in anyway related, since I am running Docker container assuming host network for communication (aka docker run [...] --network=host [...] some_image some_command
). But, I find that running
sudo usermod -a -G dialout $USER
on the host machine fixes the issue for my case. The gripper is attached to arm. I also have a daemon to start socat
on the control box as well, just to ensure everything is running as intended.
Hi everyone!!
I have the same problem and cannot connect and control the gripper even connceted directly to PC and even connected directly to the UR5e robot controller.
Could you help me please?
@DavidYaonanZhu Did your solution worked?
Thank you in advance!
@rrapi Have a look at RVL Robotiq Integrated Driver. It is a wrapper for controlling Robotiq gripper with MoveIt! collision planning that I wrote for this purpose.
@mqt0029 thank you very much for your answer!! I took a look to it but did not understand very well how it works and how I can use it. Can you explain it to me please??
@rrapi The wrapper has a detailed documentation in both HTML and PDF format, just clone the repository and follow the instructions provided.
I followed rrapi
's steps to get my robotiq 2f gripper working and after fixing some of the common python3 issues in the robotiq ROS code, it works quite well and I can control the gripper from ROS.
However this is when the arm is running and the External Control
URCap is not yet started. As soon as I start the robot program, the gripper light turns off and of course also the communication breaks.
Some info and observations:
External Control
starts running
rs_485
version: 1.0.0, External Control
version: 1.0.5External Control
:
External Control
and not while waitingInstallation -> URCaps -> RS485
it reports that the daemon is running the whole timeHow would the next debugging steps look like? How could the gripper's power being switched off (?) be related to the start of the External Control
URCap?
That was a quick one: The parameter tool_voltage
defaults to 0
, but for the robotiq 2f gripper should be 24
. To complement rrapi
's instructions linked above, it should be this then:
roslaunch ur_robot_driver ur5e_bringup.launch robot_ip:=<ROBOT_IP> kinematics_config:=${HOME}/path_to/ur5e_calibration.yaml use_tool_communication:=true tool_device_name:=/tmp/ttyUR tool_voltage:=24
Hi there,
I have a setup in which the 2f-85 gripper is directly attached to my UR5e robot arm. To start the robotic arm, I run
roslaunch ur_robot_driver ur5e_bringup.launch robot_ip:=192.168.1.2 kinematics_config:=$(rospack find ur_calibration)/my_robot_calibration.yaml use_tool_communication:=true tool_device_name:=/tmp/ttyUR tool_voltage:=24
This creates a file named 'ttyUR' in my tmp folder.
However, I encounter the following error and notice that the ttyUR file created in my tmp folder gets deleted anytime I run
rosrun robotiq_2f_gripper_control Robotiq2FGripperRtuNode.py /tmp/ttyUR
Traceback (most recent call last):
File "/home/ubuntu/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 89, in
Summary
To use a Robotiq gripper with the
tool_communication
interface on our UR, I have tried using both the official Robotiq package andpymodbus
directly and failed with both. It looks like this is a connection or robot setup issue, and our drivers have worked with Robotiq control boxes before, so I am posting it here rather than on the Robotiq repo.Related to #168.
Versions
Impact
The tool interface does not work.
Issue details
I followed the tutorial to set up the tool communication interface, installed the rs-485 URCap, checked in the Installation tab that the daemon runs, checked that the voltage, baudrate, stop_bits and parity seem correct (they also match what the Robotiq Gripper URCap sets for the interface on the pendant). There seems to be no firewall on the PC (
sudo ufw status
returnsinactive
) and the robot controller works fine otherwise.I get a range of error messages when running
rosrun robotiq_2f_gripper_control nodes/Robotiq2FGripperRtuNode.py /tmp/ttyUR_b
(I agree that this command should be correct):or
or
When running the node, part of the UR driver fails like this:
Running
pymodbus
directly to connect to the IP address and port does not succeed either, but the bridge node does not die (since the device is not used).On the pendant, going into Log/External/MODBUS displays no activity (I assume there should be something). In the Tool I/O menu, I tried changing the URCap to "User" instead of "Robotiq Grippers", and I kept the robot in Remote Control mode. The port in both the launch file and URCap internal file is 54321.
What else could be the problem? Are there any other required settings? I am out of ideas.
Use Case and Setup
Project status at point of discovered
When I tried to switch over from using URScripts to control the gripper.
Steps to Reproduce
-
Expected Behavior
-
Actual Behavior
-
Workaround Suggestion
-