Messages

So a little more strangeness. The errors happen when students copy my setup, but do not happen when I export their files from my machine. The students are running the exact same versions of Rhino 7 and Kuka PRC. Given the same setup, what might cause the files they create to generate errors while my machine does not?

Jason

Hi Johannes,

When trying to run a variety of files on the IIWAs, I am getting a Safety Warning under Safety Control that "Communication to Sunrise failed," which I have not seen before. Sometimes reducing the number of frames generated to reduce the number of PTP commands seems to help, but I have much larger sets of movements that are fine. I cannot figure out what is truly causing the problem. When the error occurs, the runXML application cannot be reenabled. The robot has to be rebooted before I can try again. Most of the safety features in the config are turned off, so I don't think that is the issue. In the application, I get a bunch of errors about reaching a point, but often this is a point that the robot is known to be able to reach.

Files attached for one of the setups causing issues.

Jason

Hey Joh!annes,

Cool! At least most of what I am doing will be with circle segments. I am working on replicating some of ways in which Borromini approached the geometry of domes, so similar to the scripting Cameron Wu does, but in three dimensions. None that requires a spline. That means if the arc has to be on one of the planes, it could get tricky to come back and have an arc-like movement normal to the surface at a point, correct? My colleague is much better with g-code than me, so he might be able to help more than me. Regardless, I am happy to assist with testing and figuring things out.

Using Akima interpolation for the splines seems like a good compromise. I guess the thing to test would be to see how different the actual movement is from the preview? Mostly the preview is just acting as a 'not doing very, very bad things' check for me :D, so close enough might be fine.

Jason

Hi Johannes,

Sorry for the delay: Wednesdays are my robot days. :)

Ah, yes, that makes sense in terms of the behaviour that I am seeing. CIRCs just become points in the gcode. SPLINE movements might be ok, too. I would be more than happy to play around with things and see what I can make work relative to G2 and G3 commands, if you can reenable both for the Kuka.CNC code output.

Jason

When exporting KUKA CNC, are the Spline and Circ movement components supported? The g-code I am getting doesn't create a G2 or G3 command, it just tells the robot to go to a given point.

I am seeing a disconnect between the simulation and the movement of the IIWA movement when attempting to draw multiple circles.

When creating a CIR movement on the IIWA, my recollection of the proper point order to pick is start (point 1), end (point 2), aux point (aux point).

In Kuka PRC, if I input that point order, the simulation does not show the correct movement, but if I input the points as start (point 1), aux (aux point), end (point 2), the simulation looks correct.

On the robot, the opposite happens. If I input the points as start (point 1), aux (aux point), end (point 2), the robot back tracks when repeating the arc movement to form circles.  If I input the points in the order start (point 1), end (point 2), aux point (aux point), the robot moves correctly.

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

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

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

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