Messages

Hmmm... Interesting! If you come across anything that might be a bug with KUKA|prc, please let me know, e.g. via johannes@robotsinarchitecture.org
Best,
Johannes

Hello,

You have to set the right base number and base XYZABC values in the KUKA|prc settings. As you are using a Custom Tool, go into the Custom Tool settings and set the right tool number and tool XYZABC values.
Finally, you can try to enable "Smooth Simulation" in the KUKA|prc Settings/Simulation Settings to see interpolated positions as well.
Now, if the simulation looks fine it *should* also work on the real robot. From your screenshot it seems that you've still got the default tool from the turntable example active.

Finally, what you can try to troubleshoot: Write down the XYZABC values of the first LIN position, activate the right tool and base, and then try to manually move the robot to that position. That should give you an idea what's wrong.

Best,
Johannes @ Robots in Architecture

That's actually good news as it means that the syntax is working. Now you have to troubleshoot to find the problem. What could be wrong...
...do you use the same tool/base number and XYZABC values on the robot and simulation?
...is the root point of the rotary axes set right? Right-click the component and set it like the calibrated turntable.
...through your editing you have set the linear axis E1 to 0.0, can the robot reach the rotary axis from there?

Then it should work. Please mind that I'll be out of the office the next days, so support may be slower!
Best,
Johannes @ Robots in Architecture

Hello,

That's most likely the problem. For the moment, the easiest way is probably just to do a search/replace on the KRL file.
E.g. search for "E1" and replace all with "E2", then search for "E2 0.0, E3 0.0" and replace with "E1 0.0, E3 0.0". I may be mistaken, but if I remember correctly the KUKA doesn't worry about the order of variables, i.e. if its XYZ or XZY.
On the long term, you can reconfigure the external axis from E1 to E2, or wait for a future KUKA|prc release for which we are planning to support more than one external axis.

Best,
Johannes @ Robots in Architecture

Hello,

Well, the tool is as accurate as you draw it - you can of course e.g. constructively find the accurate TCP, or even work backwards from the XYZABC values you got when you calibrated the tool on the robot.
On the other hand, a simulation is never going to be 100% accurate anyway, as also the physical robot is probably not 100% identical to the public 3D model, with some additional, internal calibration data ensuring accuracy on a "real" robot..

In the image, the mesh geometry that you have at the global origin is basically the source geometry for the tool (you can hide it in Rhino). It is then moved to the right position according to the robot's axis values and the tool's XYZABC values.

Hiding the robot works as with any Grasshopper component, i.e. right-click and disable preview.

Best,
Johannes @ Robots in Architecture

Hello,

With global origin I'm referring to the actual global origin of Rhino, not that of an arbitrary construction plane.
Just move the gripper manually to the global origin of Rhino, as I did in the modified file. When looking at your screenshot, the gripper seems more or less in the right position. I think I set the TCP of the gripper to the back of its clamps, if you want it to be at the front of the clamps, just move the gripper geometry and adjust the Z-value accordingly (i.e. measure the distance between zero point and the flange-mounting point of the gripper).

Best,
Johannes @ Robots in Architecture

KUKA|prc assumes the TCP of a custom tool geometry to be at the global origin of Rhino. On the robot you have to calibrate the tool to get the right XYZ and ABC values. The KUKA manual guides you through all the calibration steps (e.g. first get the right XYZ offset from the flange via "XYZ-4 Point" and then the ABC values via "ABC World").

Best,
Johannes @ Robots in Architecture

Hello,

You rather overcompensated by putting in rather arbitrary values in the tool settings and the moving the tool in space. I've fixed the file, take a look at the attachments.
Basically, it's important to remember that there are several ways how to calibrate a tool, especially in regards which tool axis is used (by default X).
So for now I've put the Tool Center Point (TCP) of the gripper to the global origin with X being the tool axis. As the tool is normal to the flange, B=-90, and A and C = 0.
The TCP is 255mm away from the flange, and if you take a look at the KUKA manual or the custom tool illustration, the axis normal to the flange is Z. Therefore, Z=255 and X and Y = 0.
One more important thing: You set the tool nr 0 for the tool - this is a very bad idea, as the tool 0 should be the flange (I'm personally unsure if you can even change it easily) with 0/0/0/0/0/0 for XYZABC. Set the same number and same values as you got when you calibrated the gripper at the robot. If you really got X=-1390, Y=430, and Z=-2180 for the tool, I'm quite sure that there is some error - that tool center point would be somewhere near the robots root point.

Hope this helps!

Best,
Johannes @ Robots in Architecture

Hello,

Excellent, I've replied to your eMail. It's a very nice setup you have there, just be advised that at the moment, KUKA|prc only supports one external axis. We are working on a new version that is much faster, more accurate, and supports more external axes and expect an early member version to be published sometime in very late 2014, early 2015.

Best,
Johannes @ Robots in Architecture

Hello,

Glad you figured it out! When you posted it was very early morning here, so I didn't see the posts until now.
I'll get back to your eMail in a few minutes!

Best,
Johannes @ Robots in Architecture

I believe the pick and place example already uses the Custom Tool component, so just plug in your tool geometry as a single mesh (i.e. mesh it, join it, and ideally use ReduceMesh to reduce its size = increase the performance). Then double-click (or right-click) the component to get into the settings and enter the according XYZABC values. If you've already calibrated the tool at the robot then you can take these values, otherwise take a look at the explanatory graphic near the XYZABC values, i.e. with Z+ direction being the normal of the flange, and X+ pointing downwards.

Best,
Johannes @ Robots in Architecture

Hello,

Well, this is something robot-related, i.e. nothing that is special to KUKA|prc. With your robot you should have received a DVD with all the PDF documentation, look especially for the KUKA System Software.

Here's the official definition of C_DIS:

A translational distance can be assigned to the variable $APO.CDIS. If the approximate
positioning is triggered by this variable, the controller leaves the individual block contour, at
the earliest, when the distance from the end point falls below the value in $APO.CDIS.

And here is C_VEL:

A percentage value can be assigned to the variable $APO.CVEL. This value specifies the
percentage of the programmed velocity ($VEL) atwhich the approximate positioning process
is started, at the earliest, in the deceleration phase of the individual block. The component
which, during the motion, reaches or comes closest to the programmed velocity value, is then
evaluated in terms of translation, swivel and rotation.

Basically the higher the value (distance for C_DIS, percentage for C_VEL) the smoother the movement will be, but it will also be less close to the programmed path.
I've attached a screenshot from an older KUKA manual.

And yes, only change the limit for A06!

Best,
Johannes @ Robots in Architecture

Hello,

I wasn't able to look at the entire video as my internet connection is quite slow in the train, but from what I've seen it's probably a wrong setting at the robot. Either the C_DIS value doesn't allow any blending of motions, or the robot is running in single-step mode. But then it would also show up like that with other files. Try changing the C_DIS value in the KUKA|prc settings if the single-step issue does not occur with other robot files.
Regarding the red coloring, that should be fixed in the member version which is several months ahead of the free version. For now, I would recommend just setting the axis limit for A6 to -360 to 360. The next major KUKA|prc release that will hopefully enter testing at the end of November will much more reliably simulate also processes that go past 180 degrees, e.g. winding.
Regarding your 3D model I would recommend running the ReduceMesh command, as it seems like a very high-poly model, which will negatively impact KUKA|prc and Grasshopper performance.

Best,
Johannes @ Robots in Architecture

Hello!

To get started I would recommend taking a look at the examples in the forum. The documentation is indeed out of date, though there are some additional files for members. But just ask if you run into any issues!
We intentionally made it so that even the free version generates fully working robot code - if you're using an example file, make sure that the "Save File" box is checked and set an Output directory in the settings.
However, there is no need for a SRC and DAT file, all the necessary data is contained within the SRC file.

What are you referring to as the "robot dimension"? Do you want to create a custom robot model?

Best,
Johannes @ Robots in Architecture

Hello,

You can also prototype it with the free version, the member version is quite a bit faster and supports external axes, among other "member" features. But a proof of concept can definitely be done with the free version as well.
Of course we'd like to have you as a member of the Association, though - there just shouldn't be any pressure ;)

Best,
Johannes @ Robots in Architecture