Controlling Tool Output while using a newer version of the Robotiq Gripper URCap is not possible

[firesurfer]

Affected ROS2 Driver version(s)

Prob. all

Used ROS distribution.

Iron

Which combination of platform is the ROS driver running on.

Ubuntu Linux with standard kernel

How is the UR ROS2 Driver installed.

Build both the ROS driver and UR Client Library from source

Which robot platform is the driver connected to.

UR E-series robot

Robot SW / URSim version(s)

5.14.6.123463

How is the ROS driver used.

Headless without using the teach pendant

Issue details

We have a UR16e with a Robotiq 2f-85 connected to the wrist.
We currently use the Robotiq Gripper URCap on the arm in order to control the gripper. The URCap opens a TCP Socket which allows to remotely control the gripper as well as controller the gripper with the Teachpanel, what is quite convenient.

But when upgrading the gripper URCap from UCG-1.8.13.22852 to anything higher we can not select in the Installation tab -> ToolIO -> Controlled by: User, as the URCap will then refuse the interact with the gripper.

I contacted the Robotiq support and UR support. Basically the answer was. Yes this is intended (but they didn't tell me why). BUT: When selecting: ToolIO -> Controlled by: Robotiq Gripper UrCap it is still possible to control the IO via the script command: set_tool_digital_out (Confirmed by the UR support. I didn' test it myself to be honest).

When taking a look at the external control urscript I can not find this command being used to set the tool io. (But we definitely can via the ROS2 Driver). I guess the IOs are set via a different control method.

So my request is: Support setting the tool IO via the urscript in order to workaround with issues in combination with the Robotiq Gripper UrCap. Perhaps you have a better contact to UR and can figure out why Robotiq was forced to include this check...

Relevant log output

No response

Accept Public visibility

• I agree to make this context public

[RobertWilbrandt]

I don't quite understand how this relates to our ROS 2 driver. We use the RTDE protocol to read the robot state, move the arm and set i/os. This did not change.

What exactly do you want to achieve? Why do you need to be able to directly set tool i/os if the robotiq urcap is used?

[firesurfer]

@RobertWilbrandt

1. Why do I want to set one of the tool outputs while the robotiq urcap is used?

The robotiq 2f-85 only uses one of the outputs as power supply. We use the second one to control an electromagnet mounted at the wrist.
Being able to control the gripper from remote + from the teach panel is very convenient for testing.

2. Apparently setting the output via the urscript instead of RTDE still works with newer versions of the urcap.

As neither UR nor Robotiq want to do anything about this the only way of having this very convenient feature is by changing the way the IOs are controlled in the ROS driver....

[RobertWilbrandt]

I see, that makes sense.

We are aware that using RTDE for IOs can lead to problems when integrating with additional equipment (also e.g. if you try to control the UR IOs from a PLC while controlling the joints through ROS). Enabling IO control through a different interface is on our roadmap, but we don't have a timeline for that yet.

@urrsk do you maybe have some more information on this specific conflict with robotiq?

[urrsk]

@firesurfer you have a good point and we are aware about it. In general, we are missing a good way to integrate URCaps with the use of the ROS drivers.
On the short term, regarding the digital and analog outputs, we have talked about expending the script_commands thread in the Universal_Robots_Client_Library/resources/external_control.urscript#L496 to also control the outputs as an alternative to use RTDE.

[firesurfer]

@urrsk
Could you perhaps elaborate why it should make a difference to control an IO via RTDE or via a urscript? In both cases one would need to accept that one can interfere with the settings from an installed URcap (or it has to be blocked). Unfortunately I did't get any useful answer from the UR support why this specific behavior has been changed (That the robotiq urcap may only control the gripper if the IOs are controlled by the urcap) .

[EbbeFuglsang]

@firesurfer Our current way of managing the Tool Connector have it limitations. The intend with selecting one owner is that they are in control. In the past we have seen cases with other tool manufactures tools have been disturbed by the presence of Robotiqs URCap, even when they were selected as owner of the tool connector. That is what Robotiq have fixed here.
Is it an option to use the UCG-1.8.13.22852 version of the URCap?

[firesurfer]

@EbbeFuglsang Thanks for the info.

Is it an option to use the UCG-1.8.13.22852 version of the URCap?

Thats what we are currently doing. But given that there were some necessary updates in the past I would like being able to run the newest version of the URCap to avoid bad surprises in the future.
(E.g. at some point the combination of the URCap and a newer Polyscope version lead to the gripper shutting down during startup because of an over current condition)

Also I would argue that from a user point of view: If I select: Controlled by user, than I would like to be able to control it myself ;)