Hello there.
Looking for an example here. I want to make something generalized which solves for not only E1,E2 just based off frames, but also ABC - for one of our on-board tools.
Has anyone created such a generalized solver?
Simply hand the frames and angles are calculated to say, keep a tool vertical, while table pitches and rotates.
I'm having a great time trying myself, but I'm afraid there are maybe some fundamentals I'm missing here, mainly in what to compare for the tool angles in 8 axis operation.
Hello,
I'm not sure what you mean by ABC, but keeping the table vertical shouldn't be too hard.
Just out of curiosity, what is the advantage of using the turntable, rather than just having the tool move around a bit more? Is there any process-related reason for the tool to stay vertical?
Best,
Johannes
Johannes, thanks for the reply.
By ABC, I refer to the tool angles.
I do WAAM with KUKA PRC. Necessary to keep welded area upright in some cases because welding creates newtonian fluid.
We are interested in having an open tool angle solver so we may run a slightly modified toolpath in parallel.
We can solve for moving the table to keep the tool vertical, but reliable and robust tool angle calculation for 8 axes has eluded us for a while now.
Hmmm... I'm still not sure if I understand it correctly. Your application itself makes sense, of course. So you are currently using the E1/E2 of your DKP positioner to keep your tool parallel to the World Z. But what do you mean by a "tool angle calculation for 8 axis"? Because your robot plus 2 external axes would be already 8 axes?
Best,
Johannes
".... But what do you mean by a "tool angle calculation for 8 axis"? Because your robot plus 2 external axes would be already 8 axes?"
We are in a position where we would benefit greatly from performing independent tool angle calculation for a toolpath using 8 axes.
The tool angles in 8 axis printing change in a way we've had a hard time deriving.
The math is hard to figure out a general solution for!
Sorry, I'm still stumped.
I mean a robot position in space has got 6 DOF - position and orientation. The extra 2 DOF help you to optimize reachability or other factors, but you basically end up with an infinite amount of solutions for every position. Is that what you mean with the generalized solution? Because there really isn't one, you can just optimize for some parameters that are then probably very particular to your use-case and not universal...
Best,
Johannes
Understandable - let me try to clear things up.
Luckily, we are not trying to do something like joint solutions.
I only say 8-axis to imply we are using some level of coordinated motion, with a coupled base frame to a table that tilts and rotates.
Solving for tool angles is a challenge, especially in that scenario. When the base frame is tilted and rotating, the tool angles are dynamic the entire time.
Up until now, I've really just been trying to calculate the ABC angles in grasshopper, with vanilla component blocks, looking at the Cplane and tool frames we want to move to. The solvers I've built always seem to just be special case solutions....
Let me put my question in different words:
When finding the rotation angles of the tool frame to the base, is there a correct order to derive them?
Or, are there conventions of how to arrive at the ABC (Rz, Ry, Rx)?
Hello,
About going to ABC angles, attached is a way there and back again using KUKA|prc's internal methods. There are plenty open-source solutions around as well that you could use.
Or ask your LLM of choice, something like that brought a result that looks plausible to me in ChatGPT: "Create C# code that turns a coordinate system, defined by an origin point, an X-axis and a Y-axis (each Vector3) into XYZABC values in a way that works with a KUKA robot."
I was looking for my really old Grasshopper code for XYZABC calculations from like 16 years ago, but I couldn't find it... Sorry!
Best,
Johannes
Much appreciated Johannes.
I didn't know there was a KUKAprcCORE library to use!!
16 years ago... That's awesome man!
Feeling old ;)
But it was just using GH components, which made it somehow interesting to modify and play with. But pretty slow.
If you go deeper into scripting, take care that KUKA|prc wraps its classes into GH-specific classes for transport within GH.
Attached is a simple example!
Best,
Johannes