CIRC command unable to point constantly at center

[bigdeer]

Hello everyone!

I am using Trail version 2016.3.31, and I have some problem creating a circular movement. Here it is:
   
At first I didn't know the CIRC command and I used SPL command to create a spline close to a circle.
This works fine like the GIF below:


But then when I zoom in I found the pin move like this:


I divide the arc into 100 points, arc radius is 155mm, and robot arm is AGILUS R1100.
The black circle is how I measure the pin displacement, the circle radius is 3mm.
In this case if I divide the arc into 100, the accuracy will be 3mm/150mm.
If I divide the arc into 1000 points, the accuracy will be increased, and the displacement will be less than 0.1mm.
Which I think  is OK. But I am not sure if a 1000 division number will reduce the speed of the whole system.


After then I found there is a CIRC command, and it seemed more reasonable than a 1000 division Spline.
I made the GH definition like the picture below:

But the final result is like the GIF below:


Then I checked the PDF named <KUKA System Software 8.3 Operating and Programming Instructions for End Users>
And I found some description like that:


So in this case I assume that no matter what tool I use (I did not try kuka official tool), I can not control the point direction through out the arc, with auxilary plan in GH.

After some research I found this Youtube video:
https://www.youtube.com/watch?v=owyy1g1FHMA
I clipped the gif as below:


I think this kind of "fixed pointed" arc movement is very common in robotic arm, and I believe the arm in this video did not use a 1000 division Spline, nor did it encounter some direction problem like my CIRC command.

I am a little confused now.
Is there anything I am missing? Or did I do something wrong.
Please help me.
Thank you very much!

[Johannes @ Robots in Architecture]

Hello,

The trial version is now nearly 3 years old and quite outdated.
If you want to give it a try with the most recent version of KUKA|prc send me an eMail (johannes at robotsinarchitecture.org).
Circular movements also have several different orientation strategies like #VAR, #PATH, etc.
The jitter in the SPL may either be rounding problems or spline interpolation through an identical point. But as I wrote, it's an old version, I'll need to check if that is a bug that still exists.

Best,
Johannes

[bigdeer]

Hello Johannes, nice to meet you!
Thank you very much for your reply! It really helps.
I would like to have a try at the latest version. and I had send email to you. Please check!

[bigdeer]

Hello,

The trial version is now nearly 3 years old and quite outdated.
If you want to give it a try with the most recent version of KUKA|prc send me an eMail (johannes at robotsinarchitecture.org).
Circular movements also have several different orientation strategies like #VAR, #PATH, etc.
The jitter in the SPL may either be rounding problems or spline interpolation through an identical point. But as I wrote, it's an old version, I'll need to check if that is a bug that still exists.

Best,
Johannes

Hello Johannes!

I have received the latest version and the license. Thank you very much!
But I still can not figure out how to use VAR or PATH command to set orientation in circular movement.
Would you please give me some advice or hint or examples?
I think I should use "combine command" to combine a CIRC and something like VAR or PATH, but I am not quite familiar with KUKA command.
So I decide to check the KRL output for a existing command and do some backward research, hope to find some clue on the command system.

Then I find out that the analysis output did not output anything, neither did the analysis component.

I have checked at this red arrow but still got nothing.

[Johannes @ Robots in Architecture]

Hello,

Thanks for the feedback, you need to activate the "Output Analysis" option in the Advanced options first.
That is not clear, we will fix that in the next release!

And Circs are currently set to #VAR, there isn't an option at the moment to change it.
You could modify the SRC file, but then the simulation wouldn't be accurate.

Just a remark regarding outputting KRL through the Analysis component: Grasshopper can get really, really laggy when you have a text panel with thousands of lines of text, like a KRL program. So it's not KUKA|prc's fault when it gets slow.

Best,
Johannes

[bigdeer]

Thank you Johannes! I did things according to your instructions and the KRL is ready.
Now I can do some research on these commands.
Here is the procedure: I hope these pictures can be some kind of tutorial to new users.

[Johannes @ Robots in Architecture]

Hello,

Thanks for sharing the screenshots! We'll auto-activate the "Output Analysis Values" option in the next release.
The default behavior is that KUKA|prc generates the *.src file in the background, with the project name and directory as provided in the first page of the settings. The output within GH is mostly meant for special cases, where you e.g. need to do extra edits to the code.

Best,
Johannes

[bigdeer]

Hi Johanness!
Thank you for your help in the past few days!
I just found out that I can not define the CIRC_TYPE with KRL "CIRC_TYPE=PATH" as the picture above.
After the "KRL to command"  there is still this command, but after the KUKA core and the analyze, I found that the command disappear.
Does that mean I can not do what I want with CIRC command at all, and I will have to use a Spline?
If you have other idea please let me know.
Thank you again!

[Johannes @ Robots in Architecture]

Hello,

I'm not sure how you wired that up, can you send me the file?
Please be aware that data input into Custom KRL gets written into the *.src file, but is not simulated.
And no lines should disappear...

Best,
Johannes

[bigdeer]

Thank you so much!
Here is the file.
You can put the 1.src file in the same folder as the GH file, and GH can read it.

[Johannes @ Robots in Architecture]

Hello,

I don't really understand what you did there - you took a *.src file and embedded it into a Grasshopper program? KUKA|prc needs at least one movement component, I'll need to make sure that a single Custom KRL component triggers an error message from now on.
KUKA|prc will not simulate the contents of a Custom KRL component, it's mostly for e.g. triggering specific variables etc.
So you could make a Custom KRL component with $ORI_TYPE=#PATH but it wouldn't be simulated.

Hope that makes sense!
Best,
Johannes

[bigdeer]

I am not sure I got the correct understanding.
My understanding is :"There must be one component like CIRC, and I can add my own KRL to it"
Is my way correct? Because I found it look like the same as before

[Johannes @ Robots in Architecture]

Hello,

Something like in the screenshot should work, but it will not be simulated.
So while it looks identical in the simulation, it will work differently on the robot - which can be dangerous.

Best,
Johannes

[bigdeer]

KUKA|prc will not simulate the contents of a Custom KRL component, it's mostly for e.g. triggering specific variables etc.

If you look into my GH file, it will stimulate the circle movement successfully, but it did not follow the correct direction because "circ_type=path" did not work.

[bigdeer]

Hello,

Something like in the screenshot should work, but it will not be simulated.
So while it looks identical in the simulation, it will work differently on the robot - which can be dangerous.

Best,
Johannes

I guess that there is not way to control a CIRC movement and make the direction pointed at the circle center at all, with KUKA pro.
The only way for me is to use Spline.
If this is the case then I will use Spline for my stimulation.
Thank you Johannes! Please confirm this for me, I have been stuck in this for many days and I really hope that there is some kind of way to control a circle perfectly.
But if not, I am OK with Spline.