issue between simulation and reality

Started by ludo, September 22, 2023, 04:31:04 PM

Previous topic - Next topic

ludo

Hello,
i have an issue between simulation and the real movements.
I am facing tese issue for some definition not all.

simulation
https://drive.google.com/open?id=1gR7mjL9XNNY0GFw4IRproj0MXroRjYVx&usp=drive_fs

reality
https://drive.google.com/open?id=1gA8Mn_MLw4n2w8hBn0mjEaU2AbntNvem&usp=drive_fs


A long time ago (2015) you said to check the status and turn.
I use stauts "As start" and I use Only linear and axis movement.
The Axis movemet is use to "unroll" the axis and reach a safe position when the External axis turn.

Is there a menu to check the status and turn on the robot side / Controller KRC4?

Thanks
Ludovic

Johannes @ Robots in Architecture

Hello,

I looked through the video and it looks like at the beginning with the external axis at 0 everything is fine, but then it starts to differ. Did you calibrate the base as an Offset Base, or as a regular base?

Best,
Johannes

ludo

Hello,
 i Measure the turntable, and set it as a "cinematic couple"  Screen capture "Externalaxis.jpg"

https://drive.google.com/open?id=1glc87IdV-Q7W1Y9Qhi7i-aHtnmjyDO-6&usp=drive_fs

And i define a base attached to this External axis : screen capture "Rotary base.jpg"


https://drive.google.com/open?id=1ggmKpWvbLkWeGZoSeILtUx4A4vkBGQDx&usp=drive_fs

The simulation is Ok for 5 GH def and the sixth one is not correct.

Johannes @ Robots in Architecture

Hello,

Sorry, I don't know the terminology of KSS in French compared to English and German, so I have to ask again: Did you calibrate the base as an offset base, rather than a normal base?
With an offset base, if you rotate E1 in a Cartesian movement mode, the robot tool will keep its position in relation to the turntable, i.e. it will rotate around the tool axis.

Best,
Johannes

ludo

Hello, sorry I took a screen shot without change the language to be clerly explicit to all the community.

So, yes i set the rotary as a base (base KP1) and set the base (base 4) is an offset to the E1.

Yes,  When in use cartesian move in the base 4 and turn the E1 the TCP is not moving accordingly to the E1 (no relative move form the KP1)  the TCP always pointing a fixed point ine the KP1 and KP1 is turning.

Johannes @ Robots in Architecture

Hello,
I see that your Base 4 is all zero, could you try to calibrate it via 3 points? The resulting values should be in relation to the origin of the turntable (rather than the origin of the robot). So very low numbers if it is close to the root point of the turntable.
Best,
Johannes

ludo

Hello,
At the beginning, I measure set the turntable with a sharp tool and get this.
X : -493
Y : 2854
Z : 1103
A : 36.05   B : -44.9   C : 90.74

Then i create a base attached to the turntable base with a null offset.
The simulation and the robot path are accurate.


Do you say that i must set the turnatble base with
X= Y= Z =0
A= 36.05  B -44.9  C 90.74


And set the base offset
X : -493
Y : 2854
Z : 1103
A=B=C = 0
?

I try it tommorrrow to see if there is a change.
Thanks.
Ludovic

Johannes @ Robots in Architecture

Hello Ludo,

I am worried about the null offset. It would be great if you could calibrate the offset base by three points and see if the values are really close to zero! If the XYZ values are not, then we have something to look into.

Don't do any subtractions/additions, that just ends up in chaos and masks the real issue, if there is one.

Best,
Johannes

ludo

hello,
I measure the base (base N°6) attached to the rotary axis KP1H;

base6andpositioner.jpg
 when i assign this base to the Rotary axis, then the base 6 is offset from the rotary base, For instance, the origine of base 6 in in the center of the KP1H, but when i want to to go 0,0,0 in base 6, My robot fo this :

base6issue.jpg

I guess it could came my misunderstanding of the "External Kinematics Rotary axis" in KUKA PRC Core.?
I join a definition that cause the difference betwen simulation and reality. (tenonforum.gh)


Johannes @ Robots in Architecture

Hello,

The GH file looks plausible, with base 4 at all-zero. However in your screenshot there is a base 6. Was that the measured base (using 3-points)? The values seem to be in relation to the robot-Origin rather than the turntable-Origin.
What KSS version are you running? KUKA changed a few UI things relating to tools and bases.

Best,
Johannes

ludo

hello,
yes the base 6 was measured from the robot $Nullframe. Form the robot origin.

I use KSS8.6.10 and think that in the KSS8.6.10 the coordinate of the base assigned to rotary axis is and offset base, so if base 4 assigned to the rotary axis has all itscoodiante with 0, these base is in the center of the rotary axis with no offset.

Do you think i should use the kuka prc with another value to get coorect simulation. The issue comes when i want to turn the E1  more than 90 degrees and flip plane.

Thanks in adavanc,
If you want more detail and simulation issue, i could do it.


Johannes @ Robots in Architecture

Good Morning,
I should have some time with our Cybertech today, which has got an external axis on KSS 8.7 (being nearly identical to your 8.6).
However I assumed that you were having constant issues, i.e. once the axis leaves E1=0 and the base gets rotated. Is the movement fine below 90 degrees? That would be an important, new factor.
Best,
Johannes

ludo

Good evening :-)

I test again, this program always cause issue.
I attach the GH programm and embeded image of the issue and highlight in a panel  the position that cause problem.

Johannes @ Robots in Architecture

Hello,

Please understand that these things are hard to troubleshoot remotely, so a lot is guesswork.
Just from looking at the code, you are making a seemingly large movement after a toolchange as a LIN - I would try using PTP instead.
On the other hand it seems that you keep the Cartesian position in a similar area but rotate by 150 degrees, so the rotating does not seem that unlikely.

One last comment to the GH file, you marked the panel where you have got a transition of exactly 180 degrees from 270 to 90 degrees. These things are tricky because the robot could choose either direction to get there. Maybe going from 270 to 271 or 269 would help.

Best,
Johannes