Set tool center point (TCP) cleared when external control enabled

[RoBeau]

We are developing a mobile co-bot using a ur10e running along side a ros2 stack with moveit2. The majority of the time the arm controlled through moveit2 with the robot running the external control cap. However there are some situations when we need to send movel and set_tcp programs via the ur_script interface node.

Running with the docker simulation we are facing an issue when trying to alternate between external control with moveit2 and sending script commands the tcp is set back to zero. Steps to reproduce

1. Publish set_scp(p[0, 0, 0.2, 0, 0, 0])
2. Publish textmsg("TCP = , get_tcp_offset()) - Confirms tcp has been set
3. Publish movel(...) - Movel respects tcp settings
4. Play external control program
5. Publish textmsg("TCP = , get_tcp_offset) - TCP set back to zero

We have also found that after sending any ur_script programs via the external control program goes from "running" -> "normal" and requires the ur_dashboard/play service to be called to re-enable external control. We suspect this is causing the default installation to be loaded even though the dashboard manual only indicates this should happen via the load service.

Additional information

We are sending each set_tcp and movel cmd as a defined program followed the program call.
Docker simulation showing firmware version 5.13.0
Building the ur_robot_driver from source using the humble branch.

[RobertWilbrandt]

Thank you for your report.

urscript_interface stopping the program on the robot is expected behavior and documented here. For me, calling /dashboard_client/play does however not load a new installation - If i have my program "external control" running in some "test_installation", going through these steps does not change it. Can you describe what exactly you do that triggers the loading of your default installation?

I can reproduce your issue of the resetting tcp, but cannot quite figure out why that happens. @urmahp do you know what's happening here?

[RoBeau]

Thanks for the quick reply. Sorry for the confusion, the resetting installation was only a theory.

Also on a related but separate issue, it would be very handy to see the changes to the tcp via the script interface reflected in the GUI.

[urmahp]

This is intended behaviour, because when you play the program the robot will read the tcp configuration from the installation file, which in your case is zero. When you set the tcp using the script command it will be active until you overwrite it with a new set_tcp command or playing a program with a different tcp configuration in the loaded installation file.

[RoBeau]

Can you suggest an alternative way to achieve what we are after?

[fmauch]

An alternative aproach would be to

a) Modify the installation on-line (which to my knowledge isn't possible (at least straight forward), but I might be wrong)
b) Implement setting the tcp through the custom script interface in the client library and then wrapping this into a ROS call similar with how we handle the setPayload() call.
c) Edit: I am not sure whether setting the tcp would be doable using a secondary script, that would not abort the external_control script from running?

Option b) would require adding it to the urscript here and here, adding it to the ScriptCommandInterface, adding it to the ros2_control xacro similar to this and finally wrapping it into a ROS controller similar to this repo's gpio controller (Note that this is currently a dump for multiple funcionalities that will get broken up into individual controllers, see #579 for a standalone controller). Any help on implementing this would be very much appreciated, I think this would be a great enhancement.

[RoBeau]

Unresovled