Messages

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

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

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.

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

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!