Usage of .xml , .urp and .script files for RTDE control

Technical Questions URScript
1

Hi everone,
I am currently trying to understand the RTDE communication to receive and send messages via Simulink’s socket communication.
In this process I stumbled over several data types namely .urp, .xml and .script files.

In the RTDE guide (Real-Time Data Exchange (RTDE) Guide - 22229) both an .xml file for defining transmission data and a .urp file are given.
Later, I found the ur_rtde cpp interface and a .script file (scripts · master · SDU Robotics / ur_rtde · GitLab) that is defining soem functions and even running a loop to read and write reisters.

I’d like to know the difference between these three data types, since the cpp interface seems to be working without .urp and .xml file and the RTDE guide does not mention a .scrip file.

For now I believe, that the .urp file somehow represents the GUI of the Teach Pendant and that the .scrip file does the same thing but not in a GUI kind of way. For the .xml file I haven’t found any hint on how to use it.

Thanks in advance and kind regards,
Max

1 Like
2

Hi Max,

The .xml file as you mentioned is our recipe file: it defines what inputs and outputs you’d like to transmit along with their respective data types (ints, floats, vector6d’s, etc.). A .urp file is a Polyscope program file that you can load on the robot. In the case of the RTDE example, it simply has the robot move between two waypoints whose values are being streamed via RTDE and the robot’s registers. If you wanted to play the “example control loop” sample in the zip file at the bottom of the RTDE Guide page you would need three things: “example_control_loop.py” and its associated modules, “control_loop_configuration.xml”, and “rtde_control_loop.urp” loaded on the robot. You would play the Python file first, followed by playing the robot program.

When you play a Polyscope program (.urp), a .script file gets generated and that is what the controller actually executes. I am not as familiar with the C++ library as it’s a third-party interface, but it looks like there is a comprehensive amount of code written to accomplish similar tasks to what you would want to do with the base RTDE interface (with the added bonus of a chunk of functions already written out).

1 Like
3

Thank you very much for summarizing the relationship between .urp and …script file. That was very helpful and good to know.

Since the .xml recipes and the .urp/.xml files are not closely related to each other, I think that I understood these too. My question to this would still be, where to place these recipes. They have to be running on the polyscope somehow, but where will they be executed?

Lastly I’d like to understand your following statement:

Blockquote

How do you remotely read/write registers via RTDE? I found the suitable script commands to do such operations, but it does not work when I try to send it while another program is running. Does the .script or .urp has to define an operation “await command”, or can you simply send ascii commands like “write_output_integer_reg(0,1)” for setting the corresponding register 0 to value =1 while a different program is running on the controller?

4

Okay, so there are two different sides to run these examples: the robot side and the PC side which is physically connected to the robot via an Ethernet cable. On the PC side, you have the .xml file which configures which RTDE inputs and outputs you want to utilize. In order to send a pose to the robot, you need to send it 6 different float values which in the example are under the key “setp” in the .xml:
rtde_setp

Additionally on the PC side you need to run a Python file called “example_control_loop.py” which will send those values to the robot’s double, or float, registers. Once you run the Python program, you can switch over to the robot teachpendant and play the program (.urp) “rtde_control_loop.urp”. There is some code in there which will read the float registers and combine them into a variable waypoint that the robot then moves to. In this case you are not manually reading the registers, the robot has a Thread which is constantly doing so.

So to summarize:

  1. Unzip the file at the bottom of the RTDE guide.
  2. Load the “rtde_control_loop.urp” onto your robot and connect it to your PC via an Ethernet cable.
  3. Open the “example_control_loop.py” file via your favorite Python IDE (Pycharms, IDLE, Spyder, etc.)
  4. Edit the .py file and change the IP address to match your robots (you can set this in Polyscope by going to the Hamburger menu → Settings → System → Network. It’s recommended to set a static IP address.
  5. Play the Python file.
  6. Play the robot program.
2 Likes
5

And again thank you very much for such a detailed answer. I was simply not familiar with the .xml functionality, execution and concrete influence on the communication in terms of reading/writing registers. But you made that very clear to me.

I will still look this up a little bit further before starting with the examples to try understanding this better.

Good evening for you.

Best regards,
Max

6

Any time! Please feel free to reply to this post or create a new topic if you have any additional questions.

3 Likes
7

I still have a few last questions that might be a little bit off topic but follow the conclusion I drew from this conversation about the .xml file and the recipes. Please inform me if I shall open up a new topic for this, so that others may find this conversation more easily:

Conclusion to .xml file
By now I understood, that the .xml file is just a way to store and read the content of the recipe messages in a simple way and is kind of exclusive for Python because there exist libraries that help extract the information stored inside of the .xml file.
This means, that one can construct the data packages corresponding to the recipes for setting up RTDE by hand and simply send them without the need of an actual .xml file. But of course this will not be as readable for a human as a .xml file is.
This conclusion brings me to the following off topic questions:

Off Topic:
How does an actual conversation between remote laptop and robot via RTDE look like on a bit-like level?
From the RTDE guide I know, that each message has a header containing the package type and the package length (which is the message length + 3 bytes for the header elements itself if I am correct?). Then follows the message depending on the requested package type. For a conversation this could look like this:

  • Phase 1: initialize RTDE: Here will be the initial messages that will be sent once or for the start and pause command even multiple times:

    1. RTDE_REQUEST_PROTOCOL_VERSION to request to talk with the robot in a specific protocol version (e.g. 2)
    2. RTDE_CONTROL_PACKAGE_SETUP_OUTPUTS here all the requested outputs (the recipes) will be sent once.
    3. RTDE_CONTROL_PACKAGE_SETUP_INPUTS same goes for the input recipes
    4. RTDE_CONTROL_PACKAGE_START telling the robot to await commands
    5. RTDE_CONTROL_PACKAGE_PAUSE telling the robot to stop accepting commands

  • Phase 2: Sending control commands

    1. RTDE_TEXT_MESSAGE somehow read/write operations to the registers will be done here?

  • Is my understanding so far correct?

  • There are different data types inside of the message. How will different data types be sent as one package? Will each part of the message be casted to a string and packed to a string array?

    • Message 1: 5V2 (Package length = 5bytes for uint16_t + uint8_t + uint16_t, V = request protocol version, 2 = version 2)
    • Message 2: 46Iinput_int_register_24,input_int_register_25
    • I don’t know how to pack this to one message, but could this be the content?

  • How would a control message to change input_int_register_24 to a value e.g 12 look like?

Thank you in advance

8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.