KR C2 moving in circular motion rather than programmed path

[jschmidt]

Hello!

This is is a bit of an add-on to a previous topic ( http://forum.robotsinarchitecture.org/index.php/topic,817.0.html ), but I am still struggling with the issue of the robot not following it's programmed path. I've attached a video, the Rhino and .gh files, and the final .src file.

Control type: KR C2
Robot type: KR 150 L150
Software Version: KSSV4.1.6

In this video, it shows the flange almost following the LIN movements that the E1 is following, but in the opposite rotation direction. This is instead of following the robot flange path in the simulation.
I have encountered this problem before the integration of the A7 axis as well. At that time, I was trying to mill a curved surface out of a piece of foam, and I initially just gave KUKA|prc contours to vertically move between and mill. When running the program, the flange did a very similar circular movement to the one in the video, rather than its simulated motion. I solved this problem by connecting the contours of the curved surface into one closed polyline, so that the flange just simply had to trace the path (creating a toolpath essentially) and that solved the problem.

I don't really see how it would be a KUKA|prc issue - because the KUKA Core Analysis is all clear - but I'm posting just to get another check that it is not an issue of the .src file that I am inputting.
- I've gone through all of the variables in the machine.dat and made sure that it was the correct machine.dat for the robot type (ref http://forum.robotsinarchitecture.org/index.php/topic,511.0.html)
- To the best of my knowledge, A7 is configured correctly.
- The tool is XYZABC calibrated and the same XYZABC values are entered in KUKA|prc and on the robot.
- Robot is mastered with EMT and A7 is mastered with a dial.
- Root Point data for the A7 was entered numerically by positioning the TCP of the reference tool at the center of rotation and displaying $POS_ACT, and then entering in those values for the Root Point.

Any ideas are appreciated and welcome!

[Johannes @ Robots in Architecture]

Hello,

I think the issue is that your turntable axis is facing the opposite direction of what KUKA|prc is expecting. So you're basically compensating for the rotation of the turntable with the robot.
If you look into the $machine.dat, what is your $ET1_TA1KR value?
The default for a KP1-V500 turntable seems to have C at 90 and all other values at 0.

Best,
Johannes

[jschmidt]

Hello!

Thank you for the reply!
The $ET1_TA1KR value is : (X 0.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0)

Attached are photos from the front and back. The KUKA motor we're using for our turntable was originally an A2 motor.
Because of the change, it would make sense to set C ~ 90.0 (or ~ 180.0)

[jschmidt]

Oh wait, wouldn't it be A at 90?

[Johannes @ Robots in Architecture]

I know this is a bit embarrassing, but I usually do these things by trial and error.
I'm honestly not sure why C=90, but that's what KUKA sets in WorkVisual and also - if I remember correctly - worked in my lab.
There is a manual for external axes - to be found e.g. here: https://www.kinematics.com/ftp/SA/Install/Driver%20Downloads/Robots/SARobotDriver%20Kuka%20Deployment%202014.08.13/KUKA%20KRC2%20Configuration/Important%20Docs/KSS_55_external%20axis%20setup%20and%20programming.pdf
On page 102 it shows the transformation for a two-axis positioner quite nicely, where you first rotate -90 around B for the horizontal axis and then rotate back +90 degrees for the "vertical" axis on top.

So more logical would be to set B to 180, so that the Z axis flips around. Or just leave it at all 0.

Alternatively in $machine.dat there is a $AXIS_DIR variable, where you could set $AXIS_DIR[7] to either 1 or -1

I'd just give those things a try!

Best,
Johannes

[jschmidt]

Okay, I sort of have an update here.
Everything seems to be working correctly, but I'm not sure how or why.

I've attached a working .src file program and a video of the robot and table running the program.
The program is fundamentally the same as the example posted here: http://forum.robotsinarchitecture.org/index.php/topic,822.0.html

This started working about a month ago when a software developer from Octopuz came to prove out the Octopuz software on our robot because we were thinking about buying a license. Long story short, Octopuz got their software to run a program accurately on our robot/table set up, and then they left, and I ran the attached program (octopuz.src) on the robot without changing anything in it, and it suddenly worked, when it hadn't the earlier that morning before Octopuz came.

The Octopuz employee said it was a matter of changing from "dynamic frames", and that the problem was that the Root Point frame on the table and the $TOOL frame on the robot flange were following the same angle, and he changed it so that they were following separate angles.

I've procrastinated posting an update on here because I don't really understand why the problem is solved. So, any insight as to what this fix entails is greatly appreciated! Thank you!


P.S.  $ET1_TA1KR = (X 0.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0), and $AXIS_DIR[7] = 1

[Johannes @ Robots in Architecture]

Hello,

Dynamic frames doesn't really ring a bell, maybe he referred to calibrating a turntable base as an offset system, rather than a normal base?
But great to hear that you got it to work!

Best,
Johannes

[Ivanescu]

I have the same problem, the arm is moving radial with the table. How can it be fixed ?
Calibration and the position is correct.
Base 17 is with correct position (rotary table coordinates) and it is selected in base in PRC.
The rotary table is moving in opposite direction than the simulation !
On the robot when moving manually + is clockwise looking from top ... is this correct ?

[Johannes @ Robots in Architecture]

Hello,

But is it synchronized? If the robot and table move nicely together and only the simulation is off, I'd rather leave the hardware as is and change the model of the turntable.

Best,
Johannes

[Ivanescu]

It is a made rotary table with a kuka motor and gear box.
No it is not syncronised.

[Johannes @ Robots in Architecture]

Then I would start there, calibrating the root point and then making an offset base.
The software setup should come afterwards!

Best,
Johannes

[Ivanescu]

It is perfectly synchronized now (when you move E1 robot fallows the point).
Now i get working envelope exceeded.

1. I have selected in PRC base 17 (it is with 0,0,0...) when i input base 17 coordinates it is far from the robot.
2. I have the corect XYZ input in Turntable component (Distance from the base of the robot)
3. The correct tool is selected.
4. I have tried with hard core base and tool from code page activated.
5. I have tried to manually modify Base 17 in the file.

CustomTurntable file has the same result. 

Base 17 in PRC shold be 0 or Turntable flange position ?

[Johannes @ Robots in Architecture]

Hello,

Base 17 is nothing special by itself, you need to make sure that you don't calibrate a regular Base system, but an Offset base.
For an offset base, the zero point is not the base of the robot, but the base of the turntable. So the values will be comparably small.

Best,
Johannes

[Ivanescu]

The robot Z cartezian values over the table are negative and this in not right ?

[Johannes @ Robots in Architecture]

I usually have it set up differentely, but there is no real "right" way to do it. If your simulation is then upside down in Grasshopper it's a "cosmetic" issue, but the simulation should still be reliable, as your external axis can be set up in any orientation.

Best,
Johannes