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 - Xylotica

#31
Support / Re: Custom Turntable Simulation
April 01, 2022, 11:14:17 AM
The more I read the KUKA documentation, the less I understand the settings in KUKA|prc...

As shown in the attached illustration, the "ROOT" coordinate system is supposed to be at the base of the External Kinematic system, while in your sample file, the ROOT coordinates (2500,0,500) seem to correspond to the "FLANGE" coordinate system.
I suppose that the "BASE" (in your file : Base N°17) is the "OFFSET" coordinate system of the illustration.

In the KUKA documentation, I haven't found any explanation about how to define the FRANCGE coordinate system relative to the ROOT coordinate system.

Could you clarify ?
#32
Support / Re: Custom Turntable Simulation
March 31, 2022, 11:48:41 PM
KSS SI ?
Ok then. I'll look it up.

Attached are all my KUKA documentations.
I actually had this document, but "Offset base" yields no result.
The best keywords here are "External kinematic system".

Thanks for pointing me to the "KUKA Xpert" web page ; I didn't know about it.
I thought you were speaking of loging in Expert mode or something. :)
#33
Support / Re: Custom Turntable Simulation
March 31, 2022, 03:00:55 PM
I have the very same problem, and still don't understand this "Offset base" concept.
Where should the base be tagged as "Offset" ?
On the controller ? A search accross ALL my KUKA documentation yielded Zero result.
In KUKA|prc ?
#34
Support / Re: Turntable issue
March 30, 2022, 03:53:50 PM
QuoteAlso in industry a standard approach would be to move to a safe position,

The industry, for a long time, has been programming robots line by line.
The "Safe position" approach is a relic of those times.
Kinematic solvers / simulation tools such as yours allow to make smarter, adaptive toolpaths.

Quote"Relatively move external axis based on the current robot position as per the IK solver"

That's not how I would phrase it.
I want the ability to rotate an axis independently without having to set the value for the others.
The fact that KUKA did not allow the programming of such a simple action is not a tribute to their smarts.
That's where tools such as yours could shine even brighter.

#35
Support / Re: Turntable issue
March 30, 2022, 02:15:14 PM
Illustration.

I know how to fix this, but this shouldn't be a problem from the beginning.
#36
Support / Re: Turntable issue
March 30, 2022, 02:01:11 PM
QuoteIf you want to not rotate the coordinate system, you can also attach the "Dummy Axis" component. Let me know if there are issues, we fixed a bug recently that is not yet in the public release.

Well, no. In this case I DO need to rotate the coordinate system.

QuoteYou can extend both axis and Cartesian movement components to accept E1-E4.

Yes, of course !
I'm sending you my file.
Basicaly, I just need to rotate my table between milling zones orient the part in a more favorable way to the robot.
The issue is that, when I rotate the table, I don't want to set the 6 robot axis .
I could painstakingly do it by hand, reading the values from the analysis, using tags, etc... But that'll work only for a particular piece.

I want this to be parametric, because well, that's the point of using Grasshopper !
:)
#37
Support / Re: Turntable issue
March 30, 2022, 12:27:48 PM
Hi Johannes, thanks for your explanation by e-mail.
For the record, in case it can help someone, here it was :

QuoteWhen KUKA|prc is set up to use a turntable, then the root point in the turntable component marks the position of the turntable within the robot's global workspace, and the base in the settings is then no longer in relation to the robot base, but in relation to the turntable.
When you calibrate the base, it's therefore important to calibrate it as an Offset Base, rather than a normal one. The process with 3 points is the same.

Now, I've set up the root point and base properly, but when I want to ratate just the turntable, I am forced to set values for A1->A6 which is kind of a pain in the neck.
It rejoins my request for a way to set a particular axis angle without messing with the other ones.
I understand now that I can use two simulation components for that purpose, but I wish there was a more elegant way to achieve this.

#38
Hi Johannes,

I understand what you are doing here, except that you didn't turn off the analysis data in the second simulation component.
So you mean that if you replace that second simulation component by a custom C# component, it could make the simulation much more fluent ?

Hey ! I vote for that ! specially if that allows to make the simulation speed more accurate when running at 100%, to get a real feel for what's going to happen.
To me, this is a core functionality of KUKA|prc, as a simulation tool, and it deserves your love :)
#39
Hello Johannes,

I'm pretty much hampered by how slow the simulation playback goes.
Sometimes it's really like watching grass grow ; there's not much that can be learned from that in terms of simulation...

Couldn't there be a cheap hack to get this thing on ball bearings, because as soon as we hit the swamp, simulation speed is not accurate anyways (much too slow).

A pre-compute of all robot meshes ?
A stack of all the A1->A6 values ?

#40
QuoteYou can have as many Core components as you like in it
Well... problem solved ! I'll try that path...

Quotehowever things might then be easier via C# rather than Grasshopper.
Ha ha ! Not for me it won't.

QuoteLike the toolpath optimizing plugin did it
I never heard of that one... Where can I get more info on this ; sounds interesting.
#41
Quote"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...
#42
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 ?

#43
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
#44
Support / Re: Turntable issue
March 16, 2022, 03:36:17 PM
New issue with the turntable : I set the initial position of the robot with a 180° angle on the E1.
In the "External kinematics" tab, I set the "Undefined rotary axis position" to "same as previous value".
Then why does E1 reset to zero at the first occasion ? (see .src screenshot).

Isn't the initial position a valid definition of E1's angle ?

Then I added an "Axis move" at the start of the program, specifying E1=180° again ; same problem : at the first LIN instruction, E1 is reset to zero.
Finally, In the "External kinematics" tab, I set the "Undefined rotary axis position" to "fixed value"=180° : same problem.

How can I solve this ? If the solution is to toggle the external axis inputs in all my LIN components and set E1 to 180, it seems a bit rough...
#45
Support / Re: Turntable issue
March 15, 2022, 06:46:59 PM
I had unplugged the Frame/Base component from the "Base" input, and thought it had reset all the values to Zero inside the KUKA-prc main component...
I just can't get used to those values "hidden" in that component. To me, Grasshopper is about explicit values.
It's much better now that I've set the base to "zero"..

Thanks Johannes.