Posts by ArthurWong

For anyone who may face the same issue as mine, I would like to summarize my mistakes for your information:

Regarding the error "Signal flow (running): Object ETHERNET 1 returns error RSITimeout" there are two causes, one is the Ethernet communication isn't set up correctly, the other is the IPOC tag.

1. Port number: I used the same port number for server and message sent to client (robot) by the server, which is wrong. The port number of client can be defined, but in this case it is automatically allocated by robot itself, and it is not 59152. A naive mistake.

2. IPOC: I guess this IPOC tag in xml file is used as timestamp. In the packets back and forward between example Testserver.exe and robot, they have the same IPOC number. (I guess) With some level of tolerance, a same IPOC number should be sent back to robot within 100 cycles, otherwise this RSI timeout error happens.

3. xml.etree.ElementTree: the functions from this library needs some time to execute, be caution of timing.

and the following is my UDP server code:

import socket
import os
import time
import xml.etree.ElementTree as ET
count = 0
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server_addr = ('192.168.1.1',59152)
s.bind(server_addr)

print('Bind UDP on 59152...')
cnt=0
timestamp=0
output='<Sen Type="ImFree"><EStr>Message from RSI TestServer</EStr><Tech T21="1.09" T22="2.08" T23="3.07" T24="4.06" T25="5.05" T26="6.04" T27="7.03" T28="8.02" T29="9.01" T210="10.00" /><RKorr X="0.000" Y="1.0000" Z="0.0000" A="0.0000" B="0.0000" C="0.0000" /><DiO>125</DiO><IPOC>'+str(timestamp)+'</IPOC></Sen>'
while True:
    data, client_addr = s.recvfrom(1024)
    if cnt==0:
        
        f = open("input1.xml", 'wb')
        f.write(data)
        f.close()
        input = ET.parse("input1.xml")
        in_root = input.getroot()
        for ipoc in in_root.iter('IPOC'):
            timestamp=ipoc.text
    else: 
        timestamp=str(int(timestamp)+4)
        output='<Sen Type="ImFree"><EStr>Message from RSI TestServer</EStr><Tech T21="1.09" T22="2.08" T23="3.07" T24="4.06" T25="5.05" T26="6.04" T27="7.03" T28="8.02" T29="9.01" T210="10.00" /><RKorr X="0.000" Y="0.0000" Z="0.0000" A="0.0000" B="0.0100" C="0.0000" /><DiO>125</DiO><IPOC>'+str(timestamp)+'</IPOC></Sen>'
    cnt=cnt+1
    print(client_addr)
    s.sendto(output.encode(),client_addr)

Quote from SkyeFire

For any RSI project, adding a Monitor object and capturing the data from inside RSI is crucial to debugging.

I would recommend using WireShark or something similar to check exactly what is being sent to the robot. Tiny formatting errors can be fatal.

Before attempting motion control, I would suggest trying an RSI program that just receives some data from your server and echoes it back. Isolate the motion issue from the communications issue.

Hi Skyfire,

Thank you so much for your advice, they are really helpful. Using wireshark I am able to analyze what is the exact process of UDP communication. Finally I got me bugs fixed, now my server can be used to control robot! Appreicate it!

bests,

Arthur Wong

Quote from huythai

Hi Wong!

I also did a similar project as you are doing but with C# language (So I can not consult you with PYTHON :D)

External Content www.youtube.com

Content embedded from external sources will not be displayed without your consent.

Display all external content

Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

I would recommend you first to use Hercules as an intermediate level to check for both connections from the robot and PC, not directly from the PC-python app to robot RSI because It would be difficult for debugging

Next, just make sure the network transmission frames are in order of receiver and sender sockets (an example is in the picture)

Hope it helps.

BR,

Quang Huy

Display More

Hi Quang,

Thank you so much for your advice. I was really inspired that there is a software to check connection detail. Finally I make my own program working!

Your project looks quiet fun, what's that for? Using joystick to control robot?

bests,

Arthur Wong

Dear all,

My robot is kuka KR6-R900, with KRC4 compact and KSS 8.6.6. The version of RSI is 4.0.

I am trying to connect an external PC to my robot to achieve real time motion control. Right now I am basically following the RSI_Ethernet example in the manual while I developed a UDP server in Python 3.9 to imitate the function of Testserver.exe.

Testing with Testserver.exe is good, I am able to acquire signal and command movement. However, using my own UDP server, I am able to receive xml message from robot but send command to robot. So I guess the ethernet configuration and UDP connection are alright. What happens is RSI will stop in few seconds after the execution of "RSI_MOVECORR()", and pops out "stop by $CORRECTION function (reset or block selection required)" and "Signal flow (running): Object ETHERNET 1 returns error RSITimeout". Meanwhile my UDP server will terminate after receiving several xml message from robot.

I guess the possible cause is either the robot address is set wrong in my UDP server, or the XML format is incorrect. I put effort on checking everything but haven't sort this problem out yet. Any advice from you is appreciated!

My Ethernet configuration:

robot side:

IP: 192.168.1.2 (RSI, virtual 6)

subnet: 255.255.255.0

(I forget other settings but they are default)

external PC side:

IP 192.168.1.1

submnet prefix length 24

gateway 192.168.1.2

DNS 8.8.8.8/ 8.8.4.4

XML message from robot:

<Rob Type="KUKA">
<RIst X="445.0" Y="0.0" Z="790.0" A="180.0" B="0.0" C="180.0"/>
<RSol X="445.0" Y="0.0" Z="790.0" A="180.0" B="0.0" C="180.0"/>
<Delay D="0"/>
<Tech C11="0.0" C12="0.0" C13="0.0" C14="0.0" C15="0.0" C16="0.0"  C17="0.0" C18="0.0" C19="0.0" C110="0.0"/>
<DiL>0</DiL><Digout o1="0" o2="0" o3="0"/>
<Source1>0.0</Source1>
<IPOC>29106442</IPOC>
</Rob>

XML message sent to robot from external PC:

<Sen Type="ImFree">
<EStr>Message from RSI TestServer</EStr>
<Tech T21="1.09" T22="2.08" T23="3.07" T24="4.06" T25="5.05" T26="6.04" T27="7.03" T28="8.02" T29="9.01" T210="10.00" />
<RKorr X="0.000" Y="1.0000" Z="0.0000" A="0.0000" B="0.0000" C="0.0000" />
<DiO>125</DiO>
<IPOC>53189046</IPOC>
</Sen>

UDP server code (Python 3.9):

import socket
import os
import time
import xml.etree.ElementTree as ET


# bind UDP socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

#my local IP of external PC is set to 192.168.1.1, same as defined in RSI_Config.xml
# submnet prefix length 24, gateway 192.168.1.2, DNS 8.8.8.8/ 8.8.4.4
server_addr = ('192.168.1.1',59152)
s.bind(server_addr)
print('Bind UDP on 59152...')

# count bytes
cnt=0

while True:
    #receive xml file from robot
    data, client_addr = s.recvfrom(1024)

    # record initial IPOC number from robot
    if cnt==0:
        
        #record received xml from robot into a file
        f = open("input1.xml", 'wb')
        f.write(data)
        f.close()

        # find IPOC tag
        input = ET.parse("input1.xml")
        in_root = input.getroot()

        # get IPOC value
        for ipoc in in_root.iter('IPOC'):
            timestamp=ipoc.text
        print(timestamp)
        timestamp=str(int(timestamp)+4+cnt*4)
        print(timestamp)

        # prepare xml sent from extenal PC to robot
        output=ET.parse('output.xml')
        out_root=output.getroot()

        # change IPOC in output xml
        for ipoc in out_root.iter('IPOC'):
            ipoc.text=timestamp
        output.write('output1.xml')

        #send prepared xml file 
        filename = "output1.xml"
        J = open(filename,'rb')
        client_addr = ('192.168.1.2',59152)
        data = J.read(1024)
        s.sendto(data,client_addr)

    # starting from the second file received from robot, no longer record xml file
    # only calculate timestamp at interval of 4ms
    else:
        print(cnt)
        timestamp=str(int(timestamp)+4+cnt*4)

        # prepare xml sent from extenal PC to robot
        output=ET.parse('output.xml')
        out_root=output.getroot()

        # change IPOC in output xml
        for ipoc in out_root.iter('IPOC'):
            ipoc.text=timestamp
        output.write('output1.xml')

        #send prepared xml file 
        filename = "output1.xml"
        J = open(filename,'rb')
        client_addr = ('192.168.1.2',59152)
        data = J.read(1024)
        s.sendto(data,client_addr)


    cnt=cnt+1

Quote from Fubini

I am not suprised that KUKA is not willing to share these info. This is usually treated as company secret by KUKA. I know in the past there have been shared projects between KUKA and other companies or university partners where these data was handed out. Usually the external partner than had to sign a non disclosure agreement. Also in these projects the initiative usually came from KUKA itself by funding e.g. a joint project. So probably you will not have a chance to get the info. As a former long time R&D developer for KUKA dynamics system and trajectory planning algorithms I know this data by heart, but I am also bound by a non disclosure agreement.

Thanks a lot for providing this information Fubini. If it doesnt violate your non-disclosure agreement, could you please tell me whether the inertia parameter calculated from CAD is close to their true value by any chance?

I have already realized that KUKA (or maybe any commerical industrial robot) works well on industrial but is not friendly to research facility... sigh

Quote from Fubini

Kinematics data including link lengths is stored in:

$ROBROOT, $TIRORO, $TX3P3, $TFLWP, $DH_4, $DH_5, $LENGTH_A and $LENGTH_B

inside R1/$machine.dat.

Your other question is not as easy to answer. You would have to consider a few additional informations on how the KRC thinks inside. There is no direct simple way of differentiating between before and after gears. You would have e.g. also consider with or without elasticity compensation, with or without coupling, ... . Basically you need knowledge how KRC handles data inside. These details usually are not publically available and you would have to contact KUKA on details. Yes it can be done if you know how to, but I would strongly recommend not to do so. It will take a lot of effort. Why not using the KUKA solution LDD (LoadDataDetermination) if you want to identify tool data inertia. On the other hand if you wand to identify the robots axis inertias, you can find them inside R1/$robcor.dat but still you would need to know how to interpret these numbers (e.g. units) and how they are applied in KUKAs internal dynamic model.

Fubini

Display More

Hi Fubini,

I have inquired KUKA FOCUS CENTER in usa about the meaning of inertia parameters in $robcor.dat, and they replied me today that this is the information they are not able to give. Could you please share your experience of how to get this information? Many thanks.

bests

Quote from MOM

a simple way to figure out the dh-parameter:

where did you get your d1 from (0.1803). Hermanns drawing shows 400mm.

I your T1 you used the correct values for sin(alpha1) and cos(alpha1).

Hi “MOM”, thanks to your and Hermanns’s help, I figured out where I was wrong. Right now my T06 is same as KUKA’s calculated TCP value.

I was wrong in three aspects:

• For d1 I used 180.3 rather than 400. I derived 180.3 from CAD file, and I think this is the height of movable components of link 1 excluding the base height. 400 includes both moveable components and base height.
• In A3 I forgot the 25 mm length in along y axis in local coordinate 3.
• My previous A4 mastering on robot wasn’t correct. It has 90 deg deviation.

The correct link length of KUKA KR6R900-2:

a1=25 d1=400

a2=455

a3=205 b3=25(along y axis in local coordinate 3)

d4=215

a5=67

d6=23

and regarding the transformation matrix T06, it is not strictly necessary to follow DH-convention. As long as each local coordinate system is constructed following right hand rule, same TCP can be derived from any transformation matrix. In my case, I set up local coordinate system in each joint, and transformation matrix from i+1 to i is x,y,z of i+1 coordinate expressed with respect to i coordinate system, and displacement of origin of i+1 coordinate with respect to i coordinate system.

Results:

T06 code:

clear
clc

%q=deg2rad([0 90 90 90 0 0]);%kuka pose: 0 -90 0 90 0 0
q=deg2rad([0 90 0 90 0 0]);%kuka pose: 0 -90 90 90 0 0

a1=0.025;
d1=0.1803;

a2=0.455;

a3=0.205;

d4=0.215;

a5=0.067;

d6=0.023;

T1=[cos(q(1))  0  sin(q(1))  a1*cos(q(1));
    sin(q(1))  0  -cos(q(1)) a1*sin(q(1));
    0          1       0     d1;
    0          0       0     1];

T2=[cos(q(2)) -sin(q(2)) 0 a2*cos(q(2));
    sin(q(2))  cos(q(2)) 0 a2*sin(q(2));
    0              0     1 0;
    0              0     0 1];

T3=[cos(q(3)) 0 sin(q(3))  a3*sin(q(3));
    sin(q(3)) 0 -cos(q(3)) a3*-cos(q(3));
    0         1  0          0;
    0         0  0          1];

T4=[cos(q(4)) 0 sin(q(4))    0;
    sin(q(4)) 0 -cos(q(4))   0;
    0         1   0         d4;
    0         0   0          1];

T5=[cos(q(5)) 0 -sin(q(5))  a5*-sin(q(5));
    sin(q(5)) 0 cos(q(5))   a5*cos(q(5));
    0       -1  0           0;
    0       0   0           1];

T6=[cos(q(6)) -sin(q(6)) 0  0;
    sin(q(6))  cos(q(6)) 0  0;
    0           0        1  d6;
    0           0        0  1];

T06=T1*T2*T3*T4*T5*T6

Quote from MOM

In post #7 you will see the correct data for the robot and your numbers do not match (maybe you used the data of the maximum workspace instead of the the link parameter)

The importent data were also mentioned by Fubini in post #2 (besides $DH_4, $DH_5 - these values depends which way your are doing the forward transformation)

Normal doing a forward transformation:

draw the robot in a xz- coordinate system all axes set to 0° (even if robot cannot move to this position)

define all the coordinate system for the different axes (z is the rotation axis)

define which dh transformation you want to follow

- dh transformation introduced by Denavit and Hartenberg (DH)

- dh transformation introduced by Craig (DHm)

depending on that define the dh parameter and calculate the dh transformation using these parameters

that's it so far

looking forward to get your example

Display More

Hi “MOM”, here is my example, sorry for the long delay. I have double checked our type, it is KR6R900-2. I also make sure $base and $tool are set to 0.

This is the coordinate system I used, which is slightly different from KUKA’s, thus for the same configuration, my angular expression is slightly different from KUKA.

LInk parameters I used:

a1=25 d1=180.3

a2=455

a3=205

d4=215

a5=67

d6=23

see my next post for code and results

Quote from MOM

so why you are not telling the correct parameters?

could be helpful for others too

I didnt find out which parameter is wrong yet. And you are right about WCP calculation from my T06 is wrong. I didnt figure out whether it was wrong robot type, while my link parameter input was wrong anyway.

our robot type is KUKAKR6R900-2 if my memory is correct.

the link length I use is from CAD file:

a1=25 d1=180.3

a2=455 d2=4.5

a3=205 d3=-4.5

a4=3.25 d4=215

a5=67 d5=-3.25

d6=23

I know from the current stage it is a little bit confusing as I didnt define my coordinate system. I will make it clean in the coming example

Quote from MOM

in which post '?

#11

"No the error is actually in x, y and z, around 30 mm, varying case by case. So I highly suspect it was the problem of the link length I input."

Quote from MOM

my very lastpost to your question

you actually can see that in post #7

two parameters are different (you probably could figure that out - probably not).

I did not compare between my calculation and robot calculation - I compared my calculation using two different robots.

And I know my calculation is correct and therefore your calculation is wrong

the reason whay they are differences in x, y and z is simply using the wrong WCP

no more comments

Display More

I appreciate your help indeed sir, while I have to clarify:

• I didn’t blame anyone
• My lab was shut down for maintenance, why are you so pushing? Would it bother you if my example is delayed?
• Your psychological predication/assumption is opposite
• I always admit it was my calculation mistake not KUKA’s, and I know the link parameter I input was wrong. The purpose for this post is finding the correct one.

Quote from MOM

This test is done in 5 minutes , so where is the time saving?

I was refering to link length identification. you may compare the difference between your T06 and robot calculated Cartesian position, but you can't find which link parameter input to T06 is wrong and what are their correct value from only one set of data.

Quote from Fubini

The error is where exactly? Position values correct and permuted? Then some orientation is missing.

Is the error some constant in one coordinate? If yes search $machine.dat for this value. You probably have forgotten a frame. A hot candidate usually is $TFLWP which brings an additional shift and orientation change from the intersection point of A4,A5,A6 to the flange plate.

What are your $TOOL and $BASE? To only get the robot these should be $NULLFRAME both?

...

As MOM said an example specifying axis values and corresponding cartesian values of both trafo could be useful. But do not forget to specify all other influencing values like Tool and Base as well.

Fubini

Display More

No the error is actually in x, y and z, around 30 mm, varying case by case. So I highly suspect it was the problem of the link length I input.

I didn't touch $TOOL and $BASE. I will double check whether they are null. I will post an example.

Quote from MOM

ok I checked the ALLMADA directory

My link parameters are from CAD file. looks similar to this table. I will double check.

Also I will post my file and robot calculation as soon as I am available.

Quote from MOM

so choose the right documentation for your robot to get the correct link length.

I am using the correct link length from the right documentation, which gives me a different T06 from what robot itself calculates.

Quote from MOM

set the values to specific axes value and save the the cartesion positions

(e.g. set A5 to 0.0 => cart position, then set A5 to 90.0 => difference will tell you the length of the distance between T06 and WCP)

That is equivalent to collecting data + nonlinear optimization + plenty of debugging time. I just want to save my time and cut the corner.

Quote from Fubini

Kinematics data including link lengths is stored in:

$ROBROOT, $TIRORO, $TX3P3, $TFLWP, $DH_4, $DH_5, $LENGTH_A and $LENGTH_B

inside R1/$machine.dat.

Your other question is not as easy to answer. You would have to consider a few additional informations on how the KRC thinks inside. There is no direct simple way of differentiating between before and after gears. You would have e.g. also consider with or without elasticity compensation, with or without coupling, ... . Basically you need knowledge how KRC handles data inside. These details usually are not publically available and you would have to contact KUKA on details. Yes it can be done if you know how to, but I would strongly recommend not to do so. It will take a lot of effort. Why not using the KUKA solution LDD (LoadDataDetermination) if you want to identify tool data inertia. On the other hand if you wand to identify the robots axis inertias, you can find them inside R1/$robcor.dat but still you would need to know how to interpret these numbers (e.g. units) and how they are applied in KUKAs internal dynamic model.

Fubini

Display More

Thank you Fubini, that's really really helpful!!! Link inertia identification is actually a part of my research so there is no way around it. You showed me a perfect start point from where I will move forward. Thanks a lot!

Quote from MOM

there are a few ways:

have you checked simulink?

developing a base system application, like RSI or OccuBot without any help from kuka

you will not be able to handle any if your ideas

Thank you "MOM" for all of your help. we are at the very very early stage of research. While KUKA Focus center starts to ignore my questions.... Perhaps I need to check whether we have purchased support package or not.

Quote from SkyeFire

Yeah, the FRI interface on the iiWA is the one that was made for research purposes. Of course, the iiWA is very much a researcher's robot, too. (with a $$$ to match!)

Yea I start to regret we bought the KUKA KR6. Although this order was directed by my supervisor, I am the one suffering inconvinence...

Quote from SkyeFire

RSI connects your real-time motion command into the robot's motion control at a much deeper level than KRL. But it doesn't bypass all of the path/motion planning engine.

Thank you so much SkyeFire, for your detailed response. We don't plan to bypass all of the trajectroy engine, but we would like to change the command sent to PID controller. That is something possible right?