Real Time Data Exchange (RTDE)

RTDE is a protocol designed for Universal Robots to facilitate real-time communication between the robot controller (UR5E's onboard computer) and external systems, operating at the controller's native real-time cycle of 500 Hz (2 ms per cycle).

This communication protocol:

• enables users to both send commands and receive data from the robot with minimal latency
• this makes it highly suitable for applications requiring precise timing and synchronization

RTDE Protocol Details

RTDE is a TCP/IP-based protocol that operates over a dedicated port (30004) on the robot controller. It supports bidirectional data exchange, allowing for efficient real-time monitoring and control of the robot's operations. Protocol can handle:

• Joint and Tool data such as position, velocities, accelerations and forces
• State Information such as safety modes, runtime state, and digital/analog/ I/O states
• Custom Data that are defined by the user, such as custom registers for integer and double values

The Mechanism

RTDE does not steam all available data. At connection time, the client and controller negotiate a recipe which is an explicit list of variable names the client wants included in each cycle's packet. A recipe is like a fixed list of variables names to include in a data packet. So if we set up the output recipe, we are saying that every output packet that u send to the client must contain ["timestamp", "actual_q", "actual_TCP_pose". This is the entire recipe which contains just 3 strings and no functions whatsoever. Every 2 ms cycle, the controller then sends the client a packet shaped like this, [12.340, [0.1, -1,2, 1.0, -0.3, 1.57, 0.0], [0.4, 0.1, 0.3, 0, 0, 3.14]]. This is the same order as the recipe and the recipe is fixed for the entire lifespan of the connection.

Recipe type	Direction	Example fields
Output recipe	Controller to client	actual_q, actual_TCP_pose, timestamp
Input recipe	Client to controller	speed_slider_mask, input_int_register_0

Connection Sequence

RTDE follows a fixed handshake before streaming begins.

1. TCP connects to port 30004
2. Client (our python script) requests a protocol version and controller confirms compatibility (Protocol version negotiation)
3. Client sends RTDE_CONTROL_PACKAGE_SETUP_OUTPUTS and/or _INPUTS with the desired field list, controller responds confirming the recipe and assigning each output recipe an ID
4. Client sends RTDE_CONTROL_PACKAGE_START which then allows the controller to start sending data packets each cycle

Synchronisation Model

RTDE is synchronous by design. Each 2 ms controller cycle produces exactly one packet per configured output recipe, and the client is expected to consume it before the next cycle if it wants to stay lock-step with the controller.

Interface	Port	Purpose
Dashboard Server	29999	Coarse control: load/play/pause programs, power on/off. Not real-time.
Primary/Secondary Script socket	30001/30002	Send raw URScript text commands. No structured state streaming back.
RTDE	30004	Structured, high-frequency, bidirectional state + command streaming. What ur_rtde is built on.