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
Support / Re: Compound Return Error on IIWA
April 17, 2024, 08:49:52 AM
If nothing comes out of it, please send me the description and I'll follow up with some people at KUKA Germany.

Best,
Johannes
#2
Support / Re: Compound Return Error on IIWA
April 16, 2024, 05:36:04 PM
Hello,

We had a polishing process that would repeatedly (software, not hardware) crash (!) the iiwa after like 20mins, apparently some internal countdown expiring or something. We switchted it to a LBR14 and suddently it went away... While I like the iiwa a lot, Sunrise just isn't as mature as KSS (not a surprise) and to my knowledge, it's also no longer getting updates.
My suggestion would be to ask the KUKA hotline about that error, ideally they can provide a reason or at least a troubleshooting strategy.
Let me know if there is anything I can help with from our side!
Best,
Johannes
#3
Great, thanks for the feedback!
Best,
Johannes
#4
Hello,

I assume that the automatic solver keeps the values within a range and does not rotate infinitely. I'll have to look at that in more detail.
I've plugged in the code from the Custom Turntable Strategy example from the forum and it seems to work nicely!

Best,
Johannes
#5
Hmmm... We didn't mill a lot the past year, but I think having a wooden base onto which you can screw your timber objects is a good approach for generic objects! If you do many similar-sized, large objects it would definitely make sense to come up with a specialized solution, e.g., a metal plate with threaded rods onto which you can screw the object.

For our stationary milling, we use a welding table, which is nice with the many mounting options, but I don't think it's super convenient when you cannot access the mounting surface from below.

Best,
Johannes
#6
Excellent! Thank you for the feedback!
Best,
Johannes
#7
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
#8
General Discussion / Re: rotational_axis
April 08, 2024, 01:45:33 PM
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
#9
General Discussion / Re: rotational_axis
April 04, 2024, 09:07:25 AM
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
#10
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
#11
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
#12
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
#13
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
#14
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
#15
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