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

#1
Hello Jesse,

From my perspective, I obviously love the software development aspects of robotics. However, developing a "universal" software as we're doing is tricky business-wise because the money lies in the applications. So my recommendation would be to develop tools that solve specific issues in specific industries and can therefore be sold for a lot of money.
Ideally, that would be for an industry that is relevant where you are living so that you can be there on-site, as for remote jobs, you are often compared with companies working out of low-wage countries.
Again, that is just the limited perspective from me and the people in my bubble.

Best,
Johannes
#2
Support / Re: Custom Variables
July 16, 2024, 01:41:31 PM
Excellent, thanks for the update!

Best,
Johannes
#3
Support / Re: Custom Variables
July 12, 2024, 10:03:58 AM
Hello,
What exactly would you like to achieve? The main purpose of a DAT file is a nicer separation of logic and variables (in my opinion, at least), so you could declare those variables also in the SRC file if that is needed. However, if the scope of the DAT file is global, you could access those variables also from your SRC program.
I am not sure how the Python script fits in here, does it generate the parameters for your printing process and saves them to a DAT file?
Best,
Johannes
#4
Hello,

There are a LOT of things here, I'm happy to help with the technical details but for the pathplanning you will have to be more specific.

1) A singularity is not necessarily terrible, usually the worst thing that could happen is that the robot goes into an E-stop due to excessive speed when (usually) A4 spins. I would not recommend using the Dynamic Value for a 2-axis positioner. I've attached an example (dkp_orientation.gh) that may be helpful for creating your own orientation strategy.

2) That's a very specific question that definitely needs a proper example, otherwise I would just guess what you are trying to achieve. I see what you mean with the inner and outer distances, but how to approach such a problem is very much up to your specific process. From your screenshot I'm assuming you are using additive manufacturing? So you could try to reduce the extrusion speed when the spacing is very tight.

3) An example for a custom DKP is included (customdkp_2.gh). We don't support it by default, so a scripting component is needed and you may have to adjusts the paths to the KUKA|prc libraries.

Best,
Johannes
#5
Support / Re: plane to frame with python for prc
July 02, 2024, 07:54:43 AM
Hello,

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:

            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
#6
Support / Re: plane to frame with python for prc
July 01, 2024, 05:51:04 PM
Hello,

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 KUKAprcLibrary.PRC_Commands.PRC_LINMove(Plane pln, double velocity = -1, string interpolation = "C_DIS")Let me know if there are any problems!

Best,
Johannes
#7
Support / Re: plane to frame with python for prc
July 01, 2024, 07:39:54 AM
Hello,

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
#8
Hello 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
#9
Hello,
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
#10
Hello,

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

#11
Hello,

Depending on the version, KUKA|prc may default to base 6, so I would double-check if base 0 is selected, as you don't want to use a base. Also the orientation of the tool might be wrong with it coming in from below, so please also double-check that the tool values (number plus XYZABC) are (close to) identical.

Or if your robot is on a rail, the Z=0 might be on the floor, rather than on the bottom of the robot.

Best,
Johannes
#12
General Discussion / Re: KUKAprc wit ABB?
June 05, 2024, 11:05:55 AM
Hello,

Unfortunately, that is not possible. We focused our efforts on supporting KUKA robots as well as possible; other robots are currently not supported.

Best,
Johannes
#13
Hello,

My apologies for the late reply, we currently have the ROB|ARCH conference going on in Toronto.
In the file you provided I was missing a few plugins, but I looked at the settings and you are using base 8 with all values at 0. Did you set base 8 as an offset base?
Can you check how base 8 is set in the config.dat file on the robot?

And regarding my previous post, is the turntable synchronizing properly?

Best,
Johannes
#14
Support / Re: 3d printing with kuka
May 22, 2024, 04:02:48 PM
Hello,

Not that I am aware of. You can have the robot trigger an output at a certain event, but as far as I know not before an event. Personally, I would add an extra point before the end of a path, shut down the extruder there, and then continue moving.
You could also try to post your question at places like the robot-forum, as it is not really KUKA|prc specific.

Best,
Johannes
#15
Hello Max,

So the intended behavior in KUKA|prc is that you calibrate an offset base (not a regular base) which is then kinematically linked with the robot. So when you go into base movement mode, switch to the E1 and move it, the robot should move along with it (assuming an offset base is selected).

From your description it sounds like this is happening, which would be good. But is there a mismatch between simulation and reality?

Best,
Johannes