Strange/broken behavior with URScript

jonlong 2017-02-02

I have a Robotiq 85 2-finger gripper that I'm using with a UR5 running version 3.3.2.266, and would like to control remotely (presumably via URScript).

Perhaps I have missed something basic, but this does not seem to be working, and behaves in ways I would not expect.

When I run "gripper_tutorial.urp" from the pendant, that does work. But when I single-step through any of the rq_* commands (using the >| button on the bottom of the pendant display), I get a compile error, e.g., "Compile error: name 'rq_close' is not defined". Likewise, sending rq_* commands over a socket does not work; there does not seem to be any effect.

I can control the gripper remotely using raw socket commands from URScript, e.g., socket_set_var("POS", 255, "gripper_socket"). But that does not seem to work reliably, and does not seem like the right way to do things given the presence of the rq_* commands.

Any idea what might cause this behavior? Have I missed some initialization step? Shouldn't I be able to send "rq_close()" (e.g.) over a URScript socket?

matthewd92 2017-02-02

@jonlong Not that I'm aware of as those are not "native" features of the robot language. The Robotiq script is loaded into the robot memory at run time when you press play. The way it works on the robot is when you press play the program is compiled and all new script functionality is loaded at that time.

If you try to single step through the program those scripts are not loaded as the program is not actually being executed and therefore you get the error. My understanding is when you press the single step button you are actually compiling a small program for that step and then sending that one step to the controller as a program. To emulate that behavior you'd have to send as your program to the controller the entire Robotiq script file along with the one command you want to execute so that it's loaded in the run environment.

jonlong 2017-02-02

Okay, thanks, I think that explains the behavior I'm seeing.

Sending the entire Robotiq script with each command does not sound very efficient; is there no efficient way to control the gripper over a socket while it's connected to the UR control box?

It sounds like I should just connect the serial port of the gripper externally to the UR control box; is that what you'd recommend?

matthewd92 2017-02-02

Honestly, never tried controlling the gripper from off the robot. When we do things like that we don't generally have a Robotiq on them.

How are the socket commands not being reliable? We do quite a lot (rather did, replaced not too long ago with RPC) with socket commands and never had any issue with them. We weren't controlling a gripper but communicating with an off-robot device over TCP/IP

jonlong 2017-02-02

Okay, I'm leaving URScript and switching to external control.

What I meant about the socket commands is that simply calling "socket_set_var" over a URScript socket does not seem to reliably produce the expected response on the gripper (sometimes it does, sometimes nothing happens). The actual Robotiq implementation does a number of "sync" calls and has an ack-retry loop. I presume that that would work reliably, but again it's somewhat cumbersome to be sending that code as URScript for every gripper action...

cgilmer 2017-02-02

I have the exact same issue as you are having. I would prefer to use the rq_* commands that I've seen shipped with the R85, but they are not available to me over a socket connection. Currently I have to send individual "socket_set_var" commands to get the behavior I want and use a python time.sleep(2) command to block.

For reference, I'm using and contributing to code here: https://github.com/SintefRaufossManufacturing/python-urx/blob/master/urx/robotiq_two_finger_gripper.py

I'm currently reaching out to Robotiq to see if an engineer has a better idea of how to handle this situation.

matthewd92 2017-02-02

@cgilmer Since you are using an external library for robot control I am assuming you are also using an external computer, how about just hooking into the gripper directly from the PC? You could just open the socket on the gripper and not have to go through the robot at all. When we wrote the nodejs library similar to that one that was the plan we had for any external devices on the robot.

cgilmer 2017-02-02

@matthewd92 - Interesting idea. Can you link me to your node library? Or is there a spec I can look at for socket communication to the gripper? It's somewhat nice to go through the UR but not necessary. If I could talk directly to the gripper I will probably have more control, which would be nice.

matthewd92 2017-02-03

@cgilmer we never implemented the Robotiq interface as we would up using an end effector we could operate via digital I/O and so just didn't need it for the project we were building the library for. It's actually still quite incomplete and we haven't opened it up to anyone outside our organization at this time but if there are some specifics you are interested in I can take a look at letting out small bits of the code. At some point when we have some more time to dedicate we'd like to get back on the project and open it up for some folks to help us with it.

As as far as communicating to the gripper here's some documentation on how to do that via Modbus RTU over either the USB to RS485 converter or directly via RS485. We're doing something similar on another project but we write all of our code in nodejs. The biggest difference with that project is we are strictly reading data so no writing to the registers but it looks rather straightforward just briefly reading over the docs.

http://support.robotiq.com/download/attachments/5963876/2-Finger-Instruction-Manual-060716.pdf?version=1&modificationDate=1467835896840&api=v2#page54

cgilmer 2017-02-03

This is actually super helpful. It looks like the best way to manage the robotiq in this instance is to bypass the UR all together and just talk directly to it. If I find time to do it, and if my company lets me, I'll try to open source the python driver when I get it done.

matthewd92 2017-02-09

So I had a little spare time today so I sat down and started working on a nodejs library for controlling the 2F-85 gripper. You can find the source code at https://github.com/mbush92/robotiq-node. Its very limited in scope currently as I just started knocking out some code this afternoon but you can activate the gripper and then open and close it. If you're familiar with node you can run a simple script that I wrote called gripper.js in the /lib folder and it will control the gripper through an close and open cycle. I will hopefully be doing some more work on this over the next few days.

Hopefully it will give you guys some ideas on how to control the gripper using other languages as well.

Also just as a note, I do not warranty the code to be free from errors or bugs so use at your own risk....had to throw that out there you know

If anyone wants to work on this code as well let me know and I can add you as a contributor

cgilmer 2017-02-09

@matthewd92 - This library is great. It looks like you talk directly on a serial connection to the gripper. Have you figured out how to talk to the robotiq over an ethernet connection?

matthewd92 2017-02-09

@cgilmer Thanks, still a ways to go to make it really useable but it's a start. Since it's a serial device I just talked to it directly. I plugged the USB cable directly into my mac. Since it uses modbus RTU I'd think you would have to still somehow convert from TCP/IP to serial at some point to actually communicate to it

Something that would be nice to have confirmed is if they all have the same address when you plug them in. I was able to find it pretty quick by looking in the /dev folder on my mac. @Etienne_Samson would you or one of the others have the answer to that question about the device address.

PierreOlivier_Proulx 2017-02-13

@matthewd92 The addresses of the usb/serial converter are assigned by the OS. So we cannot tell in advance how they will be named. On linux for example, they are named /dev/ttyUSBX or /dev/ttyACMX where X is an integer.

@cgilmer For an external library to control Robotiq devices, have a look at the ros-industrial robotiq package. https://github.com/ros-industrial/robotiq. Use the gripper manual for the communication protocol description.

PierreOlivier_Proulx 2017-02-13

@cglimer I re-read your post and regarding that quote "I would prefer to use the rq_* commands that I've seen shipped with the R85, but they are not available to me over a socket connection." nothing prevents you from appending the gripper preamble to the urscript you are sending over tcp. This preamble declares the functions we use to control the gripper and you can find it in the .script file that is generated when you press the play button (those files are located next the .urp file in the programs directory).

That preamble is quite long but you can probably prune it and keep only the relevant functions for your case.

cgilmer 2017-02-13

@PierreOlivier_Proulx - I had tried appending the preamble to my script but it did not appear to work when I did it. So for now I've left it out. Instead I control the gripper state via UR script using socket_set_var and then put a timeout in my own code to simulate how long I expect it to take.

A better solution would be for me to talk directly over a socket connection to the gripper via the UR's built-in Modbus (as opposed to buying a separate modbus controller and connecting the gripper to it separately). I haven't been able to do this yet or I haven't figured out how to set up the modbus on the polyscope correctly to allow it.

My goals are really two-fold (and not exclusive):

1. Cause a blocking action on the gripper action so that no other commands run while the gripper is in motion. (this is applicable probably only to my setup)
2. Get the gripper state in real-time so I can figure out what's going on.

I haven't figured out how to do #1 (blocking action) so instead I have the timeout. For #2, I think the variables I want get set globally and output on the primary monitor (the polyscope) but these same variables aren't sent out to the secondary monitor, which is what I'm using to monitor the robot and thus the gripper state. I think this is more a problem with UR than with Robotiq.

This brings me back to my initial wish - that I could control the robotiq directly over the UR modbus interface. Any idea how to do this?

PierreOlivier_Proulx 2017-02-13

You can't control the gripper over UR modbus interface because UR client is ModbusTCP while the gripper is ModbusRTU (i.e. over a serial line). To do so you would have to buy a ModbusTCP controller to control the gripper.

I still think that copying the whole preamble should work. URScript is very sensitive to indentation and it is not very verbose when problem occurs. Why not trying pasting the preamble but one function at a time to see the result incremantally.

cgilmer 2017-02-13

@PierreOlivier_Proulx - You may have solved my problem. What is the indentation rule that must be followed? I bet my indentation was wrong and so it errored out.

PierreOlivier_Proulx 2017-02-14

The particularity is that function definitions cannot be on the same indentation level as the program definition. However, regular instruction can. This might look obvious but we had situations where we were having a functional script with built-in instructions on level 0 and then, after adding a function nothing worked. You also have to be careful with the : at the end of control instructions (if, while, function) and the end that close those control instructions block. As a general rule, when I have to write a script by hand, I usually do it very incrementally, testing every small modification in order to catch problems early.

def prog(): 
 def func(): 
 textmsg("abc") 
 end 
func() 
end

cgilmer 2017-02-14

@PierreOlivier_Proulx - I'm going to try this out. It's super helpful. Thanks for sharing this with me. I'll let you know if it works sometime in the next couple days when I get back to it.

PierreOlivier_Proulx 2017-02-14

@cgilmer I took a look at the repo you linked https://github.com/SintefRaufossManufacturing/python-urx/blob/master/urx/robotiq_two_finger_gripper.py. I think that you could directly add the gripper preamble in that file and use rq_* functions directly instead of socket_set_var.

cgilmer 2017-02-14

@PierreOlivier_Proulx - I think you're right. one other question: do you know if the URScript is sensitive to tabs or spaces? I assume it requires tabs. But if you know it would help tremendously.

PierreOlivier_Proulx 2017-02-14

@cgilmer I always use spaces.

cgilmer 2017-02-14

@PierreOlivier_Proulx - good man!

matthewd92 2017-02-14

I've found that it doesn't matter either way, tabs though seem to be pretty indented.

PierreOlivier_Proulx 2017-02-14

@cgilmer take a look at this fork, I appended the preamble.

pgb123 2018-05-14

Hi Pierre and Matthew et al,

The link as step 1 of the setup for this project seems broken, is there any other source for the driver, as it seems like a great project?

SETUP

|
| You must install the driver first and then power on the gripper from the
| gripper UI. The driver can be found here:
|
| http://support.robotiq.com/pages/viewpage.action?pageId=5963876
|
| FAQ

Also @Pierre, as we are newbies with URX, is yours a fork of this https://github.com/SintefRaufossManufacturing/python-urx and which is the best for us to start with?

PierreOlivier_Proulx 2018-05-14

Yes it is a fork of this repository. The Step 1 refer to which project?