DoF - a Robotiq Community
Warning sign
The Dof Community was shut down in June 2023. This is a read-only archive.
If you have questions about Robotiq products please reach our support team.
Categories Discussions
Home > Programming > Programming options: UR16e + 2F-85
Rasp

Hi,

what is the best way to program the combination UR16e + 2F-85? I have successfully programmed the gripper from the teaching pendant with URCap nodes, however I want to explore python or c++ programming. I have also successfully programmed the arm via https://gitlab.com/sdurobotics/ur_rtde.

The questions I have are:
I have considered:
a) Uploading recipes directly following rtde-2.3.6's examples, and proper functions to the uploaded URScript (to mimic Robotiq's URScript), and use Python:
https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/real-time-data-exchange-rtde-guide-22229/
https://dof.robotiq.com/discussion/comment/3840 (the gripper script, similar to the one available in the teaching pendant)

b) Adding recipes to SDU's RTDE wrapper, and proper functions to the uploaded URScript (to mimic Robotiq's URScript), and use either C++ or Python:
https://gitlab.com/sdurobotics/ur_rtde
https://dof.robotiq.com/discussion/comment/3840 (the gripper script, similar to the one available in the teaching pendant)

c) Connecting directly to the gripper, and using URX to upload URScript commands directly to the gripper?? I am unsure whether this also requires uploading the URCaps script to the gripper, or whether by connecting directly instead of through the controller the URCaps' functions are available as commands:
https://github.com/SintefManufacturing/python-urx

d) Connecting directly via MODBUS RTU
https://dof.robotiq.com/discussion/1382/control-grippers-from-python-using-modbus-rtu
https://dof.robotiq.com/discussion/92/controlling-the-robotiq-2-finger-gripper-with-modbus-commands-in-python?_ga=2.17431289.1133307955.1542044765-1547192274.1535646624

e) This unclear method through rs485 (looks similar to MODBUS RTU as stated in option 'd'):
https://dof.robotiq.com/discussion/1926/python-module-for-control-robotiq-2f-85-from-external-ubuntu-pc

Am I missing something?

- - - -
To summarize the questions:

Q1) Why does digital output seem to have no effect on 2f-85, even though the teaching pendant / URcaps works?

Q2) What are the main differences between connecting directly to the gripper (via port 63352) vs connecting to the RTDE interface (via port 30004) and have the controller talk to the gripper?

Q3) I have listed several options, are there any pros/cons for either I should be aware of?

Thanks,
Sam.

bcastets

Q1) Why does digital output seem to have no effect on 2f-85, even though the teaching pendant / URcaps works?
> Digital output and gripper control is not related. The gripper is connected via USB. Digital output are not used by the 2F.

Q2) What are the main differences between connecting directly to the gripper (via port 63352) vs connecting to the RTDE interface (via port 30004) and have the controller talk to the gripper?

>The RTDE interface receive UR script. Then UR script is executed by the controller to perform an action. In case of the gripper, the controller will take the UR script and then convert this strict into Modbus RTU command with the support of gripper URCAP.
The direct connection to the gripper is more complex but more flexible. You can directly send modbus RTU command to the gripper. It is probably faster and you can communicate with your own why to the gripper.

Q3) I have listed several options, are there any pros/cons for either I should be aware of?

a) Easy but slow because you have to send a lot of code for a simple gripper action.
b) Not sure about the difference with a)
c) Don t know URX but I don t think it will help.
d) Easy and flexible but the gripper is not connected on the robot.
e) It looks like the best option. Gripper is connected on the robot and you are free to communicate in Modbus RTU. This solution is UR ROS package to emulate the gripper communication on the PC and control it in Modbus RTU. Did not had time to test it but it looks good.
Rasp

Thanks for the answer, Benoit.



With (a) and (b) my expectation is that once the URScript is uploded and running, only the command+recipe with the proper information (eg: set_gripper_pos(255)) will be needed, without having to send more information. In contrast, (c) URX seems to send an entire URScript for every command.
When you say that "a) Easy but slow because you have to send a lot of code for a simple gripper action.", what do you mean by "send a lot of code for a simple action"? What would be an example of a lot of code?


Oh, so the main difference between (d) and (e) is that (d) is with direct connection, while (e) uses the tool's TCP port. I see, thanks for that clarification.
prier

Hello Rasp

I am the author of ur_rtde. I have two suggestions for you. 

1) (The proper way) Option e)

Download the rs485-1.0.urcap from here, install it on the robot and remember to remove the Robotiq_Grippers UR cap as these two
cannot function together. You can then use the tool_communication script for making the robotiq serial port available on your desktop. (eg. /tmp/ttyUR). Finally use a modbus RTU based driver to communicate through the serial port. Alternatively you can avoid running the tool_communication script and just communicate directly to the socket at the port specified in the rs485 cap (default is 54321). 

2) (The not so proper way) Option b)

You can send the robotiq preamble script together with the function you want to run, using the sendCustomScriptFunction() of the rtde_control interface. (Unfortunately you have to send over the preamble with the gripper api functions everytime, it does give a bit of delay). Attached you will find some example code in python with the preamble embedded. It exposes a RobotiqGripper class, that can be used together with ur_rtde like the following: 

from robotiq_gripper import RobotiqGripper
from rtde_control import RTDEControlInterface
import time

rtde_c = RTDEControlInterface("<ROBOT_IP>")
gripper = RobotiqGripper(rtde_c) # Activate the gripper and initialize force and speed
gripper.activate() # returns to previous position after activation
gripper.set_force(50) # from 0 to 100 %
gripper.set_speed(100) # from 0 to 100 %
# Perform some gripper actions
gripper.open()
gripper.close()
time.sleep(1)
gripper.open()
gripper.move(10) # mm
# Stop the rtde control script
rtde_c.stopRobot()
 

Rasp

Hey Anders,

thank you for the information, and of course thank you for sharing your library!
I ended up first trying SDU's library. Here is what I did for that:
  1. Forked the library
  2. Modified SDU's URScript to include all the functionality to communicate with the gripper, similar to the script you can get when you create a program with the Robotiq_Grippers URcap in the teaching pendant.
  3. Modified the C++ API and python bindings to expose some of the methods, or to change recipes to include gripper parameters.
This worked fairly well, but then I started hitting some hurdles, namely:
  • Having the URScript and the recipes hard-coded required compiling SDU every time I wanted to try a small script change
  • Compilation time on my Macbook takes around 10 minutes, so iteration time was very slow.
  • I would have to divert substantially from the library (for example, I did not like that SendCustomScript would restore the original script after execution, since like you said it would require the preamble, and also seems designed for lower frequency updates than what I want to try)
  • Certain delays in the arm (eg: SDU C++ waiting for the arm to ack the received command via signal_ready) would delay commands for the gripper, so I would have to continue separating their logic more.
  • [question] Is there a reason why the script and recipes can't be data-driven, instead of hard-coded (the script loads as .h)?
  • [question] Is there a way to speed up compilation for fast iteration? I did not look too much into it, but the culprit looks like boost linking.

I decided to try the direct communication approach, and I was able to create a simple python script that communicates with the gripper directly using port 63352. That port is the one Robotiq_Grippers URcap exposes to URScript. It receives commands in ASCII, and I have been able to get/set position, speed and force, and to retrieve object information (OBJ), to understand when I grip an object, so it seems to work for my case.

Both bcastets and you seem to suggest modbus RTU with the ROS driver. Are there any drawbacks to using the socket exposed by
Robotiq_Grippers URcap, which accepts ASCII commands instead? I was even able to command the gripper using https://sourceforge.net/projects/sockettest/ . This is how Robotiq_Grippers URcap seems to implement teaching pendant nodes.

Thank you,
Sam.




prier

Great that you found a solution!

I was actually not aware that you could communicate directly to the robotiq socket at 63352, that seems like a great solution. It is likely a better option than using the rs485 cap, since you cannot run the Robotiq_grippers cap together with that. If you are in a position to share the code, I would be interested.

So for your questions.

  • Is there a reason why the script and recipes can't be data-driven, instead of hard-coded (the script loads as .h)?

    No, however initially my reason for doing this for the script, was to avoid deserialization from the filesystem (performance and dealing with file paths). It is actually supported to load the script from a file instead through (sendCustomScriptFile), but some small code changes would be needed to make it part of the 'protocol' eg. re-upload functionality. But I completely agree with you, it is fairly annoying that you have to rerun cmake + compilation to evaluate a small change in the script, and the performance is essentially irrelevant during initialization. 

    Regarding the recipes I just wanted it to be fast (read from memory) and I did not have a lot of recipes in the beginning. Since there is now a lot of recipes and a potential need for custom recipes also, I will make it file based instead (XML or YAML likely) which is also a lot nicer and something that has been on my TODO almost since I initially implemented the library.

  • Is there a way to speed up compilation for fast iteration? I did not look too much into it, but the culprit looks like boost linking.

    Yes I actually haven't done much optimization in terms compilation speed, I believe some classes can be forward declared and I will take a look at the linking in general.
About the delays introduced by the acknowledge process, this is something that I am currently looking into. I have done some changes for servo and speed commands, that makes these a lot faster the 7-8ms delay is reduced to ~20 microseconds. 

Thanks for the feedback, it is very valuable.
bcastets

I understand now about your method to send gripper command by connecting to gripper URCAP server via port 63352.
I never tried to communicate with gripper URCAP server from outside but it sounds like a good idea.
I will try it !
Rasp

- - -
@prier
It's great that you are addressing those points! I think the library works great for the UR arm; I did find it less flexible to add more features due to its design: it seems very focused on supporting just the arm, and in a very specific way.

Another example of a thing where I needed to create more scaffolding was in the output registers: I was trying to add the outputs from the gripper, and I had to create methods and bindings because ur_rtde does not expose all output_int and output_float registers.

Overall it's been a great start for me, I could start programming the arm right away; but it lacked in comfort/flexibility to add new features or to use it in a different way than originally intended. For example, I am very happy you are addressing the 7-8ms delay.

My 2 cents. :)

- - -
@prier @bcastets

See attached gripper_2f85.py file (remove .txt extension)

An example on how to use it could be:
def log_info(gripper):
    print(f"Pos: {str(gripper.get_current_position()): >3}  "
          f"Open: {gripper.is_open(): <2}  "
          f"Closed: {gripper.is_closed(): <2}  ")

def run():
    gripper = Gripper2f85()

    gripper.connect('10.0.1.5', 63352)
    gripper.activate()

    gripper.move_and_wait_for_pos(255, 255, 255)
    log_info(gripper)
    gripper.move_and_wait_for_pos(0, 255, 255)
    log_info(gripper)

Note that in my implementation the variables are not cached, so each getter will try to contact the gripper. This can result in inconsistencies in a real environment, so an atomic `update_all_vars()` may be needed to resolve those inconsistencies in a real deployment. IIRC SDU's ur_rtde also has this issue, since variables updated from the robot state update one at a time (you may read some updated vars vs some not up-to-date yet.)

Feel free to try it, and give feedback.

The manual was very helpful to understand each variable:
https://assets.robotiq.com/website-assets/support_documents/document/Hand-E_Manual_UniversalRobots_PDF_20191219.pdf

And testing with https://sourceforge.net/projects/sockettest/ was trivial. Set IP address and port, connect, and write "GET POS" or "SET POS 255".



bcastets

Hello rasp,
Thank you for sharing this. I will try it !
Rasp
Rasp
felixvd
Rasp

felixvd said:
Hi Rasp,

Thanks a lot for posting your script. I made this ROS node based on it, and it seems to work well from what I can tell. It is a lot more convenient than sending URScripts, for sure.

If you add a permissive license (ideally BSD, MIT or public domain) I will be happy to apply the same and release the code in a package.

Hi @felixvd,

glad to hear it was useful. I know there were a couple of bugs/typos, but I do not plan to release an update since it was functional. Please feel free to modify as you see fit.

You can consider the script file as released under MIT license.

As far as I know, @prier released it as well under SDU's RTDE library, where https://gitlab.com/Exchizz fixed that one issue:
+ fix https://gitlab.com/sdurobotics/ur_rtde/-/commit/c3eb7efb93385c9da408660c3c2b74aa5527fa71
+ file https://gitlab.com/sdurobotics/ur_rtde/-/blob/master/doc/_static/gripper_2f85.py

One thing I noticed, for everyone interested, is that using URCaps (via TCP socket) to communicate with the gripper seems to yield an update frequency of around 50Hz, while it should be possible to achieve 200Hz according to the manual. I have been more successful communicating at higher frequencies via modbus. But if you do not need high frequency, the URCaps / TCP version would be good.

Cheers!









cwang344

Hi @Rasp, thanks for sharing your Robotiq code on the UR_rtde library. Your code seems to have the "gripper_socket" set at 1 by default. Is there any way we can change the "gripper_socket" value? I have two grippers connected to the UR robot and wish to control both of them by setting them with different "gripper ID(socket)", and control them seperately. 
Rasp

Hi @cwang344

I am not sure which script you are referring to, since the gripper_2f85.py file does not have a variable `gripper_socket`.

Unfortunately I do not have access to the URCaps code anymore, so I'm not sure what it does to access a second gripper. I remember that it exposes port `63352`, so perhaps `63353` is the next gripper, and you would connect with: gripper.connect('10.0.1.5', 63353) ?

Sorry I can't be of more help. I don't have access anymore.
felixvd

felixvd said:
Hi Rasp,

Thanks a lot for posting your script. I made this ROS node based on it, and it seems to work well from what I can tell. It is a lot more convenient than sending URScripts, for sure.

If you add a permissive license (ideally BSD, MIT or public domain) I will be happy to apply the same and release the code in a package.
I forgot to update that we have released this along with our ROS1 setup with two UR5e robots using Robotiq grippers and Realsense SR305 cameras. They got 3rd place in the World Robot Summit Assembly Challenge and the complete source code is here: https://github.com/o2ac/o2ac-ur

zoom

bcastets

felixvd said:
felixvd said:
Hi Rasp,

Thanks a lot for posting your script. I made this ROS node based on it, and it seems to work well from what I can tell. It is a lot more convenient than sending URScripts, for sure.

If you add a permissive license (ideally BSD, MIT or public domain) I will be happy to apply the same and release the code in a package.
I forgot to update that we have released this along with our ROS1 setup with two UR5e robots using Robotiq grippers and Realsense SR305 cameras. They got 3rd place in the World Robot Summit Assembly Challenge and the complete source code is here: https://github.com/o2ac/o2ac-ur

zoom
Congratulation for this ! Would it be possible to share a video of this or a link presenting what you did at this challenge ? We could eventually share this on social media.
Feel free to contact me.