Update Rate

[futureneer]

It seems that any commands to the robot (via send_program) can only be sent at 10Hz.

I have spoken at length with the support team at Universal Robot, and they tell me that commands can be sent to the secondary interface at 30002 at near 125Hz. I am not sure what rate the robot broadcasts its information over 30002. I will ask them tomorrow morning.

I looked fairly deep into the code, and it looks like you are using a blocking socket.recv call. I tried setting the timeout of the socket to .01 seconds, but this causes several problems with other functions timing out. Would it make sense to have a shorter timeout, and have handling for when the socket doesn't receive anything? That would then allow commands to be sent to the robot faster than 10Hz, because the socket wouldn't be blocking and thus restricting the command rate.

Conversely, would it be easier to put the command code (`send_program') on a different client that the receive code, so that you don't have to mess around with that code?

This is related to Ticket #1, because (also from UR support) the best way to send smooth continuous commands to the robot is via speedl, because it is the only command that does not impose a velocity profile, which causes sequences of other commands (such as movel) to be jittery (as the robot is repeatidly command zero velocity in between commands).

I have written a PID velocity controller which can do this, but it requires fast (~100Hz) commands to the robot, as well as equivelently fast updates from the robot about its current pose. I will continue to discuss this with the UR support team.

I am happy to try and resolve this issue, I would just like to know what your design decisions were.

Cheers,
Kel

[KidsOfAllAges]

Hello Kel,
did you succeed with your PID controller ? I tried to control the UR10 with the servoj command from an external controller, but it's not working reliable enough, every once in a while the robot "bumps"... i think it has something to do with the congestion control algorithms (see here: http://rsewiki.elektro.dtu.dk/index.php/UR10)
With the speedj command communication problems don't seem to cause such mayhem, but then I need faster feedback from the robot, like you do. So i would be interested if you made any progress ?
Best, Matt

[oroulet]

I do not know why but I missed that thread. The robot processes data at around 10Hz so we cannot do anything on client side. I leave that bug opens so people interrested can refer to it. If you want to control the robot at aroud 100Hz then you need to write your own controller and run it on robot controller. This is possible, some people I work with do it, but it is not in the spec of urx.

[KidsOfAllAges]

Thanks for the info... do you have more information on the custom controller ? Does it work with the UR API, which I was told was rather difficult to work with ? 100Hz would be ace... but anything more than 25 would be a good start....

[BartMoyaers]

It's possible to use the real-time data stream to send commands, which you would ideally be able to send at at least 125Hz! According to this webpage:
https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/remote-control-via-tcpip-16496/

Since the creators of this repository already implemented code to connect through the RT data stream, it's fairly easy to implement sending URscript code faster. See pull request #79

We tested this on our UR5 running the 3.5 software.