Our Setup:
We are communicating with the UR control box via TCP/IP using the RTDE protocol, sending commands from a linux system with patched real-time kernel to our UR10e robot. We want to control the robot in joint space and need very fast response to follow our desired joint angles that are sent from the linux pc. On the linux pc a loop with 2ms cycle time is running and sending new desired joint angles to the robot controler. On the robot side we are using the servoj(…) command to track the desired joint angles.
Our Problem:
We are saving the desired (sent to the robot) and actual joint angles (received from robot) in the same cycle as vectors on the linux system. After performing a cross-correlation of the two vectors, we see delays of ~17 time steps (with a cycle time of 2ms this corresponds to 34ms).
To test our communication we only sent joint angles to the controler and back to the linux system. (We removed the servoj() command and replaced it with a sync()). Now the delays shown by the cross-correlation are 2 or 3 time steps (corresponding to 4ms or 6ms).
Our Conclusion:
The servoj(q_des, 0, 0, 0.002, 0.03, 1200) has a time delay according to lookahead_time = 0.03s. This is a serious problem for our application.
Our Question:
Is the time delay of 30ms coming from the servoj() command with lookahead_time=0.03?
Can we somehow reduce this time delay?
Can we use another function than servoj() to control the joint angles? (maybe less safe but faster?)
Thanks for your help!!
This topic was later discussed here and a solution (work around) proposed: Reduce Delay Time of ServoJ Command ( lookahead_time ?) · Issue #86 · UniversalRobots/Universal_Robots_Client_Library · GitHub