Path planning

[GOBLIN]

Does KUKA|PRC use ROS?
How the heck does it do path planning to show users what the robot will do?

[Johannes @ Robots in Architecture]

No, KUKA|prc does not use ROS, we have custom libraries for kinematics and code generation that do not require ROS. For pathplanning it builds upon the geometric capabilities of the visual programming environment Grasshopper.

Best,
Johannes

[GOBLIN]

I wish KUKA had better performance around singularity regions... Really an issue with the KRC4's on KSS 8.x.x
Ever had any luck navigating around them? Maybe we could switch to joint commands... But that is not ideal in the slightest.

Have you ever used Galapagos or similar to optimize a job location based on singularity outputs...?

[Johannes @ Robots in Architecture]

Hello,

Well, if you have got somehow similar products, then you can resolve many singularities by optimizing the orientation of the tool.

Regarding optimization: Sure, but that again is highly individualized, because optimization depends on degrees of freedom. Like for a milling process, you can optimize by rotating the tool around its axis, because the tool is rotating anyways. But that would not work for a process with a non-symmetrical tool.

With a turntable, you open up a lot of potential for optimization, but that comes with quite a bit of complexity.

The singularities are unfortunately a result of the kinematic layout of those robots...
So I cannot offer an easy solution here.

Best,
Johannes

[GOBLIN]

Johannes,

That is not our case - we work in the 3d printing industry.
Maximizing the size of a part put's the workspace through the entire reach bubble.
This generally encourages singularities. There are workarounds, usually sacrificing build volume....

Would there be a way to optimize a print job position/orientation based on the analysis output for singularity risk...?

We are working on getting a license now to have access to the analysis values.

[Johannes @ Robots in Architecture]

Hi,

Of course, that should be possible, the question is just what value to optimize. So thinking in Galapagos terms, the fitness function would be to minimize the amount of singularities, but what sliders do you modify?
But GH is nice in that these optimization setups are maybe not super fast to run, but very fast to setup. And the time-savings can be really significant.

Are you in touch with my colleagues in Germany regarding a commercial license?
Best,
Johannes

[GOBLIN]

True. There are definitely some clever ways to approach this... For now, just adjusting position and frame A rotation of the move planes.
I feel so silly for waiting so long to try Galapagos. It is so easy to use!!!

We are in touch. I think we will be wiring payment soon. We've been going back and forth for like 2.5 weeks......

We've been looking for some open-source slicer software - preferably something we can integrate into grasshopper. Python libraries ideally. COMPAS-dev caught our attention. Is there anything you'd recommend checking out?

[Johannes @ Robots in Architecture]

Hi, generally G-code should be pretty easy to import, especially with some help by the AI. You could even directly generate KUKA|prc motion commands - there should be examples around, if not, let me know.
If you want to generate the G-code directly within GH, I don't have any real suggestions regarding libraries, unfortunately.

Best,
Johannes

[GOBLIN]

Johannes,

It's not so much that I want or need Gcode - I mean the actual toolpath. Making our own custom Gcode flavors over here. Flavortown - Guy fieri style!

Just looking for like a python library with could do things like take a "slice" and do polygonal decomposition, or geodesic slicing, or something along those lines...

Anything to make life more easier. But not excessively easier. Hate that.

[Johannes @ Robots in Architecture]

I'm biased but it will be tricky to find a library that goes far beyond what Rhino/GH offers. Companies like ModuleWorks offer kernels that companies can implement into their software for additive or subtractive processes - but that will most likely be quite expensive.

A challenge with GH will be that it will get slow with too many points. Definitely makes sense to prototype it in GH and then move the code e.g. into C# components for higher performance.

Best,
Johannes

[GOBLIN]

You know, you're right. The whole problem with open-source stuff generally is that it's someone's massive brainchild that speaks Chinese and I have to teach it how to build a car in one month haha.

Yes we are printing large objects - so actually just having the points loaded sucks up a lot of processing power.
Thank you for the advice!

Also - I've seen there is a grasshopper 2, ever played around with it? Seems to handle text panels horribly!!!