KRC 2 external axis causing program errors?

[jschmidt]

The tool is calibrated correctly: we moved it in the A,B and C axis and the tip stayed in the same place.

The robot is not professionally leveled and neither is the turntable. They are both sitting in the corner of a room with a poured concrete floor (where the floor is highest in elevation at the corners of the room) so we are going to focus on that next.

The actual "table" that sits on top of the turntable is also not completely level - with the middle where its secured to the mechanics being higher than the edge - but I don't see why that alone would create a deviation because the reference point for the root point stays in the same place relative to the table, and then just the entire table and the reference tool on the robot are moved.

Finally, the robot does seem to wobble as it moves: in the TOOL coordinate system, when we jog the X-axis or Y-axis @ 10% speed, the tool is clearly wobbling a bit - is that normal, when jogging at continuous motion? We went through and tightened the anchors that connect the foundation plate to the concrete floor, as well as the bolts that connect the robot to the foundation, but that produced no change in wobbling. If this is a problem, and the professional leveling doesn't completely fix our error measurement deviation, I am unsure of what to do next.

[Johannes @ Robots in Architecture]

Hello,

It shouldn't matter whether it's levelled or not, after all the frame of the turntable is set in XYZABC, so just like a base it could also be tilted.
It's quite normal that the robot is shaking a bit when accelerating and decelerating during jogging, but while it's moving it should be a straight line.
When you calibrated the robot, did you use a calibration device (EMT/EMD)? Because it's not enough to just align the white marks.

Best,
Johannes

[jschmidt]

Okay! Got it - that's good-ish news I suppose.
When you say calibrate, you mean mastering, correct?
Because yes we used an EMT tool to master the robot, and we were also able to calibrate 3 tools correctly with XYZ 4 Point and only received an error measurement of around 0.5 mm with each calibration.

When mastering the external kinematic, we are not able to use an EMT tool because we built our own mechanics around the KUKA motor. So, to master it, we simply select Setup > Master > Dial > External Axis 1 > Master and that's it - we don't move the external axes at all before we master or do anything else. Does that matter?

[Johannes @ Robots in Architecture]

Yes, I meant mastering. All of that sounds fine, as a turntable is generally symmetrical it doesn't matter too much where the zero point is located at!

Maybe one more thing: Did you set the gear ratio correctly? That might also confuse the robot during the calibration.
EDIT: I guess you could check the gear ratio by manually jogging the turntable, to check if 360 degrees are actually one full rotation.

If that doesn't help I would try to enter the values manually, just to see if it works out. In your $config.dat there will be a line like that...
MACHINE_DEF[1]={NAME[] "DKP-400_1_40A_400V",COOP_KRC_INDEX 1,PARENT[] "WORLD",ROOT {X 7000.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0},MECH_TYPE #EASYS,GEOMETRY[] "ObjectId = -1068536877"}
Set the XYZABC of the ROOT to the position of the turntable. Maybe leave ABC at 0 to start with. Then calibrate an Offset Base and see if it's synchronizing (with a little bit of drift).

Best,
Johannes

[jschmidt]

Hello:

The process you suggested (I think) allowed me to calibrate the Root Point correctly. Referencing an earlier response to this thread, I moved the TCP to the origin of the rotary, and then displayed the TCP's position with the variable $pos_act and recorded the XYZ values. Then, I went under Setup > Measure > External Kinematic > Root Point (numeric) and entered in the XYZ values.

I think though, that I am confused about the necessity of a base calibration when using a turntable and creating a code in KUKA|prc for it.

In KUKA|prc:
I created a toolpath from the control points along the polylines that were derived from the contours of a form that I want to mill out of a piece of foam. After entering in the Root Point Numeric values in the teach pendant, I entered the same values for XYZ for the robot under Positioner Root Frame in (the Generic Turntable component).

Because the root point is given, and the control points to mill between are given in grasshopper, why is it necessary to also enter in Base values in KUKA|prc? It's my understanding that the base in the initial "stock" of foam that will be milled - is that incorrect? In the .src file, my base is set at 0.

I've attached my .gh file and .3dm file in case that clarifies my question.

[Johannes @ Robots in Architecture]

Hello,

Well, the thing is that even if you have got a turntable, you might not always want to use the root of the turntable as your origin. But note that bases on a turntable are called Offset Bases, and you need to calibrate them as such. If it's not an offset base, then it won't rotate along with the turntable. I doubt that base 0 would work as an offset base, so calibrate a new offset base - you can use all 0 if it's at the center of your turntable.

Some more suggestions: The GEO input of the turntable is meant for the geometry of the object on top, i.e. it will rotate along with the turntable. At the moment we do not support custom turntable geometries, though we can integrate it as a native component for members.

And very important: The more triangles you have, the slower Rhino gets. Your turntable model has got 45k vertices, which is more than the entire robot. So your performance will get quite a hit.

I have made a quick example for you on how to calculate turntable values automatically. See here: http://forum.robotsinarchitecture.org/index.php/topic,822.0.html

Best,
Johannes

[mcb]

Did you solve the large measurement error during calibration? This could also be due to an incorrect gear ratio being set. Do you have the exact ratio for your gearbox?

[jschmidt]

@ Johannes: Okay, that makes more sense about the offset base: if you don't want to use the root point of the turntable as your origin, the robot will use the origin of the base that's on top of the turntable. If you do want to use the root point of the turntable as your origin, then there is not a need to calibrate an offset base.

When you say "I doubt Base 0 would work as an offset base" - do you just mean in terms of the program being set to a base called "0"? (why does it matter whether it's called Base 0 or Base 17 if the XYZABC values will all be 0 for either one?)

Thank you for your note about the amount of triangles in the table mesh. I knew that the Geo input of the turntable was meant for the mesh of the final form and just forgot to unwire it so it was a good reminder to disinclude that. I've swapped it out for a simple extrusion in Rhino of the turntable top so that I can make sure the spindle isn't colliding with it (attached for ref)

Finally, thank you so much for the example file!! That has solved almost all of my issues. I think the last thing to resolve is that A6 is spinning all the way around in the first few motion blocks, and then about 30 lines down stops the program because "software limit switch +A6 reached" or something to that effect. Just something else that needs to be resolved in the .gh script I'm assuming.

--
@ mcb: for calibration of the Root Point of the turntable, I entered in the values numerically: I moved the TCP of a previously calibrated tool to the origin of the rotary, and then displayed the TCP's position with the variable $pos_act and recorded the XYZ values. Then, I went under Setup > Measure > External Kinematic > Root Point (numeric) and entered in the XYZ values.
I believe the gear ratio is 24/1 based on the $rat_mot_ax variable (photo attached because not sure if that's it)

[jschmidt]

Aaand now looking at the analysis of the code again, I see that there is a wrist singularity right at the beginning, which would be the reason that the simulation after the singularity is inaccurate.
So! I suppose I am on to modifying the $SINGUL_POS[3] variable in the machine.dat file

[Johannes @ Robots in Architecture]

Hmm... I need to look into why this is showing up as a singularity, because it seems to be part of a PTP movement, where singularities are not a problem.
In general to avoid singularities, just adjust the posture (e.g. via status, or simply by changing the starting position) or for milling rotate the tool around its axis.
And base 0 is "hardcoded" as the robot's base, so I wouldn't change it (not sure if you can even change it).

Regarding the gear ratio, as I suggested before I would simply manually rotate your E1 by 360 degrees and check if it makes a full circle!

Best,
Johannes

[jschmidt]

I've been updating our Call Center Engineer @ KUKA on this process as well, and he is saying that:

   - Our serial number indicates that we are operating a KR 125-2
   - But our $robcor.dat from the archive that I sent him shows it is configured to control: KR 150 L150  "#KR150L150_2_TJ H C2 FLR ZH01"

   and that this difference could cause some substantial differences between the motion planning and the physical path of the robot. So, we've been instructed to reinstall
   the default files for the machine.dat.

I'll keep you updated on this process - let me know if you're able to look into what could be causing a wrist singularity @ the PTP movement and maybe resetting the machine.dat is the right answer as supported by both investigations?

Also, okay good (!) - just jogged the E1 360 degrees and that worked. I think that instruction went over my head before - whoops

[Johannes @ Robots in Architecture]

You should have got a sticker on the side that tells you the robot type - what does it say?
But it's of course possible that somehow robots and controllers got mixed up.

I'd recommend making a backup of the current setup before the re-installation. If you don't have the KUKA recovery stick, either install backup software on the robot or (better) connect the HDD to another PC via an USB adapter and use a software like Macrium Reflect to make an image.

Best,
Johannes