Simulink for real-time control of a robot via TCP/IP

18 views (last 30 days)
I am working with the UR10e robotic arm from Universal Robots. The robot has a static IP address and the manufacturer provides a TCP/IP interface for sending control commands (like joint positions, velocities etc.) and receiving desired status updates of the robot (actual poses, inverse kinematics, timestamps etc.).
This interface is located on a specific port of the robot and requires some initial messages to set up a desired conversation between server and client (tells the robot what message to send, defines frequencies and prepares the robot for input messages). Due to this, the client (local computer in the network) has to send the initial messages through the same port that it uses later for the whole communication (Send data on port A, receive data on port A).
With the great code-generation feature of Simulink and the large amount of control options, I would like to set up this TCP/IP control in Simulink on my computer.
I therefore need Simulink to run in a real-time mode and have it read the TCP/IP input in each iteration step and send a TCP/IP message in each iteration step.
I shortly after stumbled over this explaination , and since I do not have any remote computer for using the actual Real-Time environment, the Real-Time Desktop environments seemed to be the best solution for my purpose.
The Normal Mode, Accelerator Mode or External Mode provide the required real time options for the control and communication while still acting on my local machine. But since both Normal and Accelerator mode can not guarantee 100% real time, only external mode does fulfill the requirements for real time and code generation, where the code is running on my windows real time kernel with which Simulink interacts.
The TCP/IP blocks of the Instrument Controlbox library ("TCP/IP Send" and "TCP/IP Receive") and the TCP blocks of the Simulink Real-Time / IP library ("TCP CLient", "TCP Send" and "TCP Receive") are not compatible with code generation and therefore don't work with external mode (see image below).
The Simulink Desktop Real-Time library is designed for the normal, accelerator and external mode, but for some reason the TCP/IP connection,for which I am using the "Packet Output" and "Packet Input" blocks, gets a RST response from the robot indicating a failed communication (see image below).
Yet another problem with the "Packet Output" and "Packet Input" blocks is that the initial messages are in the range of 3 to 250bytes, while the actual conversation uses static message lengths of 52bytes (receive) in 500Hz and 104bytes (send). It seems that variable message lengths are not suported by the "Packet" blocks
  1. Regarding the external mode approach with the "Packet Output" and "Packet Input" blocks: Why am I getting rejected by the robot? Did I set up the packet blocks wrong?
EDIT: I had simply made a mistake while defining the Port on the host device: Instead of 30004, i entered 300004. Now it is responding correctly.
  1. Regarding the external mode approach with the "Packet Output" and "Packet Input": Is there a way to implement variable package lengths for the receive and send option?
  2. Generally speaking: is this approach meant to fail and if yes, are there other options for me? Can I fix the previous TCP/IP or TCP approach?
  1. Code generation of TCP blocks which worked in normal simulation and were able to handle variable message lengths due to the "Length" port in the send and receive block
2. Setup of the "Packet" Blocks. Here with static lengths for the first initial message
3. Packet rejection when using "Packet" blocks in external mode
Thank you in advance for every hint you can give me.
Best regards,
rothTransform on 18 Nov 2022
I have the same issue, but I am implemeting it on a Speedgoat and doing it in real time (problem somewhat reversed as yours - I'm implmenting the "robot" side of the communication) - the lack of a number of bytes on a receive is a major issue!
I've been looking at the TLC blocks that create the code for the RT application, and it appears possible to change this behavior and add another port, but it has proved to be very difficult to get all the dependancies and parts togeter to go down that route and not sure if it is the best approach?
Have you been able to figure anything out on your end?

Sign in to comment.

Answers (0)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!