Robotiq grippers on UR e-series: Tool communication issues

[felixvd]

Summary

To use a Robotiq gripper with the tool_communication interface on our UR, I have tried using both the official Robotiq package and pymodbus 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

• ROS Driver version: master
• Affected Robot Software Version(s): 5.7
• Affected Robot Hardware Version(s): e-series?
• Robot Serial Number: x
• UR+ product(s) installed: x
• URCaps Software version(s): 1.0.2/1.0.0 (rs-485)

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 returns inactive) 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):

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 <module>
    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 88, in getStatus
    response = self.client.read_holding_registers(0x07D0, numRegs, unit=0x0009)
  File "/usr/lib/python2.7/dist-packages/pymodbus/client/common.py", line 109, in read_holding_registers
    return self.execute(request)
  File "/usr/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 85, in execute
    return self.transaction.execute(request)
  File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 130, in execute
    result = self._recv(expected_response_length or 1024)
  File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 163, in _recv
    result = self.client._recv(expected_response_length or 1024)
  File "/usr/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 401, in _recv
    result = self.socket.read(size)
  File "/usr/local/lib/python2.7/dist-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

or

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 <module>
    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'

or

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 <module>
    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)
  File "/usr/lib/python2.7/dist-packages/pymodbus/register_read_message.py", line 98, in getRegister
    return self.registers[index]
IndexError: list index out of range

When running the node, part of the UR driver fails like this:

process[b_bot/ur_tool_communication_bridge-10]: started with pid [460109]
[INFO] [1596678277.235497]: Remote device is available at '/tmp/ttyUR_b'
[INFO] [1596678277.236016]: Starting socat with following command:
socat pty,link=/tmp/ttyUR_b,raw,ignoreeof,waitslave tcp:192.168.1.42:54322
[...]
2020/08/06 01:45:18 socat[460126] E connect(10, AF=2 192.168.1.42:54322, 16): Connection refused
[b_bot/ur_tool_communication_bridge-10] process has finished cleanly
log file: /root/.ros/log/30134730-d786-11ea-b68b-c8d3ff4172f5/b_bot-ur_tool_communication_bridge-10*.log

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

-

[fmauch]

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.

[gavanderhoorn]

From the tracebacks shown I believe @felixvd is running this in Docker containers. Can you confirm @felixvd?

[gavanderhoorn]

Possibly related: #108. no, it isn't.

[gavanderhoorn]

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.

[felixvd]

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 run socat on your ROS PC (ie: the client side). The command is printed as an INFO 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.

[gavanderhoorn]

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.

[felixvd]

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.

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 an socat 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

[gavanderhoorn]

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.

[fmauch]

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.

[gavanderhoorn]

@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

[felixvd]

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.

[fmauch]

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.

[felixvd]

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.

[felixvd]

Post on the Robotiq DoF forum.

[fmauch]

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.

[felixvd]

Thanks. Which part of the ROS-PC-side code is that urscript talking to? I didn't manage to find it yet.

[fmauch]

Motion commands are sent here and keepalive signals are read here but as mentioned earlier, this is simply socket communication. For something simple as commanding individual gripper commands, a quick python implementation might be more suitable.

[MatMcT]

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?

[DavidYaonanZhu]

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?

[DavidYaonanZhu]

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:

1. Update Pyseria to version 3.4
2. Implement try/except suggested by ToDo of @felixvd and source file of robotiq driver catkin_ws/src/robotiq/robotiq_modbus_rtu/src/robotiq_modbus_rtu/comModbusRtu.py updated file here

I have not tried with Robotiq URCap installed in TP. I will report if any progress.

[mqt0029]

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.

[rrapi]

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!

[mqt0029]

@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.

[rrapi]

@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??

[mqt0029]

@rrapi The wrapper has a detailed documentation in both HTML and PDF format, just clone the repository and follow the instructions provided.

[matthias-mayr]

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:

1. The gripper dies as soon as External Control starts running
   • Current drawn by the gripper drops from ~50 mA to ~20 mA as soon as that happens
2. rs_485 version: 1.0.0, External Control version: 1.0.5
3. The log on the Teaching Pendant does not contain anything regarding the tool
4. I made a program that would wait for 10s and then start External Control:
   • the gripper dies only when it reaches External Control and not while waiting
5. I can only recover by a) restarting the whole robot or b) loading a program from a different installation
   • It is not sufficient to turn the robot off and on within the same installation or load another program within the same installation
6. The robotiq URCap is not installed, following the instructions above
7. In Installation -> URCaps -> RS485 it reports that the daemon is running the whole time

How 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?

[matthias-mayr]

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

[Yeesha-R]

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 mainLoop(sys.argv[1]) File "/home/ubuntu/catkin_ws/src/robotiq/robotiq_2f_gripper_control/nodes/Robotiq2FGripperRtuNode.py", line 75, in mainLoop status = gripper.getStatus() File "/home/ubuntu/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 "/home/ubuntu/catkin_ws/src/robotiq/robotiq_modbus_rtu/src/robotiq_modbus_rtu/comModbusRtu.py", line 94, in getStatus response = self.client.read_holding_registers(0x07D0, numRegs, unit=0x0009) File "/home/ubuntu/.local/lib/python3.8/site-packages/pymodbus/client/mixin.py", line 107, in read_holding_registers return self.execute( File "/home/ubuntu/.local/lib/python3.8/site-packages/pymodbus/client/base.py", line 391, in execute raise ConnectionException(f"Failed to connect[{self!s}]") pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] Failed to connect[ModbusSerialClient /tmp/ttyUR:0]