Search

[Xylotica]

I'm setting up my turntable at last.
I've checked out the Turntable example file and watched Karl's videos, but I just can't make sense of what I see in the attached file.
The position and orientation don't seem to reflect the input values for the root XYZ and ABC.
Could there be a bug with the "Custom turn-table" component ? Or is it me ?

[Johannes @ Robots in Architecture]

Hello,

So what I'm seeing is that you have defined the root of the turntable to be 2500mm in front of the robot, and then set the external base - which refers to the root point - to like 2300mm.
Currently, the center of the turntable is nearly 5m away from the robot, so out of reach.
Make sure to calibrate the base as an external base!

Best,
Johannes

[Xylotica]

I had unplugged the Frame/Base component from the "Base" input, and thought it had reset all the values to Zero inside the KUKA-prc main component...
I just can't get used to those values "hidden" in that component. To me, Grasshopper is about explicit values.
It's much better now that I've set the base to "zero"..

Thanks Johannes.

[Johannes @ Robots in Architecture]

Excellent, thanks for the update!
A "everything through Grasshopper inputs" component is still on my to-do list!

Best,
Johannes

[Xylotica]

New issue with the turntable : I set the initial position of the robot with a 180° angle on the E1.
In the "External kinematics" tab, I set the "Undefined rotary axis position" to "same as previous value".
Then why does E1 reset to zero at the first occasion ? (see .src screenshot).

Isn't the initial position a valid definition of E1's angle ?

Then I added an "Axis move" at the start of the program, specifying E1=180° again ; same problem : at the first LIN instruction, E1 is reset to zero.
Finally, In the "External kinematics" tab, I set the "Undefined rotary axis position" to "fixed value"=180° : same problem.

How can I solve this ? If the solution is to toggle the external axis inputs in all my LIN components and set E1 to 180, it seems a bit rough...

[Johannes @ Robots in Architecture]

Hello,

Can I take a look at the file? Either the IO operations are confusing it or 0 is set for the PTP movement.
At least that would be my best guesses!

Best,
Johannes

[Xylotica]

Hi Johannes, thanks for your explanation by e-mail.
For the record, in case it can help someone, here it was :

When KUKA|prc is set up to use a turntable, then the root point in the turntable component marks the position of the turntable within the robot's global workspace, and the base in the settings is then no longer in relation to the robot base, but in relation to the turntable.
When you calibrate the base, it's therefore important to calibrate it as an Offset Base, rather than a normal one. The process with 3 points is the same.

Now, I've set up the root point and base properly, but when I want to ratate just the turntable, I am forced to set values for A1->A6 which is kind of a pain in the neck.
It rejoins my request for a way to set a particular axis angle without messing with the other ones.
I understand now that I can use two simulation components for that purpose, but I wish there was a more elegant way to achieve this.

[Johannes @ Robots in Architecture]

Hello,

If you want to not rotate the coordinate system, you can also attach the "Dummy Axis" component. Let me know if there are issues, we fixed a bug recently that is not yet in the public release.

You can extend both axis and Cartesian movement components to accept E1-E4.

Best,
Johannes

[Xylotica]

If you want to not rotate the coordinate system, you can also attach the "Dummy Axis" component. Let me know if there are issues, we fixed a bug recently that is not yet in the public release.

Well, no. In this case I DO need to rotate the coordinate system.

You can extend both axis and Cartesian movement components to accept E1-E4.

Yes, of course !
I'm sending you my file.
Basicaly, I just need to rotate my table between milling zones orient the part in a more favorable way to the robot.
The issue is that, when I rotate the table, I don't want to set the 6 robot axis .
I could painstakingly do it by hand, reading the values from the analysis, using tags, etc... But that'll work only for a particular piece.

I want this to be parametric, because well, that's the point of using Grasshopper !
:)

[Xylotica]

Illustration.

I know how to fix this, but this shouldn't be a problem from the beginning.

[Johannes @ Robots in Architecture]

Ah, now I get it, when you create a Cartesian movement the tool rotates along with the turntable.
I can understand that you would like that to be easier, but the current implementation is consistent with how the KUKA works internally.
Also in industry a standard approach would be to move to a safe position, rotate the turntable and then continue the process.
I don't see a "Relatively move external axis based on the current robot position as per the IK solver" component as something that would find wide use, and it comes with the typical GH problems of acyclical dataflows.

Best,
Johannes

[Xylotica]

Also in industry a standard approach would be to move to a safe position,

The industry, for a long time, has been programming robots line by line.
The "Safe position" approach is a relic of those times.
Kinematic solvers / simulation tools such as yours allow to make smarter, adaptive toolpaths.

"Relatively move external axis based on the current robot position as per the IK solver"

That's not how I would phrase it.
I want the ability to rotate an axis independently without having to set the value for the others.
The fact that KUKA did not allow the programming of such a simple action is not a tribute to their smarts.
That's where tools such as yours could shine even brighter.