Recent posts
#21
Support / Re: plane to frame with python...
Last post by Johannes @ Robots in Architecture - July 02, 2024, 07:54:43 AMHello,
I sent the reply a bit too quickly yesterday because there are some extra steps. Internally KUKA|prc works with a different Plane definition, and the resulting commands also need to be formatted for GH. So generating a LIN movement with a plane would look as below:
An example made in Rhino 8 is attached!
Best,
Johannes
I sent the reply a bit too quickly yesterday because there are some extra steps. Internally KUKA|prc works with a different Plane definition, and the resulting commands also need to be formatted for GH. So generating a LIN movement with a plane would look as below:
Code Select
KUKAprcCore.Geometry.Plane ghPlane = KUKAprcGH.PRC_GH_Methods.PRC_GH_Methods.PRC_RHtoPRC_Plane(pln);
KUKAprcCore.PRC_Classes.PRC_CommandData cmd = KUKAprcLibrary.PRC_Commands.PRC_LINMove(ghPlane, 1.0, "C_DIS");
KUKAprcGH.PRC_IOClasses.GH_PRC_CommandData ghCommand = new KUKAprcGH.PRC_IOClasses.GH_PRC_CommandData(cmd);An example made in Rhino 8 is attached!
Best,
Johannes
#22
Support / Re: plane to frame with python...
Last post by Johannes @ Robots in Architecture - July 01, 2024, 05:51:04 PMHello,
Your Python code is only generating a string, so you could write that into a file and run it.
For KUKA|prc you need to bring it into a KUKA|prc component.
The easiest would be just to get the XYZABC values as doubles and plug them into a Frame component (or you do the three rotations yourself, the Frame component doesn't do much more).
To create a linear movement by code, use
Best,
Johannes
Your Python code is only generating a string, so you could write that into a file and run it.
For KUKA|prc you need to bring it into a KUKA|prc component.
The easiest would be just to get the XYZABC values as doubles and plug them into a Frame component (or you do the three rotations yourself, the Frame component doesn't do much more).
To create a linear movement by code, use
Code Select
KUKAprcLibrary.PRC_Commands.PRC_LINMove(Plane pln, double velocity = -1, string interpolation = "C_DIS")Let me know if there are any problems!Best,
Johannes
#23
Support / Re: plane to frame with python...
Last post by bobrobot - July 01, 2024, 10:11:12 AMThanks for the fast reply! I will keep working on it.
one other thing is the error :
2. Data conversion failed from Text to KUKA|prc Command.
Is there a way to put the python generated code into the CMDS of the KUKA|prc core
For instance the python outputs:
LIN: X 529.21, Y 193.84, Z 582.43, A 1.75, B 9.85, C 10.15, E1 0, E2 0, E3 0, E4 0
but the core doesn't like it as its a text instead of a KUKA|prc generated command.
Tried to put the text into the KRL code command but no luck
Thanks again!
one other thing is the error :
2. Data conversion failed from Text to KUKA|prc Command.
Is there a way to put the python generated code into the CMDS of the KUKA|prc core
For instance the python outputs:
LIN: X 529.21, Y 193.84, Z 582.43, A 1.75, B 9.85, C 10.15, E1 0, E2 0, E3 0, E4 0
but the core doesn't like it as its a text instead of a KUKA|prc generated command.
Tried to put the text into the KRL code command but no luck
Thanks again!
#24
Support / Re: plane to frame with python...
Last post by Johannes @ Robots in Architecture - July 01, 2024, 07:39:54 AMHello,
In general the code "looks" plausible, but I guess that is the thing with AI-generated code, there could still be issues. Some things to consider are that KUKA|prc by default uses X as the tool-axis. Take a look at the "Frame - KUKA|prc" component, where you can toggle between the tool axes (also that option is in the settings if you want to use the Z-axis everyhwere). The second thing is that there are multiple ways to express the same coordinate system. So just because the ABC values differ, it does not have to be incorrect. So turn your ABC angles into a coordinate system and compare the coordinate axes.
Best,
Johannes
In general the code "looks" plausible, but I guess that is the thing with AI-generated code, there could still be issues. Some things to consider are that KUKA|prc by default uses X as the tool-axis. Take a look at the "Frame - KUKA|prc" component, where you can toggle between the tool axes (also that option is in the settings if you want to use the Z-axis everyhwere). The second thing is that there are multiple ways to express the same coordinate system. So just because the ABC values differ, it does not have to be incorrect. So turn your ABC angles into a coordinate system and compare the coordinate axes.
Best,
Johannes
#25
Support / plane to frame with python for...
Last post by bobrobot - June 30, 2024, 08:30:38 PMHi Forum. Thanks in advance for your advice!!!
I am trying to get a little deeper into using python in combination with KUKA|prc for robotics :)
working with ChatGPT to create a class that takes planes and generates robot frames...
But its not going well :(
I have read that KUKA uses the Euler ZYX system to calculate the TCP orientation. This means that three rotations happen in a specific sequence to achieve the final orientation. The order is:
A rotation about the world Z axis
B rotation about the new Y axis
C rotation about the new X axis
Diving deeper to understand this I found the following site: https://www.mecademic.com/academic_articles/space-orientation-euler-angles/
Which is super interesting.
ok so i have a sample plane: O(0.00,0.00,0.00) Z(0.17,-0.17,0.97)
which when passed through the LIN motion component outputs: LIN: X 0, Y 0, Z 0, A 135.4, B 75.9, C 134.6, E1 0, E2 0, E3 0, E4 0
and when I pass through the following code generates: LIN: X 0.00, Y 0.00, Z 0.00, A 1.75, B 9.85, C 10.15, E1 0.00, E2 0.00, E3 0.00, E4 0.00
not sure whats gone wrong. any advice is appreciated!!! Thanks!!!
here is the python code (file attached):
import Rhino.Geometry as rg
import math
class PlaneProcessor:
def __init__(self, plane):
# Initialize with the input plane
self.plane = plane
self.frame = None
def calculate_frame(self):
# Deconstruct the plane to get its components
origin = self.plane.Origin # Origin point of the plane
x_axis = self.plane.XAxis # X-axis vector of the plane
y_axis = self.plane.YAxis # Y-axis vector of the plane
z_axis = self.plane.ZAxis # Z-axis vector of the plane
# Construct the frame using the origin and axes
self.frame = rg.Plane(origin, x_axis, y_axis)
def get_euler_angles(self):
if self.frame is None:
# Ensure the frame is calculated
self.calculate_frame()
# Extract the axes from the frame
x_axis = self.frame.XAxis
y_axis = self.frame.YAxis
z_axis = self.frame.ZAxis
# Construct the transformation matrix from the axes
transformation_matrix = [
[x_axis.X, y_axis.X, z_axis.X],
[x_axis.Y, y_axis.Y, z_axis.Y],
[x_axis.Z, y_axis.Z, z_axis.Z]
]
# Calculate Euler angles using the ZYX convention (intrinsic rotations)
# A is the rotation around the world Z-axis
A = math.atan2(transformation_matrix[1][0], transformation_matrix[0][0])
# B is the rotation around the new Y-axis
B = math.atan2(-transformation_matrix[2][0], math.sqrt(transformation_matrix[2][1] ** 2 + transformation_matrix[2][2] ** 2))
# C is the rotation around the new X-axis
C = math.atan2(transformation_matrix[2][1], transformation_matrix[2][2])
# Convert the angles from radians to degrees
A = math.degrees(A)
B = math.degrees(B)
C = math.degrees(C)
# Adjust angles to ensure they are in the correct range (0-360 degrees)
if A < 0:
A += 360
if B < 0:
B += 360
if C < 0:
C += 360
# Round angles to two decimal places
A = round(A, 2)
B = round(B, 2)
C = round(C, 2)
return A, B, C
def get_kuka_frame(self):
if self.frame is None:
# Ensure the frame is calculated
self.calculate_frame()
# Get the Euler angles
A, B, C = self.get_euler_angles()
return self.frame.Origin, A, B, C
def create_lin_command(self, X, Y, Z, A, B, C):
# Generate the KUKA LIN command string
E1, E2, E3, E4 = 0.0, 0.0, 0.0, 0.0 # External axes placeholders
lin_command = "LIN: X {:.2f}, Y {:.2f}, Z {:.2f}, A {:.2f}, B {:.2f}, C {:.2f}, E1 {:.2f}, E2 {:.2f}, E3 {:.2f}, E4 {:.2f}".format(X, Y, Z, A, B, C, E1, E2, E3, E4)
return lin_command
# Initialize the PlaneProcessor class with the input plane
plane_processor = PlaneProcessor(plane)
# Get the TCP pose values (X, Y, Z, A, B, C)
origin, A, B, C = plane_processor.get_kuka_frame()
# Extract X, Y, Z from the origin point
X = round(origin.X, 2)
Y = round(origin.Y, 2)
Z = round(origin.Z, 2)
# Create the LIN command
lin_command = plane_processor.create_lin_command(X, Y, Z, A, B, C)
# Output the TCP pose values and LIN command to Grasshopper
a = lin_command # LIN command
happy Roboting!
-bob
I am trying to get a little deeper into using python in combination with KUKA|prc for robotics :)
working with ChatGPT to create a class that takes planes and generates robot frames...
But its not going well :(
I have read that KUKA uses the Euler ZYX system to calculate the TCP orientation. This means that three rotations happen in a specific sequence to achieve the final orientation. The order is:
A rotation about the world Z axis
B rotation about the new Y axis
C rotation about the new X axis
Diving deeper to understand this I found the following site: https://www.mecademic.com/academic_articles/space-orientation-euler-angles/
Which is super interesting.
ok so i have a sample plane: O(0.00,0.00,0.00) Z(0.17,-0.17,0.97)
which when passed through the LIN motion component outputs: LIN: X 0, Y 0, Z 0, A 135.4, B 75.9, C 134.6, E1 0, E2 0, E3 0, E4 0
and when I pass through the following code generates: LIN: X 0.00, Y 0.00, Z 0.00, A 1.75, B 9.85, C 10.15, E1 0.00, E2 0.00, E3 0.00, E4 0.00
not sure whats gone wrong. any advice is appreciated!!! Thanks!!!
here is the python code (file attached):
import Rhino.Geometry as rg
import math
class PlaneProcessor:
def __init__(self, plane):
# Initialize with the input plane
self.plane = plane
self.frame = None
def calculate_frame(self):
# Deconstruct the plane to get its components
origin = self.plane.Origin # Origin point of the plane
x_axis = self.plane.XAxis # X-axis vector of the plane
y_axis = self.plane.YAxis # Y-axis vector of the plane
z_axis = self.plane.ZAxis # Z-axis vector of the plane
# Construct the frame using the origin and axes
self.frame = rg.Plane(origin, x_axis, y_axis)
def get_euler_angles(self):
if self.frame is None:
# Ensure the frame is calculated
self.calculate_frame()
# Extract the axes from the frame
x_axis = self.frame.XAxis
y_axis = self.frame.YAxis
z_axis = self.frame.ZAxis
# Construct the transformation matrix from the axes
transformation_matrix = [
[x_axis.X, y_axis.X, z_axis.X],
[x_axis.Y, y_axis.Y, z_axis.Y],
[x_axis.Z, y_axis.Z, z_axis.Z]
]
# Calculate Euler angles using the ZYX convention (intrinsic rotations)
# A is the rotation around the world Z-axis
A = math.atan2(transformation_matrix[1][0], transformation_matrix[0][0])
# B is the rotation around the new Y-axis
B = math.atan2(-transformation_matrix[2][0], math.sqrt(transformation_matrix[2][1] ** 2 + transformation_matrix[2][2] ** 2))
# C is the rotation around the new X-axis
C = math.atan2(transformation_matrix[2][1], transformation_matrix[2][2])
# Convert the angles from radians to degrees
A = math.degrees(A)
B = math.degrees(B)
C = math.degrees(C)
# Adjust angles to ensure they are in the correct range (0-360 degrees)
if A < 0:
A += 360
if B < 0:
B += 360
if C < 0:
C += 360
# Round angles to two decimal places
A = round(A, 2)
B = round(B, 2)
C = round(C, 2)
return A, B, C
def get_kuka_frame(self):
if self.frame is None:
# Ensure the frame is calculated
self.calculate_frame()
# Get the Euler angles
A, B, C = self.get_euler_angles()
return self.frame.Origin, A, B, C
def create_lin_command(self, X, Y, Z, A, B, C):
# Generate the KUKA LIN command string
E1, E2, E3, E4 = 0.0, 0.0, 0.0, 0.0 # External axes placeholders
lin_command = "LIN: X {:.2f}, Y {:.2f}, Z {:.2f}, A {:.2f}, B {:.2f}, C {:.2f}, E1 {:.2f}, E2 {:.2f}, E3 {:.2f}, E4 {:.2f}".format(X, Y, Z, A, B, C, E1, E2, E3, E4)
return lin_command
# Initialize the PlaneProcessor class with the input plane
plane_processor = PlaneProcessor(plane)
# Get the TCP pose values (X, Y, Z, A, B, C)
origin, A, B, C = plane_processor.get_kuka_frame()
# Extract X, Y, Z from the origin point
X = round(origin.X, 2)
Y = round(origin.Y, 2)
Z = round(origin.Z, 2)
# Create the LIN command
lin_command = plane_processor.create_lin_command(X, Y, Z, A, B, C)
# Output the TCP pose values and LIN command to Grasshopper
a = lin_command # LIN command
happy Roboting!
-bob
#26
Support / Re: KUKA PRC models block out ...
Last post by Johannes @ Robots in Architecture - June 25, 2024, 09:44:13 PMHello Chris,
That's weird, could you send me an example - ideally only baked planes, no logic or plugins - so that I can take a look?
Best,
Johannes
That's weird, could you send me an example - ideally only baked planes, no logic or plugins - so that I can take a look?
Best,
Johannes
#27
Support / KUKA PRC models block out gras...
Last post by WAAMMAN - June 25, 2024, 09:27:05 PMHello everyone,
Not sure if this is a documented bug, but it appears as though robots (KUKA DKP table shown here) block grasshopper previews (as well as the CPlane in rhino).
The previews are not actually blocked by the robot models, but the model rendering is applied over the previews and rhino objects?
It's difficult to describe, but the problem constantly necessitates for me to turn off the PRC Core preview so I can see the preview geometry and CPlane.
-Chris
Not sure if this is a documented bug, but it appears as though robots (KUKA DKP table shown here) block grasshopper previews (as well as the CPlane in rhino).
The previews are not actually blocked by the robot models, but the model rendering is applied over the previews and rhino objects?
It's difficult to describe, but the problem constantly necessitates for me to turn off the PRC Core preview so I can see the preview geometry and CPlane.
-Chris
#28
Support / Re: kuka prc simulation don't ...
Last post by Johannes @ Robots in Architecture - June 25, 2024, 09:19:59 PMHello,
Before we go into any KUKA|prc details, please ensure that the turntable is correctly set up. To do so, calibrate an Offset Base with three points, enter a Cartesian movement mode, and jog the E1. If the robot moves along with the turntable (keeping its position in relation to it), we can proceed to KUKA|prc.
In your problem description with the bust, it's unclear what the problem is to me. Could you please provide some more details?
Best,
Johannes
Before we go into any KUKA|prc details, please ensure that the turntable is correctly set up. To do so, calibrate an Offset Base with three points, enter a Cartesian movement mode, and jog the E1. If the robot moves along with the turntable (keeping its position in relation to it), we can proceed to KUKA|prc.
In your problem description with the bust, it's unclear what the problem is to me. Could you please provide some more details?
Best,
Johannes
#29
Support / kuka prc simulation don't matc...
Last post by luis.hernandezv - June 25, 2024, 08:02:17 PMHello there,
after a long period of time i was looking to using a turn table that we bought from a kuka distribuitor but it's not a kp1 v500 so instead i just used a custom turntable component on PRC. however the simulation from GH definition will not match the actual point that is uploading as a SRC.
i've been looking throug karl singline's tutorials on turntable settings but in his videos. the definition was a spiral contouring the bust of beethoven. this definition also wouldn't work for me beacause the robot would try to reach each individual point instead of letting the E1 turn the base. basically the robot would spin around clockwise and the turntable counterclock wise all through the code.
so i decided to try something a bit diferent. the attached file is a zig-zag definition on one face of the object so it would "atack" just 180° aproximatly from the front.
i do not know if i'm explaining myself but i attached the files aswell as my $machine.dat and config.dat as i suspect there is something wrong with my workvisual project as well.
after a long period of time i was looking to using a turn table that we bought from a kuka distribuitor but it's not a kp1 v500 so instead i just used a custom turntable component on PRC. however the simulation from GH definition will not match the actual point that is uploading as a SRC.
i've been looking throug karl singline's tutorials on turntable settings but in his videos. the definition was a spiral contouring the bust of beethoven. this definition also wouldn't work for me beacause the robot would try to reach each individual point instead of letting the E1 turn the base. basically the robot would spin around clockwise and the turntable counterclock wise all through the code.
so i decided to try something a bit diferent. the attached file is a zig-zag definition on one face of the object so it would "atack" just 180° aproximatly from the front.
i do not know if i'm explaining myself but i attached the files aswell as my $machine.dat and config.dat as i suspect there is something wrong with my workvisual project as well.
#30
Support / Re: why is tool orientation di...
Last post by Johannes @ Robots in Architecture - June 23, 2024, 04:48:30 PMHello,
You can switch the tool axis to Z in the settings if it annoys you. In general, using the X-axis makes the XY planes in GH easier to use.
But I understand that it's not an ideal solution in either way.
Best,
Johannes
You can switch the tool axis to Z in the settings if it annoys you. In general, using the X-axis makes the XY planes in GH easier to use.
But I understand that it's not an ideal solution in either way.
Best,
Johannes