Home› Programming

Discussion

Left ArrowBack to discussions page
RaspRasp Posts: 8 Apprentice
edited February 2020 in Programming
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:
  • According to UR's training https://academy.universal-robots.com/modules/e-Series%20core%20track/English/module2/story_html5.html?courseId=2165 , the gripper could be controlled by setting the digital output on the teaching pendant. This doesn't seem to work for 2F-85. Is this because this gripper requires the more complex API (rGTO and other vars), and the digital output is simply ignored or not connected?
  • What are the main differences between connecting (from a unix machine) directly to the gripper (via port 63352) to send UR commands to the gripper, and connecting to the RTDE interface (via port 30004) so that a UR script running on the robot communicates with the gripper?
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://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://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:

d) Connecting directly via MODBUS RTU

e) This unclear method through rs485 (looks similar to MODBUS RTU as stated in option 'd'):

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.
Tagged:
· TwitterFacebook

Best Answers

Comments

  • RaspRasp Posts: 8 Apprentice
    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.


    · TwitterFacebook
  • RaspRasp Posts: 8 Apprentice
    edited February 2020
    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.




    · TwitterFacebook
  • prierprier Posts: 2 Recruit
    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.

    · TwitterFacebook
  • bcastetsbcastets Vacuum Beta tester Posts: 674 Expert
    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 !
    · TwitterFacebook
  • RaspRasp Posts: 8 Apprentice
    - - -
    @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. :)

    - - -

    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.


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



    · TwitterFacebook
  • bcastetsbcastets Vacuum Beta tester Posts: 674 Expert
    Hello rasp,
    Thank you for sharing this. I will try it !
    · TwitterFacebook
  • RaspRasp Posts: 8 Apprentice
    No problem.



    · TwitterFacebook
  • RaspRasp Posts: 8 Apprentice
    No problem.



    · TwitterFacebook
  • felixvdfelixvd Posts: 7 Apprentice
    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.
    · TwitterFacebook
  • RaspRasp Posts: 8 Apprentice
    edited August 2020
    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.


    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:

    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!









    · TwitterFacebook
  • cwang344cwang344 Posts: 4 Apprentice
    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. 
    · TwitterFacebook
  • RaspRasp Posts: 8 Apprentice
    edited September 2021
    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.


    · TwitterFacebook
  • felixvdfelixvd Posts: 7 Apprentice
    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


    · TwitterFacebook
  • bcastetsbcastets Vacuum Beta tester Posts: 674 Expert
    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


    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.
    · TwitterFacebook
Sign In or Register to comment.
Left ArrowBack to discussions page