Synchronization of RTDE

Technical Questions Robot Communication
1

Hi,

I am currently working on a project, where I have to legitimate the usage of RTDE over some simpler implementations with other Interfaces (RT, Modbus, XML-RPC etc.). The main benefit all the articles and forum threads keep mentioning is the synchronization feature of RTDE in combination with the 500Hz update frequency, which I somehow don’t understand.

What makes the RTDE synchronize with another device and how exactly does it work?

All I can think of is that it synchronize both CPU clocks (of the control box and the external PC), but I can not see how this is done. I am very curious about this topic, since I am implementing the RTDE communication not withing Python or C++ but in Simulink Desktop Real-Time and I need to know if there is something I have to do within this implementation to achieve the synchronization.

Thank you in advance and kind regards,
Max

2

Hey Max,
While I am not a heavily experienced with UR nor real time computing I will speak from perspective of someone who just implemented a client for RTDE protocol.

RTDE communication is based on TCP thus its real time guarantees are as good as your network. The “synchronization” works differently depending on direction.

  1. Communication from robot (server) to computer (client) is subject of real time resource constraints. If robot controller will be busy doing computational tasks then it will drop outgoing network frames. This means that your client might not get all packets, but when it will - it will always receive most recent state of outputs.
  2. Communication from computer to robot is processed in the present control cycle, below a quote from docs:

Input packages will always be processed in the control cycle they are received, so the load for the controller will vary depending on the number of received packages.

For 500 Hz frequency you might expect data packet every 2 ms. With such short cycles you will probably notice some friction due to network latency. With some more advanced network switches you could try to prioritize TCP traffic on port 30004 in order to reduce jitter.

From RTDE point of view you get a packet every X ms. How many I/O or control cycles are in between is not clear. You can combine several outputs together with a timestamp which should give you a controller timer as well.

3

Thank your for your reply.

This is how I thought it to be. I was just curious, if there is some internal mechanism inside RTDE which somehow allows actions only under certain conditions and therefore tries to achieve actually synchronization of the cpu clocks since a lot of people were referring to some kind of synchronization feature. But the robot will at least react to every input package even when it would drop an output package as far as I understood this behavior.

So my question would then be, why to use RTDE for the purpose of real-time control instead of using the RT interface on port 30003? What is the actual benefit? What was your purpose for choosing RTDE?

4

I can’t comment on robot controller functionality, as my understanding of RTDE input and output communications is same as yours. I believe that many, if not all, network protocols will be a subject of similar limitations when it comes to real time communication. A single TCP retransmission could lead to a noticeable delay in arrival of data on either side.

For RTDE vs RT interface I believe main difference is scope of protocol. Both RTDE and RT ports can give you cycle time up to 500 Hz (2 ms). However the earlier seem to have a better control over packet structure (you can pick what you send/receive) and better coverage of robot inputs and outputs.
Give that RT is marked as deprecated RTDE seems to be a recommended way from UR. Anyhow, I would rather wait for someone from official team to answer your concerns as my observations might be pretty far from real… time :slight_smile:

Cheers,
Łukasz

1 Like
5

Thank you for sharing your ideas and yes, it seems like we do have a similar understanding of RTDE. :slightly_smiling_face:

It would definitely be interesting to hear some expert’s opinion on this topic, but maybe there simply is no real benefit except the advanced management of data packages.

Best regards,
Max

6

As you mention, being able to control what you receive over RTDE is much more convenient than dealing with the RT datastream, but I think another big factor here is that while the RT client interface will attempt to maintain an output frequency of 500Hz, it’s very much one way. If you send two commands back to port 30003 in a single cycle, the earlier one will be overwritten and only the latter executed.

Once you configure your desired frequency in an RTDE client, it will ensure that your data is fed in at the right time for it to be used in the next control cycle. Can I explain exactly how it does that? No :slight_smile: