Setting Up DKP400 Virtual Cell Not Translating to Actual Robot

[GATECH_DFL]

I built a virtual cell to model the positions of my robot and DKP400 turntable. I moved the DKP400 relative to the robot using X,Y, and Z value in Positioner Root Frame menu when you click on the DKP400 component in grasshopper so the virtual cell matches my environment.

 However, I am simulating a simple curve to have the robot trace to test for milling, located above the DKP, not using any of its axes, just the robot by itself. Everything looks correct in the simulation, but when I run it on my robot, the robot goes to the floor, as if the curve is located below it. If I move the curve in X,Y, and Z by the same coordinates of the turn table, the curve looks extremely off in the simulation (located way too far away, unreachable). But if I remove the turntable and just plug in the robot to the ROBOT in the CORE component, the robot's location moves in the simulation and can reach the curve just fine, and it runs correctly on the real robot.

How can I implement the DKP into grasshopper without it causing the robot to be moved so far from its original position and place the DKP where it should be?

[Johannes @ Robots in Architecture]

Hello,

My guess would be that you did not calibrate the base as an offset base. An offset base is constrained to an external kinematic system, so in the case of a turntable it rotates along with it.

Please give that a try! When you calibrate an offset base on top of a turntable, you will get very low XYZ values as it is in relation to the turntable, rather than in relation to the robot.

Best,
Johannes

[GATECH_DFL]

The KRL files produced by kuka prc give coordinates relative to the turntable as the base. However, the robot is reading these as coordinates relative to its own base. For example, in the simulation if the robot is moving to a position where x is -900, it is moving -900 relative to turntable. In reality, robot tries to move -900 relative to its own base. How can I fix this issue?

[Johannes @ Robots in Architecture]

Hello,

I'll try to put it into an example.
You have got the offset from the robot to the turntable, let's say X=1000 and Z=500
Then you define an offset base, that is slightly higher, so Z=100.

If we now make a PTP movement to 0/0/0 and set a base that is tagged as an offset base, the robot will move to 1000/0/600 in absolute terms - however in the KRL file it will say 0/0/0.

If you don't set an offset base, the absolute position will be 0/0/100 instead. It will still say 0/0/0 in the KRL file.

The offset bases are in the normal list of bases, they just get an extra tag when you calibrate them as an offset base.

Does that make sense?
Best,
Johannes

[GATECH_DFL]

Yes, thank you!

[GATECH_DFL]

Another question. I have a simulation where the DKP400 is spinning and the tool is moving up and down as it should for milling. However, the tool is located on the wrong side of the geometry (causing unreachable points). How can I specify in grasshopper to have the tool be on the other side of the geometry?

[Johannes @ Robots in Architecture]

Hello,
I'm not 100% sure that I understood that correctly, but you can set the value of the external axis by right-clicking a movement component and selecting the option to show inputs for the external axes. So I guess adding 180 degrees to E1 would put it on the other side.
I would recommend looking into some of the samples for optimizing the external axis position - the automated solver is not optimal in many cases - especially for a DKP.
Best,
Johannes

[GATECH_DFL]

I am having the exact same issue every time I start a new program. The robot first goes to a point near the table where I have directed it, and then using the tutorial file for turntable you had posted, I have created a geometry on the table. The table begins rotating, but every single time the robot moves to the exact same position, where it maxes out A1 and A2 and turns the tool back towards itself. If I change the side of the geometry the robot should milling on, it still goes to this same position. The simulation works fine, but there seems to be an error translating to the actual robot. Is this a common error/easy fix?

[Johannes @ Robots in Architecture]

Hello, unfortunately while you provided a lot of details, I cannot fully troubleshoot it remotely. Some thoughts from my side:
It reads as if axis movements are accurate, this is why the first movement works nicely.
The rest points either to a wrong base calibration (should be offset base, not the normal base calibration!) or an error in the axis setup. Maybe the external axis is turning in the wrong direction or E1/E2 are switched?
"Wrong" being only in relation to the simulation, there are plenty ways to set up external axes.
Best,
Johannes

[GATECH_DFL]

Another question. I've programmed the robot to mill a symmetrical vase, the turntable turns and the robot simply needs to move up and down. However, I am getting a lot of unnecessary movement of the robot (it will move with the turntable, the TCP staying at the same point on the geometry), then the turntable will spin and the robot head will stay still so it can mill a path. Then it does the same thing (moves with the turntable, then back, then the turntable moves and it mills the next path). How can I remove this unnecessary movement? I was thinking of using Galapagos, but there aren't any parameters I can plug it into to change this.

[Johannes @ Robots in Architecture]

Hmmm... The easiest way might be to use axis movements in between larger movements.
So the robot finishes a path, moves in Z away from the object, makes a PTP movement to a safe position while the turntable rotates, then moves back and continues your linear motion paths.

You will need to identify paths with significant repositioning time (e.g. by comparing the E1 values), because if it just moves 20mm, then in turn the PTP motion is a major waste of time.

Best,
Johannes

[GATECH_DFL]

Thank you for the response. I'm still having a lot of trouble removing these unnecessary movements, some of which are resulting in singularities or collisions. I've attached file here if you could look and tell me where I need to adjust? The robot also does some of these extra movements in the simulation.

[GATECH_DFL]

Rhino file for above ^ (accidentally did not attach both).