Calibrating KP1-V500 with KUKA|prc

[AADPL]

I've followed Karl Singline's video tutorial (https://www.youtube.com/watch?v=0gF4Lkhtumc) on how to set up a custom turntable in Grasshopper and now have a lovely path which can be seen in the attached Rhino and Grasshopper files. To get it to work, I used the custom turntable block and set X = 1382, Y = 666, Z = 705, which results in a satisfactory simulation.

When I tried to run the program on the robot though, the robot tries to reach the coordinates very literally, which means that the robot starts reaching for a point near the "origin", which is somewhere in its own base. i.e. the highlighted coordinates in the left image correspond correctly to the KUKA|prc geometry in grey in the right image, but actually the robot's origin is shown relatively in green in the right image. So essentially, the grasshopper simulation doesn't correspond to the physical movements of the robot.


Some more exploring led me to Karl's top tip #1 (https://www.youtube.com/watch?v=nphRj5J8wCs) for making sure you actually define what base the robot should be using, and then petrvacek's post (https://forum.robotsinarchitecture.org/index.php/topic,1126.0.html) about calibrating external kinematics. Which both to me sounded like a good point to trouble shoot.

That led me to try and carry out step 2 for Calibrate External Kinematics Root Point for my KP1-V500 (see picture below). But when trying to do this step, if I rotate E1 manually to 4 different angles, and get our calibrated spike to touch the engraved cross at all 4 points then I get an error that is larger than 100mm, and if I just try and locate the root point in the middle 4 times then it says there is not enough movement between the points.



So essentially, I'm confused. I'm not sure if I'm doing the Calibrate External Kinematics Root Point right, and if this will indeed solve my problem, or if there is somewhere else I'm going wrong in the Grasshopper/prc plugin.

Thanks for the help!

[Johannes @ Robots in Architecture]

Hello,

First of all, I really appreciate the good preparation!
The first thing that comes to my mind is whether you calibrated your base 12 that you are using the file as an Offset Base (rather than a normal base). An offset base is defined in relation to the base of the external kinematic, not to the robot. So the values will be relatively small if you are calibrating it on the turntable.

For the root point calibration, the 100mm error seems pretty high and noticeable. I'd suggest marking a point on the turntable, putting the XYZ position as measured with the robot's tooltip into Rhino, rotating it by 90 degrees and repeating it until you are back where you started. You should be able to see a 100 mm error easily there. When e.g. 360 degrees are not physically 360 degrees etc.

In any case, first make sure that the turntable is properly synchronizing with the robot (i.e. you move the turntable in a Cartesian mode and the robot keeps its position in relation to it) before you move on to Grasshopper and KUKA|prc.

Best,
Johannes

[AADPL]

Hi Johannes,

Thanks for the response. Sorry, I've been busy with some other things so haven't had a chance to play around some more with the turntable until now. Also, I'm aware that the issues I'm having are slightly more from the system integrator side of things rather than the KUKA prc side of things, so thank you for your help!

So I'm still not 100% sure about whether the turntable is set up correctly. I can't seem to get it to jog while keeping the robot tool TCP and external axis reference point moving together. And I've tried trawling through the machine.dat etc and the turntable does seem to be set up correctly in terms of allowing synchronous movement etc. but I've not been able to do as you suggest to:

you move the turntable in a Cartesian mode and the robot keeps its position in relation to it

Otherwise, the config.dat for the bases looks fine.


The one bit that is a little suspicious to me is that the frame for external axis in the machine.dat is all blank?


Further to that, why does the external machine have a root in the config.dat as well? Should the Z value here actually be 0.0 and then in the machine.dat then FRAME $ET1_TA1KR should have Z = 686?


And then I suppose the final piece of evidence I have for things going wrong is that if I actually select a base in KUKA prc and try to run this on the robot then all I get is a software limit switch error after the robot has reached the start/home position and when it tries to do the first PTP move.


Its not a riveting watch but here is a video of me calibrating the root point of the external kinematic system. Am I doing something stupidly wrong here? I still don't really understand why the error is in the 10s of millimetres really? https://youtu.be/TJX9cj7bfwA

From the KUKA prc side of things, do you know which values/calibration/coordinate system in the plugin is responsible for the some sort of an offset between the X and Y values of the target planes I provide vs what actually gets spat out into the KRL? I.e. if I gave it a target plane of X 10, Y 20, Z 30, is there a way in KUKA prc (I guess not using bases and frames) of having the KRL have that same plane translated to X 20, Y 30, Z 30, effectively with an offset of X +10, Y +10, Z 0?

Thanks,

Alex

[Johannes @ Robots in Architecture]

The configuration looks fine, #EASYS should be the right mode. If ET1_TA1KR is all zero, it means that the axis is right on the root point. For your one-axis system, only the ET1_TA1KR is important, so guess that is plausible for a one-axis positioner.
That's a bit of a long shot, but you could try setting the ROOT value in the machine definition / config.dat to all 0 and then calibrate again.
While I don't think that this is connected to your issue with the failing root point calibration, you need to make sure that the external axis is linked in WorkVisual as well. That is the case if there is an arrow going from the robot to the turntable (and not just both connected to the controller).

If the root point calibration continues to fail, I would get in touch with KUKA support. Usually they are pretty good at those clearly describeable things (80mm error where it should be just a few mm). Make sure to include a KRCDiag file in the request.

Regarding the KUKA|prc question: You can use bases on a turntable, they are just called Offset Base as the XYZABC values are in relation to the root point of the turntable and not in relation to the base of the robot. That would take care of the offset.

Best,
Johannes

[AADPL]

Hi Johannes,

So I've managed to get the turntable jogging correctly, and am now very close to getting everything working! Although KUKA support were very unhelpful with the explanation of why the error could be so high for the calibration.

My main issue now is that the A value for my XYZABC targets in the KRL code is consistently increasing, meaning that my Axis 6 locks out after the first layer of the milling strategy. I know I can make Axis 6 have endless rotation, but this also isn't matching the simulation in PRC which shows the tool just approaching from one spot. I'm unsure why the A value is increasing, since I have the rotary axis vector set, and in the past that essentially locked the A value to be near constant i.e. the tool is always approaching from the same direction.

[Johannes @ Robots in Architecture]

From the XYZABC it looks like you would like the tool to more or less stay at the current position, right?
So if A moves by 8 degrees, then E1 does the negative -8 movement.
Is it possible that the real and simulated turntable turn in different directions? So instead of -8 + 8 = 0 you get 16?

Best,
Johannes

[AADPL]

Yes, staying at the current position would be good. It's possible that the turntables are going in different directions, but how do I swap this? If I flip the turntable on the robot then the coordinate system would have Z in the wrong direction and the robot would try and reach underneath the turntable, and I can't seem to find a way to flip it in PRC? I tried flipping the axis on the custom turntable block, but that didn't change anything.

Best,
Alex

[AADPL]

Just sending the files because I still haven't managed to figure anything out!

[Johannes @ Robots in Architecture]

Hello Alex,

Sorry for the late reply, I'm on holiday and therefore not as quick as usual.
Reversing the rotation axis of the turntable should flip the rotation direction as well - see the attached example!
Otherwise the approach would be to look into the machine data file, but let's keep that option for later.

Best,
Johannes

[AADPL]

Hi Johannes,

Thank you for replying on your holiday! No rush needed with the replies.

So if you see the YouTube link below I don't think the reversed direction is working consistently? Angel came up with the solution to use the flipped surface which worked on both our computers at some point, but now I try and do the exact same process and it doesn't reverse?

https://youtu.be/lr7nmwQAooI

[Johannes @ Robots in Architecture]

Hello,

Can you please send me the file and label/internalise the different options as they are on your PC?

Then I can check for differences! It also doesn't hurt to use the Recompute function, just to see if that makes a difference!

Best,
Johannes

[AADPL]

Sorry for the long delay, has been very hectic here!

Recompute doesn't seem to be changing anything here.

Attached is the grasshopper file.

Best,

Alex

[singline]

Instead of using the panel with -1 in it, right click on the rotation axis input on the Custom Turntable component and add the expression x*-1

That should fix it.

[Johannes @ Robots in Architecture]

Thanks, Karl!!

[AADPL]

Reversing the rotation axis of the turntable should flip the rotation direction as well - see the attached example!

Okay, so using Karl's x*-1 approach, I can now successfully reverse the turntable direction in my main Grasshopper definition, but this is still resulting in the same issue where I can see the A value increasing like before, rather than staying in a similar range.

Otherwise the approach would be to look into the machine data file, but let's keep that option for later.

I'm confused why this is the other option because the robot is doing what it is being told to do from the KRL, its more that the simulation isn't matching the KRL, if you understand what I mean?

Best,

Alex