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

Hi,

Introduction

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).

Task

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 https://de.mathworks.com/matlabcentral/answers/536647-what-is-the-difference-between-normal-accelerator-and-external-mode-when-using-simulink-desktop-rea , 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.

Problems

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

Questions

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?

Images

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,

Max

[Maximilian Becker]

The more I think about it, the more I am curious why the TCP blockset does not support code generation, when it is originally designed for the Real-Time applications. As such, C code will be generated and transmitted to a a target machine. So in the end, it should be possible to generate C code from TCP blocks in Desktop Real-Time too

[Maximilian Becker]

1. When trying to establish the TCP/IP communication in Simulink Desktop Real-Time External Mode through the "packet" blocks, I still can't resolve the problem of having a fixed message size. Usually the robot reads the first two bytes of a message that contain the length of the whole package such that adding values to the end of the message would not change the message from the robot's point of view (e.g. I can set the default message length to the maximum length of my messages and simply add zeros to all the shorter ones). But for some reason, the generated program from SImulink messes things up and sends the bytes in a differnt order such that the robot responds with error messages.
2. I reduced the Simulink model containing the TCP blocks to a minimum and tried to simply building these TCP blocks. I know get the error message The pre-compiled libraries libslrealtime_libsrc_ip.a_sldrt.lib are missing from the TargetPreCompLibLocation C:\Program Files\MATLAB\R2021a\toolbox\sldrt\lib\win64. but there seems to be no file matching this name and when I try to use Simulink's fix option, Simulink simply closes without further information..

[Maximilian Becker]

Due to the communication protocol with the robot I can set the to-send message size to the maximum number of bytes of my longest message and fill shorter messages up with zeros before sending. This is possible, since the first two bytes of a message declare its length and further bytes will be ignored by the robot.

For incomming messages I still don't know the actual behavior of the Packet input block, but I do believe that it is implemented with a FIFO buffer and soem blocking mode which means, that I can not receive messages of different lengths.

But I am still encountering problems with the Packet input/output blocks in terms of sampling time. Sometimes, the Packet Output block packs multiple messages into one message and even sends wrong messages causing error messages from the robot.

[rothTransform]

Hello,

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?

Answer 1

[Diego Kuratli]

For real-time control of a robot using your PC (without a real-time system such as Speedgoat), Simulink Desktop Real-Time is the appropriate choice.

All the blocks included in Simulink Real-Time are intended to be used on Speedgoat, and the TCP/IP blocks from the Instrument Control Toolbox do not support code generation, and are not designed for Test & Measurement, not for closed-loop control.

To answer your questions:

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?

I would consider using the Stream Input and Stream Output blocks instead. These blocks allow defining a message termination character so that messages with variable length can be sent and received.

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?

The best approach depends on your requirements. If you use a Speedgoat real-time system with Simulink Real-Time you can achieve faster sampling rates for your closed-loop control, and you get more scalable hardware solution.

Simulink Desktop Real-Time is an entry-level alternative that allows quickly connecting to external hardware. For a control loop with TCP/IP communication, sample time of 2ms, and if you do not have hardware deployment requirements, Simulink Desktop Real-Time is a viable option.