Resetting infinite wrist_3_link [Question]

[cambel]

Summary

Hi, I am using the last link of the UR3e for a long rotation (several full rotations). For this, I move the robot using JointTrajectory messages which work fine. However, I am also using MoveIt for motion planning with obstacle avoidance, for which I set a finite joint limit to each joint. The problem is that if the joint position is outside the joint limits, MoveIt will complain about it so I have to manually reverse as many rotations, of the last link, to go within the valid range. Doing this reverse motion is way too inefficient.

Now, I notice that using the Polyscope GUI, I can set a target position for the wrist_3, for example, 0 degrees, then use the automatic option to move the robot. In that case, the robot will move less than a full revolution and reset the state of the robot to the target position.

My question is: can this be done through this ROS driver? can I somehow request/reset the target position of the infinite rotation wrist_3_link via ROS?

Versions

• ROS version: Melodic / Ubuntu 18.04 (Docker)
• ROS Driver version: 1.0.4

[fmauch]

I think the short answer would be no.

But I'm not sure, whether there might be a workaround / solution for this.

The joint state is read by the hardware interface using the actual_q field from the RTDE protocol. So, in order to "reset" the joint's value, we would have to either reset the joint state on the robot controller (which I am not sure whether it is possible), or substract / add a full revolution inside the driver and keep track of this, which I would not be such a huge fan of doing.

I guess, there are other robots out there facing this problem, so it would probably be a good idea to have a look how this situation is handled there.

[cambel]

Thank you.

I will check if UR_SCRIPT provides an option to reset the joint's values as the Polyscope option does. If so, I can use this driver to send UR_SCRIPT commands to the robot controller, right?

[fmauch]

Yes, that would be a manual workaround. If you found something, please post it here, so that

1. others can find this information, as well
2. we can think whether and how we could integrate this into the driver.

[cambel]

I found a workaround using URscript:

1. Since we have to use URScript, the connection to the robot e-series has to be initialized using headless_mode
2. Publish a custom script snippet to the topic /ur_hardware_interface/script_command the code is: reset_revolution_counter()

I understand the limitation of sending urscript code without being in headless_mode and this solution seems simple enough, but it would be nice to have a more direct option in the driver to do this operation.

[fmauch]

Why would you require headless_mode for this to work?

[cambel]

Well, maybe I misunderstood the documentation but I read:

Custom script snippets can be sent to the robot on a topic basis. By default, they will interrupt other programs (such as the one controlling the robot). For a certain subset of functions, it is however possible to send them as secondary programs. See UR documentation on details. Note to e-Series users: The robot won't accept script code from a remote source unless the robot is put into remote_control-mode. However, if put into remote_control-mode, the program containing the External Control program node can't be started from the panel. For this purpose, please use the dashboard services to load, start and stop the main program running on the robot. See the ROS-API documentation for details on the dashboard services.

Then I also read the section about the headless_mode and so I thought that if I didn't use the headless_mode It wouldn't be able to use the External Control program. I didn't test it but, is it possible to send custom script snippets to the robot without using the headless_mode?

[cambel]

Okay, I was able to do some more experiments. So, yes, there is no need for the headless_mode, though it is necessary to have the robot in remote control mode.

[urrsk]

An alternative is to extend the protocol to support his command or start looking into how the new interpreter-mode could contribute to the driver. See https://www.universal-robots.com/articles/ur/programming/interpreter-mode/ Both are not something we are currently working on. But you are welcome to contribute and help us.

[fmauch]

It could be added as a service that calls the correct script snippet analog to zero_ftsensor.

@cambel If you'd like to create a PR with this, that would be nice.