The robot desn't work in the same way in the simulation.

[DigitalCraft]

Hi Johannes,

I just recently started using robot and kuka|prc. My robot is Agilus sixx.

After reading the tutorial PDF, I'm playing around with the tutorials samples. Everything is cool in the simulation, but when I copy the generated src code to the robot and run it, the robot works in a different way (axis 4 turn moves too much).  I took a look at the generated KRL code, noticed that for each step the "E6POS" B is always 90.0. And i tried the other samples, the KRL codes were also different from what they're supposed to be.

Please tell me how to fix this, thank you.

[Johannes @ Robots in Architecture]

EDIT: As this is post is viewed very frequently, here is some useful troubleshooting advice:

For an accurate simulation, the physical and digital robot have to be synchronized, i.e. tool and base have to use the same number and XYZABC value. Please refer to the sticky post on top of the forum: http://forum.robotsinarchitecture.org/index.php/topic,115.0.html
It is possible to set custom axis limits, which differ from the standard robot setup. If you change them back to default, make sure that there are no mechanical stops installed.
The simulation is only accurate until the first point that is out of reach. Do not depend on any information that comes AFTER an unreachable position, .e.g. when you manually skip an unreachable position via the smartPAD/KCP.
KUKA|prc only calculates the programmed positions, but there can be out-of-reach positions in between as well. You can enable LIN Interpolation in the settings to spot errors in between LIN movements.
Members are encouraged to use the most recent version of KUKA|prc - we usually update the software at least once a month.
Post in the forum or get in touch with johannes@robotsinarchitecture.org if the problem persists.

Thanks!




Hello,

First of all, this may of course be a bug, but I cannot diagnose this without the file (and preferably the robot).
Basically, it's important to consider that there is no "official" KUKA kinematics solver available for third-party software. The most accurate simulation you are going to get is via the combination of KUKA SimPro and OfficeLite, which is a virtualized robot controller, i.e. you put the KUKA|prc-generated KRL file there and can execute it virtually. So the KUKA|prc solver is made to best approximate the way KUKA robots behave.
Regarding the A4 problems you can try to set the first position as a PTP movement with a specific Status value - e.g. 010, an explanation is in the KUKA Expert Programming Manual, should be on the included CD, see also the graphic below that shows the different ways how a robot can reach a defined position.



The fact that B is always 90 probably means that you've got only vertical positions (B is the rotation around the local Y-axis).

Best,
Johannes

[DigitalCraft]

Hi,

Thanks for the reply.

I understand that there are different ways for the robot to reach a defined position. Since I don't have KUKA SimPro and OfficeLite, so I can't execute the src file there virtually. But a friend of mine also design a "simple path" program by RobotMaster and sent me the generated KRL file which the robot ran perfectly just like in the simulation. And I'm sure that the base setting and tool setting of my robot is correct.

Here is the Kuka|prc-generated KRL fie of the tutorial "simple-path", and some pictures. Please help me out, which part is wrong?

Thanks

[Johannes @ Robots in Architecture]

Hello,

I don't see any problem here, but the issue is that the "physical' movement of the real robot differs from the virtual robot, right? In that case I would need a comparison with your real robot, i.e. some images and or a video! Please also note that the simulation can only be accurate if you use the same XYZABC values for the tool and base in both simulation and reality.

Best,
Johannes

[DigitalCraft]

Hi,

I'm sure that same XYZABC values for the tool and base are used. One thing is that the robot is on a table and so I move the path up along Z-axis a bit.

videos here:

simulation: http://bit.ly/1f2gq5o
physical: http://bit.ly/1f2doy3

Best,

[Johannes @ Robots in Architecture]

Great, thank you for the data. I'll be at our Agilus on Thursday and test it myself!

Best,
Johannes

[DigitalCraft]

Hi  Johannes,

Does your Agilus run well the code? Waiting for the solution, thanks.

[Johannes @ Robots in Architecture]

Hello,

First results seemed fine, but I only checked it on a KR16. I should have time again tomorrow. Can you give me the version number that you're using? Go into the KUKA|prc settings and to the About section. It's in the upper right corner.
A general workaround, as we had at least similar problems before, that the A04 didn't turn like in the simulation: Put the robot into a position close to the beginning of a job and write down the individual axis values. Then enter them as the KUKA|prc start values.
KUKA|prc is programmed to use the "shortest" way for PTP movements, i.e. it checks all alternatives and takes the easiest one. The internal KUKA solver sometimes chooses a different strategy. I'll put the possibility of defining the status/turn of the first PTP command into the next release.

Best,
Johannes

[DigitalCraft]

Hi Johannes,

Thanks for the reply. The general workaround did solve the problem. I'm using the version 2013-12-20, looking forward to the next release!

Thank you again.

[Joanne]

Hi Johanne

I am having this A04 member issue as well. My grasshopper/Kukaprc simulation do not show that the a4 member will flip 180 degrees going from start position to the work piece. Same issue shown in the video of this thread.  Are there any other tricks to fix this other than trying different start positions?

Thanks
Joanne

[Johannes @ Robots in Architecture]

Hello Joanne,

There are a number of reasons why that could happen - but first of all, are you using the member version or the regular version of PRC? We did quite a few improvements to the robot simulation in the new PRC so that it's much more accurate now.

Ideally also send me the file where the problem occurs!

Best,
Johannes

[saltegor]

Hello Johannes!

I am preparing for my project at university and getting familiar with KUKA|prc and application of it using KUKA KR16. I have studied all the tutorials you'd provided (thanks a lot, they are pretty clear) and I have already calibrated the robot following your instructions (http://forum.robotsinarchitecture.org/index.php/topic,115.0.html). Everything works quite good, the KRL codes that I got from your tutorials are going perfectly.
So, I decided to go further using custom tool. I want the robot to draw using a sharpie. Therefore I created a mesh of my tool, imported it, defined the position of the tool. I want it to be aligned to X tool tip axis, i.e. orthogonal to A6 flange. I created the control program, using your Custom_tool tutorial as a basis. I added the table surface in order to check for collisions.

well, here are the problems I am stuck with:
1) When I draw any curve, everything goes well. But in case of a closed geometry (I chose a snail as a geometry) when I run simulation of movement, everything goes well, too. But when I try to run it with KUKA, it comes to a border condition and blocks the movement. Look the attached pictures to understand what I mean. I even tried to redefine the starting point of the movement. Depending on situation, the robot blocks different joints (usually A4 or A6), but anyways I cannot finish the drawing. For example, last time it reached -349° at A6 and tried to go further but it blocked itself, due to the movement limits. So, the question is how to solve this problem.. I think this all is because I really have no idea about the orientation point. I tried to define it as a mean point of a geometry so that the tangentials were pointed at a center of the geometry; also I tried to move the point far away so that the tangentials were almost parallel.. nothing helps. I imagine there should be some way to tell robot to compensate the positioning using the other joints, but I cannot figure it out. Maybe the problem is because I use a linear movement, but I don't think so.
2) What about collisions? Even if I connect an object to KUKA|prc and I define "check for collisions" in a corresponded setting, it gives me almost nothing. Yes, it checks and puts a red colour at the joint which goes beyond the restricted area. But why it cannot affect a compensation with the movement of other joints? As you said, there are several ways to reach the point and I think that theoretically there is a way to avoid the overpassing the limits.
3) I find really uncomfortable to export KRL code by using KUKA|prc-> Parameters-> ApplySettings button. Would not it appear more useful to have a kind of ExportCode button apart of all this? And not to update the existing code every time I want to change something. It would be cool of you to create it in future oncoming updates.

I attached the 3dm and gh files of the project for you to check my program.

Thank you very much for your patience, time and clearance of explanation. All your answers are really helpful.
I am looking forward to hearing from you soon, because I am really excited about the robot.

Regards,
Egor Saltykov
Politecnico di Milano

[saltegor]

Here I attach the photo of the robot and tool attached, because I could not add them in previous post. Also there are screenshots from Rhinoseros showing what I meant about the tangentials' direction.

Regards,
Egor Saltykov

[Johannes @ Robots in Architecture]

Hello Egor,

Thanks for your message, I've checked your file and it seems that you've approached some of the issues a bit more complicated than they have to be. I've also upgraded it to the most recent KUKA|prc version. If you send me an eMail to johannes@robotsinarchitecture.org I can send you a license for a few months - usually it is only available to members. Note that if you open it now, you will get a bunch of error messages until you've updated KUKA|prc. The file is attached.

Before the very specific problem, here are my replies to the general issues:

2.) Collision checking: While you are right that the robot can move to a given point with multiple postures (called STATUS, in the case of KUKA robots, e.g. 010, defining if the robot reaches backwards or forwards, if A4 is flipped etc.) it is NOT possible to smoothly transition from one posture to the next on the workspace. This is only possible with e.g. a seven axis robot like the iiwa, which can move its extra axis while the tool stays at exactly the same position. Therefore, collision avoidance (as you would like to have it) is not possible, you have to adjust your parametric toolpaths to avoid collisions (the beauty of Grasshopper being that you adjust your toolpaths and immediately see the effect on the robot, e.g. via the Axis graph).
Some kind of collision avoidance is possible if you use a symmetrical tool, like with milling, where you can rotate around the tool axis without changing anything. The easiest way to change that rotation is via the orientation point.
I hope you understand that it would be disastrous if you program a toolpath and then all of a sudden the automatic collision avoidance activates itself and by itself changes the posture of the robot.

3.) There is a slight misunderstanding, you do not need to manually click Apply all the time, whenever you change anything, the .src file updates automatically. If you do not want that automated behavior, you can right-click the core-component and choose "Expose Filename and Save Settings". You can then define the projectname with a string input, and use a "Button" component to save it manually.

Besides that I checked your file and everything seems OK. I did check your toolpath with the new KUKA|prc and your toolpath strategy windows up the tool to a maximum of 350.39 degrees, i.e. just a few degrees over the maximum. The easiest way to circumvent your problem is to adjust the toolpath accordingly, or to set your A6 to infinite rotation.

One more important thing: You've used an extremely fine mesh for your tool, with over 30.000 triangles. Using Rhino's ReduceMesh command I've reduced it to 3000 triangles - this greatly improves performance, especially with a weak graphics card.

Hope that helps!
Best,
Johannes @ Robots in Architecture

[HSH]

After reading the tutorial PDF, I'm playing around with the tutorials samples. Everything is cool in the simulation, but when I copy the generated src code to the robot and run it, the robot works in a different way (axis 4 turn moves too much).  I took a look at the generated KRL code, noticed that for each step the "E6POS" B is always 90.0. And i tried the other samples, the KRL codes were also different from what they're supposed to be.

Please tell me how to fix this, thank you.

Hello,
may I reopen this topic again since I have exactly the same Problem:

- I generate a very simple circular toolpath on a x-y-plane, all plane normals of six tool positions facing up in z-direction.
- Neither the coordinate-system of Base is rotated (A/B/C = 0) nor is the tool (A/B/C = 0).
- In Simulation, everything looks fine, coordinate-systems of part and tool perfectly aligned.
- BUT: generated Kuka-Code has a 90° rotation around B-axis.

My workaround: I have to rotate the position-planes by 90° around y-axis so that the X-Axis of the plane is facing upwards (="tool axis") and rotate the tool in custom tool settings by -90° to compensate.
Now I get (A/B/C = 0) in Kuka-code and a "correct" simulation.

Did I miss a setting somewhere that assigns the X-axis as tool axis in my case? Can I switch it to Z-axis?

Thanks!