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

#1261
Hello Alex,

Well, proper multi-robot support is hopefully incoming - I'm working with the RMIT guys and FabUnion on finding a nice solution.
I just checked again and robot|tool collisions seem to be working (see attached image). For a multirobot setup you would currently have to take the GEO output of the core component and then look for intersections/collisions, e.g. using the Collision One/Many component or the Mesh Intersection.

Hope that helps,
Johannes
#1262
Support / Re: Surface to Toolpath
August 04, 2015, 11:10:52 PM
Hello Bob,

It's important to mention that KUKA|prc is a "universal" tool and not a specialized milling solution. If your plan is to do mostly milling it definitely makes sense to e.g. get RobotMaster and MasterCAM (though they are quite expensive in the five-digits).
That being said it's totally possible to do additive fabrication, milling, wirecutting, etc. and quite many users utilize it exactly for that, look e.g. at the videos of Artis Engineering (not all are done with PRC, though) https://vimeo.com/user12374666

I've attached an example how the cylinder could for example work, the other surface wouldn't be any different. As mentioned in the other eMail, please send me an eMail for the temporary license (johannes@robotsinarchitecture.org).

Best,
Johannes
#1263
Support / Re: Adjusting Planes on each point
August 04, 2015, 10:55:07 PM
Hello Bob,

There you go, please find attached a quick definition. Also take a look at the files in the tutorial sections. Regarding the project, some things are important to keep in mind:

- If you're moving in a spiral, you will "wind" the robot up - every axis has got a certain axis limit, and if you keep turning in the same direction it will run into that limit. For some robots, you can set the axis 4 and 6 to infinite rotation, which would be helpful for your project (the Agilus for example can NOT rotate A4 infinitely as A4 contains the pressured air tubing).
- Even if the robot can move everywhere, the cable of your tool may wind itself around the robot.
- The "winding up" is not simulated in the "free" KUKA|prc, I would recommend taking a look at the member version, for which I can issue you a temporary license. Just send me an eMail.

All the best,
Johannes
#1264
Support / Re: Varying speeds
August 04, 2015, 10:44:45 PM
Hello Alex,

Well, the usual way is to split the path into several segments as you mentioned - any particular reason why you want to avoid that?
It should be possible to adjust the speed while a program is running, e.g. via an analogue input if that is what you're after! If I remember correctly, $OV_PRO is the variable that controls the override speed (in percent, like you set it at the control panel)!

All the best,
Johannes
#1265
Support / Re: Adjusting Planes on each point
August 01, 2015, 03:09:36 PM
Hello Bob,

I've quickly put together an example how that could work, see attached files.
It doesn't yet include any robot-specific code as I don't know which version of PRC you are using. If you're using the old PRC version, right-click the LIN-movement component to switch it to using planes as the input geometry.

Hope that helps!
Best,

Johannes
#1266
Hello Joanne,

There are a number of reasons why that could happen - but first of all, are you using the member version or the regular version of PRC? We did quite a few improvements to the robot simulation in the new PRC so that it's much more accurate now.

Ideally also send me the file where the problem occurs!

Best,
Johannes
#1267
Hello,

That sounds interesting! So you basically want to create your own PRC for a hacked Mitsubishi robot?
Seeing as you've got full control over the controller and IK, you probably have to define some format how the control data for the robot should look like, and then represent it in Grasshopper. In PRC we basically "queue up" the LIN, PTP, SPL, etc. commands and the core component then generates a control data file that can be read by the robot.

For developing GH-components, you can either use .NET (VB.net or C#, can compile into DLLs/GHAs) or Python.

Best,
Johannes
#1268
Support / Re: Surface to Toolpath
August 01, 2015, 02:35:36 PM
Hello Bob,

Hmm... Let's make sure that I got that correctly: By "complex surface" you mean polysurface, i.e. multiple joined and possibly trimmed surfaces?
We've done quite a few milling projects with "native" Grasshopper, and while it is totally possible to create your own surfacing and roughening (usually more difficult) code, it's quite tedious and slow, as regular milling software also takes a few seconds to minutes to calculate toolpaths.
From my experience - if you don't mind the slight loss in resolution it's easier to deal with one mesh, rather than many (trimmed) surfaces. At the end you end up with polylines anyway, so using meshes instead of NURBS isn't that bad.

So if you e.g. want to mill hundreds of similar objects it makes sense to code it yourself in GH, otherwise (e.g. for single objects that you want to mill) I would recommend to use CAM software to generate the toolpaths and then turn it into robot code through PRC. Natively we support SprutCAM (which is also free for universities and students) but it should work with most CAM code.

It's a feature of the member version, but I can issue you a temporary license!

All the best,
Johannes @ Robots in Architecture
#1269
Hello Mavrick,

I wouldn't call Delcam and KUKA|prc "competitive software" - with Delcam you can do milling etc., while you can use KUKA|prc to do nearly anything - take a look what e.g. Artis Engineering is doing in Berlin: https://vimeo.com/user12374666
So for milling it definitely makes sense to use specialized software like Delcam, MasterCAM/RobotMaster, etc.!
You can of course still do milling with KUKA|prc quite nicely, either by programming your toolpath-strategies yourself or by importing G-Code, e.g. from SprutCAM. We recently added a functionality to output positions in a format that can be read by KUKA CAM.Rob for very large filesizes.

So to sum it all up:
Delcam = specialized milling software
KUKA|prc = general parametric robot control software (but can also do milling)

All the best,
Johannes @ Robots in Architecture
#1270
Support / Re: Functions and Subprograms
July 04, 2015, 06:53:01 PM
Hello Matthias,

Let's deal with that directly via eMail, if that's alright for you.
I have some ideas, e.g. an option for the Custom KRL component that puts the code outside the regular KRL...

Best,
Johannes
#1271
Support / Re: Functions and Subprograms
July 03, 2015, 04:22:40 PM
Hello Matthias,

Hmm... At the moment I cannot think of a really easy way to do that. First thing that comes into mind is that you expose the filename and save option (by right-clicking the Core component and selecting the option) and then adding the subprograms "manually", i.e. by reading the .src file (via Read File component), adding the relevant lines, and then resaving it.

But do the interrupt subprograms really have to be parametric? I'm mostly curious about the application...!

Best,
Johannes @ Robots in Architecture
#1272
Hello,

This forum is related to KUKA|prc, which is a different product from KUKA SimPro. Here is the link to the KUKA.SIM Helpdesk: http://www.kuka-robotics.com/en/products/software/kuka_sim/kuka_sim_detail/PS_FAQ_KUKASim_Kontakt_Detail.htm

Best,
Johannes @ Robots in Architecture
#1273
Tutorials / Re: Surface Milling Tutorials
June 22, 2015, 06:08:36 PM
Hello Nate,

I've quickly thrown together a few examples how that could work, see the attachments of this post.
It covers a few possibilities, e.g. following the isocurves of a surface or projecting contours onto a Brep. Just disable the preview of the examples that you are not interested in, when you open the file there will be several robots visible at the same time.

Hope that works, let me know if you get stuck anywhere! I can also issue you a brief trial license of the current member version.
Best,

Johannes @ Robots in Architecture
#1274
General Discussion / Re: Kuka and Arduino
June 03, 2015, 06:22:21 PM
Hello Ben,

The WorkVisual side is easy to troubleshoot (at least if you've got regular Beckhoff modules) - you just go to Display/IO, go to the output tab, select the output and then (while pressing the confirmation button on the back of the smartPAD as if you were moving the robot) click "Value". This should now toggle the state of the output, and you should see a light on the Beckhoff module go on or off. If nothing changes, there is probably some issue with the IO Configuration in WorkVisual.
On the hardware-side you have to get the voltage of the Beckhoff digital output (usually 24V) down to either 5V or 3.3V, depending on the Arduino. There are countless ways to adjust the voltage, personally I like the small step-down modules that cost like 4USD and allow you to adjust the voltage by turning a small screw (variable resistor). Alternatively you could e.g. connect the output to a relay that can be switched by 24V DC.
Please mind that I'm most definitely not an electronics expert myself (which is why I use 4USD step-down adapter rather than 30 Cents of resistors) but it worked for us ;)

Of course be sure to measure the voltage before connecting the Arduino!

Best,
Johannes @ Robots in Architecture
#1275
Awesome, nicely done - and thank you for sharing!
The axis calculations in the new PRC are quite a bit more reliable (i.e. the entire process is simulated so that you can see when the robot is e.g. "winding" itself up via the A4 or A6). If you want to give it a try I can send you a temporary license, just send an eMail to johannes@robotsinarchitecture.org.

Best,
Johannes