Problem calibrating turntable root point

[bridgewater studio]

We've gotten to the point where we're trying to use the rotary table with CAM software, but there's a problem calibrating the root point. I've repeatedly followed these directions, but keep getting a wrong calibration. I've attached a picture of the saved settings.

Correct me if I'm wrong with your directions:

1) Locate table where it is to be used and level it. (I've also mounted a steel point in a small spindle and calibrated a TCP for that to use. I used that steel point TCP to find the rotary center of the table by rotating the table top with the steel point touching it near the center and jogging the tip until I found the center of the table. From there I repositioned the table top to be square with the base. From my homemade table top center point, I jogged the tool tip 395 mm to one edge of the table (the table measures 400mm from the center to closest edge) to make the mark for the Tool Reference Point. I numerically entered this data as (395, 0, 0, 0, 0, 0) (X, Y, Z, A, B, C) as a Tool in the Kuka.}

2) Unmaster External Axis 1 and remaster using Dial mode. (I'm not sure if I need to unmaster every time I move the table, but I have been doing that.)

3) Measure the External Kinematic Root Point using the Tool Reference Point created above using the 4 point method with the calibrated tool already mounted.

Can anyone see anything here that I did incorrectly? I ask because I consistently get a C value of +/- 179°. Why does the robot keep calculating the table to be upside down?

The software we're using to program the robot with the rotary is Kuka|PRC. If I enter these values or any C value like this into the generic turntable component, it flips the table relative to the robot, which won't work. I don't understand what could be causing this C value.

If anyone have any ideas or other sources to find answers, please let me know.

Thanks

[Johannes @ Robots in Architecture]

Hello,

Is the turntable synchronizing correctly, i.e. the robot's tool keeping its position in relation to the turntable when you're moving E1 (in a Cartesian movement mode, after having calibrated and activated an offset base)?
If that is the case we can also simply adjust the turntable model in KUKA|prc. Or you could simply add 180 to -179 and see if that works.
But before we proceed to PRC, it's important that the calibration is right, otherwise we're accommodating a broken calibration through software, which usually leads to more problems down the road!

Best,
Johannes

[bridgewater studio]

I've been simply setting C to 0 in the turntable tool in PRC just to make it work. I'm worried that this will cause everything to flip once I run the program at the robot.

And yes, whatever tool I set, if associate with the external kinematic system, then when I jog the table the robot TCP will stay fixed to the table and jog with it.

[Johannes @ Robots in Architecture]

Hello,

Can you check if the positive rotation direction is the same on both the simulation and the actual turntable?
I guess that it might be going in different directions.

Best,
Johannes

[bridgewater studio]

From the turntable manufacturer, we were directed to simply set the A, B, C values to zero for the Root Point using the Numeric Input option. His reasoning was that since the table was leveled, which he also directed us to do, that we were simply rectifying the machine data with the actual table.

I just want to state for the record that his advice was fundamentally unsatisfying. I really want to know why the machine made the incorrect calculation to begin with. I get worried that this is the result of crossed wires in the data cable. It should be noted that this same manufacturer sent us a power cable with 4 of the wires in reversed positions; I had to track this problem down myself, open the cable to expose the leads, reverse the positions of the brake power lines and the mains power lines, and reassemble. It all now works. But that isn't to say that the data cable was wired correctly, which I haven't yet checked and don't know how to check.

All that said, our table and the simulation are rotating in the same direction - initially. I have a gh definition that you had made for one my colleagues here and I modified it so that the generic turntable component matches our turntable location as well as to incorporate some changes I had made to our hotwire tool. With another adjustment to the opoint of the Orient Plane component to get the tool to align correctly, I got CORE to solve and generate code that does run in our robot.

However... the robot still thinks it's upside down relative to the table, even though I zeroed A/B/C as seen in the picture: X/Y/Z are all negative. So when I run the program the robot wants to push the TCP to the positive position relative to the table top, which in this case would be underneath the table top. If I then change the C value in the robot back to 180, the program will execute again, but when I gets to about line 14, I think, it links with the table and the TCP and the table start synchronously rotating counter-clockwise, opposite of programmed rotation. Eventually, the robot hits an axis limit and halts movement.

I fully realize that you're not responsible for our hardware problems, but I'm hoping you might have some insight as to what is causing this or maybe direct us to information somewhere, somehow that will reveal what we are fundamentally missing.

As to our calibration method, I've marked the reference point on the table as (395,0,0,0,0,0) [X,Y,Z,A,B,C] per the manufacturers specification, which is also set in the Axis Configurator in the variable $ET1_PINFL. When I calibrate the table, I first unmaster the table, then master in Dial mode with the table top more or less square to the base and in the location that I want to use it for this project. I have created a tool for the reference point using the same input as the Axis Configurator. I used a previously calibrated TCP with a metal point mounted as the measure tool. I followed through with the procedure lined out inside the Root Point measure tool inside Setup.

The way all of this is setup, I would expect that the positive X direction in the Rotary base for the external kinematic should point from the center of the table toward the reference and the positive Y perpendicular to the left of that vector. In fact, after calibration, using the newly calibrated Rotary1 base coordinate system, the positive X lies in the direction of what I thought should be negative Y and positive lies in the direction of what I though should have been negative X. And as you might guess, positive Z is down into the table. No matter what I do, it keeps thinking the table is upside down.

This is why I thinking we've got crossed wires somewhere, or a secret button wasn't set correctly inside some as yet unseen configurator that no one wants to tell me about.

We just can't make any progress at all because of this problem and I just don't know what else to do.

I've attached the rhino and gh files to see our setup. This will run in our robot, just not like what you see in the simulation.

[bridgewater studio]

Actually, correction to previous post: I stated the orientation of the X/Y/Z incorrectly. It's actually more simply like a -90 degree rotation away from positive X. So X is along -Y, Y is along +X, and +Z is +Z. But that's with A/B/C uncorrected to 0s. When A/B/C are "corrected" to 0s, you'd see values more like the picture above.

[bridgewater studio]

Alright, I figured out that the problem was in improper offset calculation. I had previously been thinking that offset were for working on parts on different parts of the base. Here, though, the offset is simply informing the robot as to which side of the rotary is up... I think. I used the center point of the table (physically scratched into the table using a steel point) as the origin of the offset. Then setting +X in the direction of positive/outward from Robot Root and +Y perpendicular and to the left of that. Now when I run the as expected with the robot making the correct approach and the tool oriented correctly from what I can see. However...

The final fly in the ointment is that our table is now rotating in the opposite direction of the PRC simulation and it's not clear why.

Thoughts?

Thanks

[Johannes @ Robots in Architecture]

Hello,

Sorry for not getting back to you before that, it's quite busy here with the start of the Rob|Arch registration etc.
What offset are you referring to? The offset base is simply a coordinate system that is placed in relation to the root point of the turntable, which means that it also rotates along with the turntable. A normal base would not do that, as it is fixed to the root point of the robot.
Regarding the axis direction, you can try the AXIS_DIR thingy from here: http://forum.robotsinarchitecture.org/index.php/topic,824.msg2131.html#msg2131
If it does not work, I can just switch the rotation direction of the turntable as well on the PRC side.

There isn't really a right or wrong with these things, just as some people use the X-axis as the robot's toolaxis, and some use the Z-axis.

Best,
Johannes

[bridgewater studio]

So, when I ran the offset with the root point of the table as the origin, it initially had the effect of causing the robot to execute the prc code correctly with the exception of the table rotation.

I then did in fact open Axis Configurator to change AXIS_DIR to -1, which didn't change the positive rotation direction of the table at all, but instead screwed up how the robot executed the code. I'm not sure how to describe what it was doing, but it was even close to what the prc simulation was doing.

I really feel like this should not be this difficult. Measuring the root point is so simple to do, how can this forever be causing so many problems? This is why I'm worried that the wiring or configuration is wrong, but I really don't have any procedure for tracking down the error. No matter how I do it, the robot thinks the table is upside down. I can't find any other variable to modify. And now, after making changes in all these other regards, the robot now thinks that the starting position is about 3 feet higher than where prc is indicating it is.

I would happily read the manual, if someone would kindly show me what page in which manual clearly states how to resolve this.

[bridgewater studio]

Actually, I just tried setting C to 180 degrees for ET1_TA1KR in Axis Configurator and then recalibrated the root point. I'm now getting close to 0 for B and C, which is good!

However, when I try to run my test.src out of prc I'm now getting an error for Work Envelope Exceeded. Is there something else I need to set in prc to accommodate this change? Or is it something else altogether?

Thanks

[Johannes @ Robots in Architecture]

Hmm.. Did you also re-calibrate your offset system, just in case?
I would try to compare the physical and actual robot, i.e. put them both in the same axis position and then see where the robot thinks that it is in the Cartesian space.
That should give you an idea where the problem is.

Best,
Johannes

[bridgewater studio]

I didn't. I'll try it. Do you think I would need to recalibrate my tools' TCPs as well? I wouldn't guess I'd need to, but so far none of my guessing on any of this has been very good.

As for physical location, see pic. This looks like the same problem I've been having all along. You can see that the X/Y/Zs of the tool relative to the rotary table are all negative even though it is currently occupying a very clearly +Z location, at the very least.

[Johannes @ Robots in Architecture]

Hello,

Well, the mastering of the turntable is important to set the right axis and therefore direction of rotation.
However, if you create an offset base - and don't flip the XY axes - Z should definitely be up.
So I would guess that with an calibrated offset base we should be much closer!

Best,
Johannes

[bridgewater studio]

Thanks for all your help with this Johannes.

So, it turns out I had all the right elements, they just needed to be blended just so.

I mastered the turntable and found the root point. I zeroed the B and C values since my table was leveled. I decided to keep the A value, but I could probably chuck that as well.

(No matter how many times I tried, I always get a C value of near +/- 180; if I changed the C value of ET1_TA1KR to 180, that wound up causing other weird problems, I think; this is such a weird, vexing problem; that it turns out not to be a problem, at least right now, just gives me anxiety, because it just seems like a problem waiting to drive me insane in the future.)

As it happens, I had multiple TCPs for the hotwire tool I had created in two different files that I was working with. For the purposes of communicating with you I had used the files above that you had helped us with. However, I had been working with another file where I had updated the TCP for that tool but had yet to update the files I posted here with it. Another person came in to help us with this and he just immediately looked for those values on the robot to double check and sure enough that was the final puzzle piece.

Also, there might have been something to do with having changed so many of the configuration settings and then resetting them that the computer needed to be rebooted. Once that happened, it just seemed like everything started working better. (It had stopped recognizing our usb drive for instance. Once rebooted it found it again.)

Anyway, for the moment we're up and running and we are now able to run the program using a rotary table in the robot and cut foam with the program running to completion with no problems. I'm still not completely confidant that if I move the table and do this all over again that I will be able to run everything correctly. But at this point, I at least have a better process by which to instantiate everything.

Thanks for your patience and efforts! Have a great conference.

John

[Johannes @ Robots in Architecture]

Hello John,

I'm not sure that I contributed much, but I'm very happy that you were able to solve it, and really appreciate you sharing the steps you took!
By the way, the next KUKA|prc update, which I will probably upload in the second half of the week, will allow you to define a custom turntable geometry, by the way. So you can integrate your own turntable for collision checking!

Best,
Johannes