Issue sending inputs to RTDE for setup

Technical Questions Robot Communication
1

I am having an issue with a library that I am creating to communicate with the RTDE port. The issue I am having is when setting up inputs. If I send a payload of 6 doubles, input_double_register_0…5 then I never get a reply back from the robot. If I send less than 6 then everything works as it should.

I am using the command for RTDE_CONTROL_PACKAGE_SETUP_INPUTS. Has anyone else had any issue sending packets to the port and not getting a response? When I was sending incorrectly formatted headers I was actually getting a text message back letting me know that there was a problem. In this case we are getting nothing back from the server.

This is a library we are working on in node.js as that is what we use for all of our projects. I have been able to basically replicate the UR provided python libraries and am working through the example-control-loop.py file and this is where I begin to have issues that I cant seem to resolve.

Also, I am currently hitting the simulator running 3.3.1.xxx if that matters.

1 Like
2

Hi Matt,

I’m having difficulty recreating the problem. When I simply extend the control loop example in the following manner it synchronizes without any problems.

Changes:

  • Add in the control_loop_configuration.xml for the setp recipe:
<field name="input_double_register_6" type="DOUBLE"/>
<field name="input_double_register_7" type="DOUBLE"/>
<field name="input_double_register_8" type="DOUBLE"/>
<field name="input_double_register_9" type="DOUBLE"/>
<field name="input_double_register_10" type="DOUBLE"/>
<field name="input_double_register_11" type="DOUBLE"/>
<field name="input_double_register_12" type="DOUBLE"/>
<field name="input_double_register_13" type="DOUBLE"/>
<field name="input_double_register_14" type="DOUBLE"/>
<field name="input_double_register_15" type="DOUBLE"/>
<field name="input_double_register_16" type="DOUBLE"/>
<field name="input_double_register_17" type="DOUBLE"/>
<field name="input_double_register_18" type="DOUBLE"/>
<field name="input_double_register_19" type="DOUBLE"/>
<field name="input_double_register_20" type="DOUBLE"/>
<field name="input_double_register_21" type="DOUBLE"/>
<field name="input_double_register_22" type="DOUBLE"/>
<field name="input_double_register_23" type="DOUBLE"/>
  • Extend the initialization of the “setp” variable in example_control_loop.py:
setp.input_double_register_6 = 6 
setp.input_double_register_7 = 7
setp.input_double_register_8 = 8
setp.input_double_register_9 = 9
setp.input_double_register_10 = 10
setp.input_double_register_11 = 11
setp.input_double_register_12 = 12
setp.input_double_register_13 = 13
setp.input_double_register_14 = 14
setp.input_double_register_15 = 15
setp.input_double_register_16 = 16
setp.input_double_register_17 = 17
setp.input_double_register_18 = 18
setp.input_double_register_19 = 19
setp.input_double_register_20 = 20
setp.input_double_register_21 = 21
setp.input_double_register_22 = 22
setp.input_double_register_23 = 23
  • In PolyScope add a script command node with the following code:
write_output_integer_register(0, 1)
global var_6 = read_input_float_register(6)
global var_23 = read_input_float_register(23)
sync()

Run the example: python example_control_loop.py

In the variables tab you should now see:

var_6 : 6.0
var_23 : 23.0

If you made a (small) mistake in the protocol implementation it might not understand the command (or expect more data) and return nothing (yet). Could you maybe send me the data (semi-raw, if possible), so we can perhaps make a detection for this particular problem?

Best regards,
Robert

1 Like
3

Robert,

Since I am writing this as a node application I have converted the config file to a JSON object as it will not reside locally once I get all of the methods working correctly. The weird part is I can send the output set-up just fine, I am negotiating the protocol version fine, getting the controller version back (another issue, the build version that is returned does not match the “About” version on the simulator but this is with my code or the python example). The other strange thing is if I limit the number of inputs that I send it works just fine, 5 or less no issue, 6 or more I have an issue.

All sends and receives from the RTDE server are using the same methods so not willing to say there is definitely not an issue with the methods but they seem to work fine for all of the other data.

Here is the raw data that I am reading in:
> {“rtde_config”:{

  "state":[
    {"name":"target_q", "type":"VECTOR6D", "title":"Target Joint Position"},
    {"name":"target_qd", "type":"VECTOR6D", "title":"Target Joint Velocities"},
    {"name":"actual_q", "type":"VECTOR6D", "title":"Actual Joint Positions"},
    {"name":"actual_qd", "type":"VECTOR6D", "title":"Actual Joint Velocities"},
    {"name":"actual_TCP_pose", "type":"VECTOR6D", "title":"Actual Tool Position Pose"},
    {"name":"target_TCP_pose", "type":"VECTOR6D", "title":"Target Tool Position Pose"},
    {"name":"robot_status_bits", "type":"UINT32", "title":"Digital Output Status Bits"},
    {"name":"output_int_register_0", "type":"INT32"}
  ],
  "setp":[
    {"name":"input_double_register_0", "type":"DOUBLE"},
    {"name":"input_double_register_1", "type":"DOUBLE"},
    {"name":"input_double_register_2", "type":"DOUBLE"},
    {"name":"input_double_register_3", "type":"DOUBLE"},
    {"name":"input_double_register_4", "type":"DOUBLE"}
  ],
  "watchdog":[{
      "name":"input_int_register_0", "type":"INT32"
    }]
  }
}

Here is an example of the buffer (converted to string) that I am successfully sending for the inputs

zIinput_double_register_0,input_double_register_1,input_double_register_2,input_double_register_3,input_double_register_4

Here is the buffer when I am having an issue by adding another input…

�Iinput_double_register_0,input_double_register_1,input_double_register_2,input_double_register_3,input_double_register_4,input_double_register_5

The size of the total buffer sent (header and payload) is 146 bytes per the length calculation. My concern is that leading character, looks wrong.

I will keep looking at it as well and hope to get this working by the end of the weekend.

Matt

1 Like
4

So I found what is probably the issue but can’t figure out what is going on.

If I calculate the length of the buffer that will be sent to the system when I am sending the 6 variables I get 146 bytes, but I am actually sending 148…Now the weird part is if I run buf.length I get

Heres a code snippet

    console.log('payload:', payload.length)
    let fmt = '>HB'
    let size = struct.calcLength(fmt) + payload.length
    console.log('size:',size)
    let header = [size, cmd]
    let buf = struct.pack(fmt, header) + payload
    console.log('buf:', buf.length)
    console.log('[INFO] Buffer Sent:',buf)
    this.sock.write(buf, 'utf8', (err)=>{
      console.log('[INFO] Bytes written now:', this.sock.bytesWritten-this._bytesWrittenPrevious)
      console.log('[INFO] Total Bytes Written:', this.sock.bytesWritten)
      this._bytesWrittenPrevious = this.sock.bytesWritten

And the output when it works as expected

[INFO] Sending the input setup
payload: 20
size: 23
buf: 23
[INFO] Buffer Sent: Iinput_int_register_0
[INFO] Bytes written now: 23
[INFO] Total Bytes Written: 143

And the output when it is failing

 [INFO] Sending the input setup
 payload: 143
 size: 146
 buf: 146
 [INFO] Buffer Sent: �Iinput_double_register_0,input_double_register_1,input_double_register_2,input_double_register_3,input_double_register_4,input_double_register_5
 [INFO] Bytes written now: 148
 [INFO] Total Bytes Written: 291

Still researching what is going on with the socket write and why I am writing 2 more bytes than what was in the payload

5

Robert,

Found the issue!! It was an encoding issue on the size in the header. Unfortunately the library that I was using that ported the struct functionality from python into nodejs was not encoding the size correctly into the buffer. So anything larger than 127 was not being encoded as a uint16_t which is what the header required so the server didn’t know how to respond, it was probably still waiting on more data or something. I have switched to using the native buffer writing in node (adds a few lines to the code) but its now working as expected with sizes greater than 127 bytes.

Thanks,
Matt

6

Hi Matt,

Great that you found the problem. I was just about to count the characters :wink:

If you face similar problems in the future:

  • Terminals F9-F11 (press ctrl + alt + F9) on the robot sometimes print helpful developer information. Although it is geared towards R&D of course.
  • Wireshark is a great tool for debugging protocol issues.
  • Robert
7

Robert,

So I actually have this running and bringing back state, have not tried setting an input yet but that should be straightforward at this point. We are feeding this into a nodejs program that is controlling the robot with moves. So we are able to get the current position of the TCP and then send in a new move or action. All in nodejs which is pretty cool with its asynchronous behavior and linking into other databases and libraries.

I have another question though about RTDE in general. Is there a way to retrieve the serial number of the robot through the RTDE interface?

Matt

8

Nice, I’m looking forward to see the new applications you can develop with this :slight_smile:

Regarding the serial number. The RTDE is meant for continuously streaming data. Therefore, configuration data, like a serial number, is not made available here. In the future we might extend the interface.

9

Could it be extended to be like getting back the controller version or protocol?

Matthew Bush
Hirebotics
M: ‭(615) 479-6151‬