Search

[Raisa K]

Hello Johannes,

We are trying to achieve a tight continuous circular movement and have come across a couple of issues – the 4th and 6th axis are in error throughout the motion, with apparent  "collisions / unreachable positions" ...any help would be fantastic.

Best,
Raisa

[Johannes @ Robots in Architecture]

Hello,

The iiwa is very constrained within its reachability, if you change the initial posture from 110 to 010 it should work.
The setting is located in the Advanced Settings, in the Start-/Endposition section.

Best,
Johannes

[Raisa K]

Yes, that solved the issue...many thanks!!

Raisa

[jason_r_Crow]

Hi Johannes,

We have made a few steps forward, but seem to be having an issue with the coordination between the actual robot position and the simulated position using PRC.

We have set a point on the robot, and copied the axis positions into the Start settings in the PRC Settings. However, when we do so the position of the robot in the simulation does not match the position of the actual robot at the point that we have set.

We assume that the robot position in the simulation should match the position of the physical robot. Is that correct? Assuming it is, do you have any suggestions about how to calibrate the simulation so that it matches the actual robot position?

thanks,

Jason

[Johannes @ Robots in Architecture]

Hello Jason,

In KUKA|prc we use the "old" notation that KUKA used for the KUKA LBR robots before the iiwa, where the extra, redundant 7th axis is called E1.
So what the iiwa calls A1 - A7 is in KUKA|prc A1, A2, E1, A3-A6.
Hopefully then the movement will match!

Best,
Johannes

[jason_r_Crow]

Hi Johannes,

I think we have something set up wrong. Aligning our simulation in Grasshopper with the robots is mapping the axes differently.
What appears to be correct for us is:
PRC A1 maps to Robot A1
PRC A2 maps to Robot A2
PRC A3 maps to Robot A4
PRC A4 maps to Robot A3
PRC A5 maps to Robot A6
PRC A6 maps to Robot A7 (Not the redundant axis, but the rotation of the media flange)

We might be setting up the base improperly? We are also getting errors when we run the PRC generated code on the robot. I've attached a screenshot of the pendant. I am also attaching our Rhino Model, test  Grasshopper script, and PRC XML file output.

Jason

[Johannes @ Robots in Architecture]

Hello Jason,

The error ("Arbeitsraumfehler" = Workspace error) means that the robot cannot reach a given position.
The most likely cause as you mentioned are the tool and base settings. To see if the KUKA|prc code is running in general, try a simple file with just a few axis movements.
I've attached a screenshot where you can see how tool and base are set in Sunrise / how they are referenced in the code.

Best,
Johannes

[jason_r_Crow]

Hi Johannes,

We are still working through trying to get the physical and virtual robots in sync. When adding in the geometry for the tool, do the notes in this post apply to the IIWA - https://forum.robotsinarchitecture.org/index.php/topic,115.0.html? I ask as we had drawn the tool vertically along the z-axis with the base of the tool at 0,0,0 and the tool tip at 0, 0, 175mm. To have that show up properly in the simulation, our tool setting for A, B, and C in the custom tool component were 90,-90,90. Orienting the tool along the x-axis with the tip facing toward 0,0,0 shows up incorrectly?

Jason

[Johannes @ Robots in Architecture]

Hello Jason,

Please excuse the late reply, I was sick for a few days and then Christmas happened.
We're using X+ as the tool-axis, which is then mapped to Z in the CAD environment. So if you've got a tool that is normal to the flange (drawn along the Z-axis), you will need to rotate the tool axis with e.g. B=-90 for it to align.
In any case, the values need to be identical within the simulation and at the robot. When working with the iiwa, take care that some values in the UI are in radians.

Best,
Johannes

[jason_r_Crow]

Hi Johannes,

We think we have tracked down our problem. We can get the simulation and the real robot to match fairly well, but when KUKA PRC generates the code, the tool settings are over-rotating on the B-axis. Basically, to get the tool setup in the simulation to match the robot, we are rotating B -90 as you suggested. We are using the ABC 2-point method to calibrate the tool, as it makes the most sense relative to how the tool is designed to move.

If we use the xml file as generated from Kuka PRC, we get an unreachable point error. I have attached an example file X_and_Y_lines.xml.
If we edit that file and change the B-value for the frames where we are making are linear moves, it works. I have attached the working modified xml file X_and_Y_Lines_B_Rotate.xml.

Basically what we are doing is changing these lines:
-<PRC_CMD>
<TYPE>LIN</TYPE>
-<FRAME>
-<FRAME>
<X>179.41107177734375</X>
<Y>-109.59288024902344</Y>
<Z>51</Z>
<A>0</A>
<B>1.5707963267948966</B>
<C>-0</C>
</FRAME>
</FRAME>

to this:
-<PRC_CMD>
<TYPE>LIN</TYPE>
-<FRAME>
-<FRAME>
<X>179.41107177734375</X>
<Y>-109.59288024902344</Y>
<Z>51</Z>
<A>0</A>
<B>0</B>
<C>-0</C>
</FRAME>
</FRAME>

Our tool INIT is:
-<INITTOOL>
-<FRAME>
<X>0</X>
<Y>0</Y>
<Z>175</Z>
<A>0</A>
<B>-1.5707963267948966</B>
<C>0</C>
</FRAME>
</INITTOOL>

which makes sense from your instructions and from the simulation in Grasshopper.
Any idea why the B is being over-rotated?

Jason

[Johannes @ Robots in Architecture]

Hello Jason,

Are you sure that the tool is properly set up in Sunrise Workbench and uses the same values as in KUKA|prc?
Especially the B rotation which should be -90 or -1.57 if radians are used?
My guess would be that your tool in the Sunrise Workbench is set to B=0.

Best,
Johannes