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
Simulink for real-time control of a robot via TCP/IP
25 次查看(过去 30 天)
显示 更早的评论
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
- 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.
- 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?
- 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
- 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
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/663410/image.png)
2. Setup of the "Packet" Blocks. Here with static lengths for the first initial message
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/663415/image.png)
3. Packet rejection when using "Packet" blocks in external mode
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/663420/image.png)
Thank you in advance for every hint you can give me.
Best regards,
Max
4 个评论
rothTransform
2022-11-18
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?
回答(1 个)
Diego Kuratli
2024-1-10
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.
0 个评论
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Development Computer Setup 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!