Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Johannes @ Robots in Architecture

#31
Support / Re: Parametric speed value for LIN movements
February 18, 2024, 10:11:46 PM
Thanks a lot for the feedback, glad that I could help!
Best,
Johannes
#32
Support / Re: Parametric speed value for LIN movements
February 16, 2024, 10:14:28 AM
Hello,

What is shown in the screenshot is not the KRL output, but the string representation in Grasshopper.
So just like when you plug a point object into a panel, it says {0.1;0.5;16} or so. Within the data object, there is more data - like the speed - than is shown in the panel.
When you look into the generated KRL file and search for "$VEL.CP" you will find numerous speed changes.
But why would you expect a speed change at every line? In your GH script you are providing ca.11000 planes and ca. 200 speed values, one per data tree it seems. Some speed values are identical, in which case they are not output.

Best,
Johannes
#33
Support / Re: Roboteam example
February 14, 2024, 02:39:59 PM
Hello,

Regarding the planes in the Analysis component, there is an ID output for every position and if it's an integer (10) then it's a programmed movement and if it's a float (10.43) it's interpolated. Maybe that could help a bit.

For the kinematically linked base, I guess that you could simulate that by transforming the positions according to the other robot's movements, though, of course, that would mess up the KRL code as the positions would be in the global coordinate system and not in the other robot's base. So I think that would require two steps, one for code generation and the following one for simulation, with the appropriate transformations.

We are currently in the process of a full rebuild of KUKA|prc, and this feedback is very important to me to decide how to lay out the software architecture. But within the context of the current version of KUKA|prc, unfortunately I don't think that it's feasible for me to integrate the linked base any time soon, especially as we don't have a RoboTeam setup ourselves...

Best,
Johannes
#34
Support / Re: Roboteam example
February 05, 2024, 02:14:27 PM
Hello Alex,

You can right-click the Core component to set the base dynamically.
It's definitely possible to mock something like this up, however you might have problems with the normalized simulation slider. Because when you change the base, the toolpath changes and through that the time changes.
You may want to provide a single movement out of the toolpath, or have KUKA|prc generate all movements for one robot and then generate the corresponding movements for the other robot. That might also work fine via the Analysis component.

Regarding that becoming a feature: The annoying part is the communication between two components in Grasshopper. Of course it is possible in the "background" (as it is already doing), but the more such features there are, the less transparent the dataflows become. At least in my opinion.

But I'm very open to suggestions, how that could be implemented!
Best,
Johannes
#35
Tutorials / Re: DKP 400
February 02, 2024, 02:59:08 PM
Hello,

I would recommend that example to get started, and then you could expand it with the second degree of freedom of the DKP: https://forum.robotsinarchitecture.org/index.php/topic,822.0.html
If you provide me with proof of your member access (e.g. sending me an email from your university/company email address) I can unlock the member section for you.

Best,
Johannes
#36
Tutorials / Re: DKP 400
February 02, 2024, 12:00:27 PM
Hello,

You need a membership at the Association for Robots in Architecture (or a commercial license of KUKA|prc), having a license of Rhino is not enough. I am not aware of any specific DKP400 tutorial, so it would help to know what you would like to achieve.

Best,
Johannes
#37
Tutorials / Re: DKP 400
February 01, 2024, 09:41:38 AM
Hello,

Congratulations on your first steps with the robot! Regarding the DKP, in KUKA|prc it is implemented that it basically rotates your base (with an optional offset, if the center of the base is not in the center of the DKP).
So, you program your path normally and then add the rotation, usually to improve reachability. There is an automatic algorithm for it in KUKA|prc, but it is rather basic, so for more complex projects, you will probably define your own strategy to set the external axis value. You can show the inputs for external axes on any movement component by right-clicking it and selecting the relevant options - assuming you have got access to the member version through your university, as external axes are not supported in the free community version.

Best,
Johannes
#38
Support / Re: turntable with parametric Root Frame
January 30, 2024, 07:41:20 AM
Hello David,
You can do that with C# scripting, the component itself currently does not support it.
Attached is a related example. You see how you can get the external axis object, its rootpln property should be what you are looking for. Just be aware that the plane is not a Rhino.Geometry.Plane but a KUKAprcCore.Geometry.Plane. KUKAprcGH.PRC_GH_Methods has got a method to turn your Rhino/GH plane into a KUKA|prc plane.
Best,
Johannes
#39
Support / Re: Roboteam example
January 25, 2024, 03:05:26 PM
Hello Alex,

It's still weird why that would cause an error message, but I'm happy that it got resolved!

Regarding the PTP, it just avoids a lot of problems, because you cannot set the posture of the robot via a LIN movement. So in the settings via the Initial Posture that needs to be actively set. You can avoid it by manually setting a PTP position. But going from the start position to the first position in a straight line usually leads to problems with singularities etc.

Best,
Johannes
#40
Support / Re: Roboteam example
January 25, 2024, 09:32:40 AM
Hello Alex,

For one robot, you have the "Hardcode Tool and Base" option (in Advance/Code) enabled, could you try disabling it?

Thanks,
Johannes
#41
General Discussion / Re: rotational_axis
January 17, 2024, 03:51:33 PM
Hello,
The first step is to get the root point of your turntable. Currently, it is set to 1500,0,0 (via right-clicking the turntable component). I guess that is not right.
Then when you calibrate the Offset Base, you will get values that are in relation to your positioner. So if the base origin is 10cm above the positioner, you will get something like 0,0,100 for XYZ.
Your current values seem a bit strange, because they have got a 2m offset in X and the other values quite low. Are the robot and the positioner more or less on a shared plane in Z?
In any case, unless you are working with a HUGE positioner, a base with 2000mm distance from the root point of the positioner is not really feasible, the values will be much lower.
Hope that helps with troubleshooting!
Best,
Johannes
#42
General Discussion / Re: robot milling
January 16, 2024, 05:36:27 PM
By default, KUKA|prc generates a new file when the input changes. You can right-click the KUKA|prc Core component and enable the option to expose the file name. You now get an extra input for the file name. This could now include the current date or for example an incrementing number.
Just be aware that the file name is also used for the internal project name, so don't use any empty space, special characters or a number at the start.

So now you change the start position in Grasshopper and get a new file to run on the robot.
Is that what you are looking for?

Best,
Johannes
#43
General Discussion / Re: robot milling
January 16, 2024, 02:04:47 PM
Sorry, it's still not clear to me what you want. Do you only want to change the starting position of the toolpath or the entire toolpath?
Either is easy to do in Grasshopper/KUKA|prc, the question is how to get it to the robot. Are you using mxAutomation? Or is it OK for you to manually copy a file to the robot?

Best,
Johannes
#44
Support / Re: Roboteam example
January 16, 2024, 02:02:01 PM
Hello,

Sometimes it needs a re-compute in Grasshopper, do that and then move the slider.
You can change the root point of the robot via the Custom Robot component. Plug it in as a reference and change the root point.
What is not supported is that when one robot moves, the second robot is constrained to it, i.e. it follows its movement.

Best,
Johannes
#45
Hello,

That's not a problem, should be done in just a few lines of code in the sps.sub - the program that runs cyclically in the background. Something like:

IF $VEL_ACT > 0.0 THEN
$OUT[1] = TRUE
ELSE
$OUT[1] = FALSE
ENDIF

Of course I haven't tested it. Consider making a backup before changing important files like the sps.sub. Or run an additional SUB program if your robot supports it!

Best,
Johannes