To understand Universal Robots control, it is necessary to examine where the control that actually moves the robot resides, and how each interface connects to that control.
The official UR3e User Manual describes a system consisting of a Robot Arm, Control Box, and Teach Pendant. The Robot Arm is the mechanical assembly with six joints; the controller coordinates the movement of those joints to move the arm. The Control Box houses that controller, external connection ports, and I/O.
Thus, the Robot Arm does not generate trajectories independently. From an external hardware perspective, the boundary is between the mechanical side—the Robot Arm, with its actuators and sensors—and the controller side—the Control Box, which coordinates them.
Universal Robots’ Script Manual identifies URControl as the low-level robot controller running on the Embedded PC in the Control Box. URScript and the various communication interfaces available to ordinary users connect to actual robot control through URControl.
Below URControl lie trajectory generation, joint control, servos, and interaction with motors and sensors. However, their internal interfaces are not exposed as external APIs for ordinary users. In practical terms, the lowest publicly accessible boundary for controlling UR from a PC is therefore the script execution system and communication interfaces exposed by URControl.
The Teach Pendant is an operating terminal connected to the Control Box; the GUI running on its screen is PolyScope. The official User Manual describes PolyScope as a GUI for operating the Robot Arm and creating, loading, and running robot programs.
The important point is that the TP does not directly operate the Robot Arm’s motor drivers. When a user creates waypoints or Move nodes on the TP and presses Play, the program is executed by the robot control system in the Control Box. PolyScope is not “the robot controller itself,” but a higher-level operating and programming environment for the controller.
Universal Robots publishes URScript as the Robot Controller’s scripting language. Motion configured in PolyScope and URScript sent directly from an external PC ultimately both reach robot motion through the script execution system on URControl. Commands such as movej, movel, servoj, and speedj are URScript motion commands; URControl executes them and passes them to the lower-level control system.
In this respect, the relationship resembles that between DENSO WAVE’s TP / WINCAPS and PacScript. The TP is the human-facing operating and teaching environment, Script is the robot language executed on the controller, and the actual motion control lies underneath.
Universal Robots publishes several interfaces for connecting an external PC to the controller. They do not have the same responsibilities.
The Primary / Secondary Interface handles URScript programs and controller information and can be used to send URScript from an external PC to the controller. This route reaches the URScript execution system without passing through PolyScope.
The Dashboard Server manages controller operating states, including program load / play / stop, power, and brake release. It is not an interface for describing robot trajectories.
RTDE has a different role again. It is the official interface for bidirectionally synchronizing variables exposed by the controller with an external application. Joint and TCP states, robot mode, safety, I/O, and general-purpose registers can be read; digital / analog outputs, the speed slider, and general-purpose input registers can be written from outside.
In other words, an RTDE client communicates directly with the controller and is not restricted to monitoring. However, the standard RTDE input fields do not contain motion commands such as movej, movel, or servoj; nor does writing target_q from outside automatically make it a joint servo target. RTDE is an interface for exchanging values exposed by the controller with a PC. Determining how those values are connected to robot motion is a separate responsibility.
Universal Robots publishes a Python RTDE Client Library on its official GitHub as a reference implementation of the RTDE protocol. This is a client library for communicating with the controller using RTDE.
The official repository also contains a robot-motion example, example_control_loop.py. Crucially, this example does not operate solely with a PC-side RTDE client. Its README instructs the user to copy the corresponding rtde_control_loop.urp to the robot and run the Python client together with the robot program.
It would be incorrect to interpret this arrangement as “another communication layer behind RTDE.” The PC’s RTDE client already communicates directly with the UR controller. The robot-side program is responsible not for communication but for defining how values written to the controller via RTDE are translated into robot motion.
Thus, the official RTDE motion example is a cooperative arrangement: the PC computes control values and updates RTDE inputs, while the controller-side program interprets those values as robot motion.
It follows that UR external control does not involve “the TP and the PC addressing completely separate robot controllers.”
In normal operation, PolyScope provides the human-facing environment for creating and running programs, whose results move the Robot Arm through URScript / URControl. Sending URScript directly from an external PC bypasses PolyScope and enters the same script execution system. With RTDE, the PC directly reads and writes variables exposed by the UR controller and, when necessary, combines those values with a controller-side program to produce motion.
Accordingly, when explaining Universal Robots’ architecture, PolyScope, URScript, and RTDE should not be placed side by side as equivalent “control methods.” Their responsibilities must be distinguished: PolyScope is a higher-level GUI, URScript is the robot language on the controller, and RTDE is a bidirectional data interface between the controller and external applications.