WISH : get axis values (1-6) at the end of a LIN command

[Xylotica]

I wish it was possible to extract current axis values from a LIN command.
This would allow to create an "Axis movement" command to "unwind" axis 4 and/or 6 : keeping all other axis values the same but re-setting 4 and/or 6 to zero.
I know I can retrieve them from the analysis, but trying to use it creates a recursive data stream (of course).
So there needs to be a component that runs the inverse kinematic engine before the main component (using the same base and tool inputs).

Or maybe there's a workaround I haven't thought of ...

Best

[Johannes @ Robots in Architecture]

Hello,

When you define the movement component, it does not have any information on the axis position yet (unless it is an axis movement ;)
Feeding that back is of course technically possible, but would need a lot of fighting against Grasshopper 's software architecture, that is just not made for this.
Thinking out loud you could have a window that shows you the axis positions of the currently selected movement component.
But that information becomes significantly less useful once you have multiple commands there.
So I am not sure if the effort/gain ratio is good enough to pursue that right now.

In general, I would rather look into defining the PTP turn values for such movements.

Best,
Johannes

[Xylotica]

Johannes,

A4 /A6 winding with LIN commands is a recurring problem for me, and I think it's worth looking for a solution.

I gave you a suggestion on how to implement the angle feedback : create a trimmed-down version of the main KUKA|prc component that would just do the inverse-kinematics.
It would have 3 inputs :
-LIN movements for which you want to know the corresponding A1->A6 values
-The BASE frame
-The TOOL parameters

An the output would be the A1->A6 angles.

Of course, having a "Single axis rotation" command in KRL would have solved the problem.
I wonder why KUKA didn't implement this : what could be more simple than ordering a single motor to turn a certain amount ?

Alternately, you could provide an "automatic un-winding" post-processor that would add the relevant AXIS movements in the .SRC file where needed...
Interesting challenge, isn't it ?

[Johannes @ Robots in Architecture]

Hello,

Thing is, you cannot do inverse kinematics from just the information of a LIN movement. LINs do not contain any information like status and turn for PTP movements.
Automatic unwinding sounds super dangerous for an unexperienced user who just ticks the box because they run into axis limits on A4 or A6 and then is astonished to see the robot just arbitrarily start rotating somewhere in the middle of the toolpath.

The best thing I can think of would be to allow the axis movement component to contain empty information, that is then filled from the previous movement. So if you don't set A1-A5 it takes it from the previous motion. That would theoretically be a solution for your unwinding, right?

Best,
Johannes

[Xylotica]

"The best thing I can think of would be to allow the axis movement component to contain empty information, that is then filled from the previous movement. So if you don't set A1-A5 it takes it from the previous motion.

Of course ! But doesn't that imply to run inverse kinematics, just to retrieve the A1-A5 from the previous movement ?
That's the whole problem.
If I could "convert" my LIN movements in corresponding axis values, I wouldn'tt be afraid to use that data to spot the places where my A4 and A6 play the reverse merry-go-round and automatically insert the proper AXIS movement to correct it.

In the attached case, KUKA's kinematic math falls in Euler's rotation trap and deals with the singularity in the most stupid way.
I won't wait for KUKA to figure out the existence of quaternions, but I sure can prevent this from happening if I can see it coming.

Would I be possible to have two KUKA|prc components in my definition : the second one using the analysis data of the first to add corrective and/or smarter commands ?
Only the second one would be used for generating the .src file, and no Grasshopper time travel would be required...

[Johannes @ Robots in Architecture]

Hello,

You can have as many Core components as you like in it, however things might then be easier via C# rather than Grasshopper. Like the toolpath optimizing plugin did it, that automatically simulated variations.
Otherwise you can try to assign the Analysis values via the Command-ID, I'd suggest tagging every movement and then using that tag to correct the output.

Best,
Johannes

[Xylotica]

You can have as many Core components as you like in it

Well... problem solved ! I'll try that path...

however things might then be easier via C# rather than Grasshopper.

Ha ha ! Not for me it won't.

Like the toolpath optimizing plugin did it

I never heard of that one... Where can I get more info on this ; sounds interesting.

[Johannes @ Robots in Architecture]

There you go!
https://www.parametriczoo.com/index.php/products/kukaprc-tool-path-optimizer/

Best,
Johannes