1. Introduction
In 2010, German academia and industry proposed the concept of "Industry 4.0 ," which is the fourth industrial revolution, or a revolutionary production method, led by intelligent manufacturing. This strategy aims to transform manufacturing towards intelligent manufacturing by fully utilizing information and communication technologies and the combination of cyber-physical systems. Therefore, in recent years, many industrial automation manufacturers have focused on remote control capabilities as a key aspect of their product development. On the other hand, with the continuous rise in domestic labor costs and the uncertainty of factory worker turnover, the robotics industry is a sunrise industry in recent years and is expected to continue to be so in the coming years. Therefore, remote control of industrial robots in factory production is a promising topic in robot integration. We know that among industrial robots, UR Robotics was the first human-robot collaborative robot to work in industrial environments, known for its lightweight, simplicity, and safety. Below, we will explore how to achieve remote control of UR Robotics from a host computer.
2. UR Robots provides an interface based on the TCP/IP protocol.
The TCP/IP protocol, originating in 1969, is an architecture and protocol standard developed for the Internet, aiming to solve communication problems between heterogeneous computer networks. It enables networks to provide users with a universal and consistent communication service when interconnected. It is the protocol standard adopted by the Internet. TCP/IP-based communication features low cost, high reliability, strong practicality, and high performance. Therefore, many industrial automation products now have interfaces based on the TCP/IP protocol, enabling communication between devices and between devices and networks. UR robots, based on the TCP/IP protocol, provide rich interfaces for interaction with external devices, as shown in Table 1.
port | Interface Description |
Robot as server | |
502 | Modbus TCP protocol, robot as server |
twenty two | SSH / SFTP (Secure File Transfer Protocol) |
29999 | Dashboard features |
30001 | The first client port automatically returns robot status and supplementary messages. |
30002 | The second client port automatically returns robot status and messages. |
30003 | Real-time feedback port, automatically returns robot status and messages, 125Hz real-time feedback interface. |
Robot as client | |
Custom | Defined by UR script functions |
502 | Modbus TCP protocol, robot as client |
Table 1 UR Robot TCP/IP Interface Table
With these interfaces, the host computer can remotely control the robot. Figure 1 shows a simplified system diagram of the host computer remotely monitoring the UR robot.
Figure 1 Remote Control System Diagram
Next, we will introduce the relevant communication interfaces provided by UR robots, so as to remotely control the robot.
3. Modbus TCP port
MODBUS is an application-layer message transport protocol at Layer 7 of the OSI model, providing client/server communication between devices connected to different types of buses or networks. Since its emergence as the de facto standard for industrial serial links in 1979, MODBUS has enabled communication for thousands of automated devices. Currently, support for the simple and elegant MODBUS architecture continues to increase. Internet organizations can access MODBUS via reserved system port 502 on the TCP/IP stack. MODBUS is a request/response protocol and provides services defined by function codes. MODBUS function codes are elements of MODBUS request/response PDUs.
The UR robot can function as both a Modbus TCP server and a Modbus TCP client; the main difference lies in the message requester. Here, we will only discuss the case of the UR robot acting as a Modbus TCP server, as shown in Figure 2.
Figure 2 Modbus TCP Server
Since the UR robot acts as a Modbus TCP server, it must have a series of Modbus addresses for the host computer to access.
address | type | describe |
0-33 | Register | Can access all I/O of the robot |
128-255 | Register | Configurable Registers |
256-265 | Register | Robot status |
270-315 | Register | Information such as joint position, speed, current, temperature, and mode. |
400-425 | Register | TCP position, speed, offset, and other information. |
768-770 | Register | Tool-side status |
0-159 | Bit | All robot I/O can be accessed |
260-265 | Bit | Robot status |
Table 2 Modbus Address Summary
By accessing the Modbus address of the UR robot, we can obtain a lot of information about the robot, which can then be displayed on a host computer. The image below shows an interface created by accessing the Modbus address, mimicking Polyscope (the original software of the UR robot). This interface allows us to monitor and control the robot's I/O.
Figure 3 IO Control
4. Dashboard Port
The host computer can send simple commands directly to the robot via port 29999. These commands are defined by UR itself, and this function is called the Dashboard. The table below shows the list of commands for the Dashboard.
instruction | describe |
load | Load the program stored in the controller |
get loaded program | Return to the program currently being executed by the robot. |
play | Start the currently loaded program |
stop | Stop the robot's currently executing program. |
pause | Pause the program currently being executed by the robot. |
isProgramSaved | Check if the program currently being executed by the robot has been saved, returning "True" or "False". |
programState | The current running status of the program, returning "PLAYING", "STOPPED", or "PAUSED". |
shutdown | Shut down the robot system |
running | The robot's operating status is indicated by returning either "True" or "False". |
robotmode | Access Robot Mode |
popup | A dialog box pops up in Polyscope. |
close popup | Close dialog box |
addToLog | Add the message to the logfile |
setUserRole | Set user permissions |
polyscopeVersion | Returns the current version number of Polyscope. |
power on | Power on the robot body |
power off | Power off the robot body |
brake release | Release brake |
safetymode | Return to the robot's current safe mode state. |
Table 3 Dashboard Command List
Obviously, we can remotely switch and load programs using some dashboard commands, and we can also start, pause, and stop programs, so that the host computer can remotely control the programs.
5. Host computer programming port
UR robots offer three programming methods: Polyscope programming, script programming, and C-API programming. Polyscope programming involves editing the program on the teach pendant, which the robot then executes; this is the UI-level programming method. C-API programming is a development-level programming method. We will focus on script programming, using URScript, a language developed by UR based on Python. URScript is the programming language for controlling the robot at the script level. Like other programming languages, it has variable types, syntax structures, methods, etc. Additionally, it has a series of dedicated methods to control robot movement and I/O states.
The UR robot's controller runs on a Mini-ITX PC. Once the PC starts the robot controller (like starting a service), the Polyscope software establishes a connection with the robot controller through the PC's local TCP/IP port. Similarly, when the host computer acts as a client, it establishes a TCP/IP connection with the robot controller through a specific programming port (30001, 30002, or 30003). This allows us to write scripts in the URScript language on the host computer and send them directly to the robot controller, which can then execute the program.
Based on the robot scripting principles described above, I can create the following interface on the host computer to remotely program the UR robot.
Figure 4 Script programming
6. Real-time feedback port
In addition to being used for remote programming, 30001, 30002, and 30003 have other functions, as shown in the table below.
port | name | Function |
30001 | First client port | The client can send script code to the server; the server automatically returns robot status and supplementary messages to the client at a frequency of 5Hz. |
30002 | Second client port | The client can send script code via a secure file transfer protocol; the server automatically returns robot status and messages to the client at a frequency of 5Hz. |
30003 | Real-time feedback port | The client can send script code via a secure file transfer protocol; the server automatically returns robot status and messages to the client at a frequency of 125Hz. |
Table 4 Programming Port
Another common feature of these three ports is that once the client opens the port, it will receive messages from the robot at a certain frequency. It's important to note that port 30003 is a real-time feedback port; the client receives a message from the robot every 8ms. Additionally, testing showed that clients using ports 30001 and 30002 only receive messages from the robot approximately every 200ms.
In fact, the robot information received by the client through these three ports is slightly different. The information received through port 30003 is the most comprehensive, including the information received through port 30002 and most of the information received through port 30001.
Therefore, receiving robot information through the real-time feedback port is the most efficient and comprehensive method for the client. Each data packet received through the real-time feedback port is 1044 bytes, arranged in a standard format. Note that in rare cases, the client may receive fewer than 1044 bytes, but the byte arrangement remains unchanged. The table below shows the 1044-byte sequence.
byte order | content |
1-4 | Number of bytes in the entire data packet |
5-12 | Controller power-on time, power-off reset. |
13-444 | Joint target position, velocity, acceleration, current, torque; actual position, velocity, current; control current. |
445-684 | TCP position, velocity, and force; 0 target position and velocity. |
685-692 | Input bit status |
693-740 | Motor temperature |
740-748 | Program scan time |
749-756 | reserve |
757-820 | Robot Mode, Joint Mode, Safety Mode |
821-868 | reserve |
869-892 | TCP Acceleration |
893-940 | reserve |
941-948 | Speed ratio |
949-956 | Robot's current momentum value |
957-972 | reserve |
973-996 | Control board voltage, robot voltage, robot current |
997-1044 | Joint voltage |
Table 5 Real-time Feedback Data Packets
With this data, the host computer can display a wealth of information. Below are two screenshots of the host computer interface: the "animated graph" shows the joint position and TCP position; the "initialization graph" shows the joint mode, actual joint current, joint voltage, and other data.
Figure 5 Animated GIF
Figure 6 Initialization diagram
7. Conclusion
In summary, the robot acts as a Modbus TCP server, and the host computer can control all of the robot's I/O through port 502; the host computer can remotely download programs to the robot through ports 30001, 30002, or 30003; the host computer can remotely control the program's running status through port 29999; and the host computer can obtain real-time status information about the robot through port 30003. In other words, by utilizing the TCP/IP-based ports open on the UR robot, one can create their own Polyscope software to achieve remote control from the host computer.
