Messages

Hello,

Does it cause a problem, if the E1 value is repeated? Because if it's repeated, the extruder won't move during the travel move. Or are you using relative values for the extrusion?

Best,
Johannes

Hello Mohammad,

If you cannot attach a file here, please send me a example file (very compact, ideally with annotations what to look for, no plugins except KUKA|prc, please!) via email!

Thanks,
Johannes

Hello Mohammad,

Hmm... Not sure that I can follow. With normal planes, do you mean planes where the Z-axis is parallel to the normal vector of the surface at that point? What would you consider a tangent plane?

I would actually recommend against using splines because splines are not NURBS; they are geometry that is — to my knowledge — robot-specific. In other words, the robot creates an optimized curve based on the current machine state.
The spline preview in KUKA|prc is only a rough approximation.

Best,
Johannes

Hello,

Thanks, I have put together a quick example of how that could be achieved.
Note that there are always multiple ways to get somewhere, so this is only one quick version. Also, I wouldn't immediately deploy that program without double-checking. One thing I noticed is that everything looks super tiny. Did you consider that the robot always works in millimeters?

Best,
Johannes

Hello,

Could you please reduce the file to the specific question? At the moment, there are some planes towards the positive X direction, and at the same time, there is the stack of rotated bricks at the origin, making it unclear what you actually want to achieve. There is also a range of components from the "Robot" plugin that I haven't installed. The "Flip Plane X" component also seems to originate from there and would have to be replaced.

In your last post, you mentioned the starting point from where you pick up elements. Assuming that you are working with bricks, the starting point could be a grid of planes, assuming you have the bricks laid out next to each other. Alternatively, it could always be the same point if you have an automatic feeder, where, e.g., the bricks slide down a small ramp, and you always pick the brick on the bottom.

I'm happy to help you with the programming, but I need to know what you want to achieve. Therefore, it's important that you reduce the file to the essentials and possibly add some comments in the GH file via the doodle function or the panel component.

Thanks,
Johannes

Hello,

What are your "specific needs"?

I couldn't fully open your file as I was missing a few plugins, primarily the component for flipping the plane. But it seems like you were getting a different number of elements into the weave component. Consider duplicating the elements that are always identical so that you get the same number of commands for each step. There is also a separate Command Weaver in KUKA|prc, but it works similar to your approach.

If you can provide some more details on what you would like to change, I'm of course happy to help!

Best,
Johannes

Nice! For that project, we went the other way and distributed the beat between four robots: https://creativerobotics.at/ars-electronica-festival-2020/
But yes, if it's an individual installation, it's probably easier to simply finetune the speed, etc., manually than to come up with a fully integrated solution.

Best,
Johannes

Hello,

We did a surprising amount of musical projects, like this one (https://www.youtube.com/watch?v=he5iY_X-E5U—the video is out of sync often, but it played nicely and in real-time), and also performative projects (e.g., the one Karl posted at https://www.youtube.com/watch?v=C0kUZhFH4hc).

But unfortunately, there is no easy solution; for the e-guitar project, we developed a kind of custom notation system that allowed a non-programmer to time and fine-tune the sound in Grasshopper (followed by a lot of trial and error to get the timing right, but GH nicely supported such an iterative process). On the KUKA side there is a system for time-based programming called ready2animate, but it also has got its limitations and won't help you on an ABB robot.

For that performance (https://creativerobotics.at/underbody/), we used RSI (hard-realtime control on KUKA robots, i.e. one position every 4ms) to map the movement in real-time to the robots. I assume that ABB has a similar system. But hard-realtime can be a pain to deal with.

Hopefully, these pointers will also be useful for an ABB-based application.

Best,
Johannes

Hello,
The KR120-P is a rather exotic robot, never saw one of those myself. If you have got access to the member version - according to your email that should be possible - then you could put it in as a custom robot as a short-term solution!
Best,
Johannes

Hello,

Full access to the member section with the software and eBooks is unfortunately only possible for members of the Association for Robots in Architecture. See https://robotsinarchitecture.org/#membershipbenefits

Best,
Johannes

Hello,

Here's an example that I put together.
Personally, I would expect several edge cases that are not covered by my simple definition, but hopefully, it will help you with your definition!

Best,
Johannes

Hello,

Here is an example with a tool with multiple ends, but it could also use separate tools, of course.
KUKA|prc always uses the most recent tool, so after the tool change, the new tool will be used.

Best,
Johannes

Hello,

Well, that depends, you can change your tool (KUKA|prc Change Tool component) to another tool with a different tool number and XYZABC values (make sure they also exist on the robot controller!), or you can rotate the planes that make up your toolpath.

Two things to note: KUKA|prc by default works with X as the tool axis, which can be confusing especially to experienced robot users.
The ABC values are not "unique"; there are multiple combinations that express the same orientation. So don't be alarmed if you rotate a plane and, at a certain point, the ABC values make a large jump.

Best,
Johannes

Hello,
The posture values relate to the so-called "status" value, which defines the robot's posture through three bits. You should have gotten some KUKA manuals along with your robot; otherwise, you could search for "KUKA KRC manual pdf" or "KUKA KSS pdf" or something similar, and it will have a section on "Status and Turn."
In (my) practice, the essential options are 010 and 110, which (indirectly) set the orientation of A4.
Let me know if you cannot find the relevant PDFs, then I can send you a direct link!
Best,
Johannes

Hello,

The Rhino origin is always the origin of your base, so when the robot is at base 0, it will stand "on top" of the Rhino global origin. If the base has X set to 500, the robot will move back 500mm so that the base is 500mm in front of it.

I hope that makes sense! We wanted to ensure that the geometry does not "move around", but the robot does.

Best,
Johannes