irPickTool -- Part rotation throws robot well off location

Just when I thought I was getting the hang of PickTool....

This is what I have happening: I've set up my TrakFrame and Vision such that the robot picks the part without any issue when it's in a rotation similar to the Reference Position. The robot tracks the part on the moving conveyor belt very well.

However... this part comes down the line rotated around Z, either between -20 and +20, or between +160 and +200 (or, I suppose, between +160 and -160 the way irVision measures rotation). And if the part comes down the line "backwards", the UTool rotates to what looks like the correct orientation (relative to the part), but it's well off location along the X axis of the TrakFrame. The actual "tracking" motion is still correct however, following the motion of the conveyor.

Looking at the values in VR[1], when the part is pointing "forwards" (that is, the -20 to +20 of the Ref Pos), I'm getting X values in the range of -50. But when the part is "backwards" (between +160 and +200), the X value jumps up to the -300 range. I think this must be the root of the problem, but I've got no idea what's causing it. The R and Y values in VR[1] look to be pretty reasonable, relative to the actual part position.

I've checked my UTool, and it's correct. And it's not a matter of the robot selecting the wrong UTool -- My Gripper has a large Y+ offset, but all my other UTools are 0'd, and the robot reaches far past where it should if one of the 0-Tools was active.

The irVision reference frame and the conveyor TrakFrame are aligned with each other to within 1deg, so I don't think that can be the issue.

My Pick Offset has only a Z value, everything else is 0, and the Approach/Retreat motions are correct relative to the Pick position. I'm not seeing any signs that any of the Frames are being flipped or inverted -- even when the robot goes much too far in X, its motions in Y, Z, and R appear correct.

My "Origin" in the irVision GPM tool is on the center of the part, so that should not throw the Pick position off in X the way I'm seeing.

So far, I've tried re-creating the entire PickTool recipe and irVision task completely from scratch 3 times, and I keep ending up with this same issue. I'm obviously missing something small but critical, but I cannot figure out what.

Addendum: I collected some more test data.

With the part pointing "forwards" -- that is, close to the Reference orientation -- the VR[1] Found Pos has values of X -151, Y 16, and R 0.1. But the VR[1] *Offset* is X -44, Y 23, and R 2.0.

With the part "backwards" (roughly 180deg in R), VR[1] Found Pos is X -190, Y 20, R -173, with an Offset value of X -295, Y 1, R -171

So I tried forcing the part into +90 and -90 rotations, which would normally not occur in production.

For a Found Pos of X -240, Y -3,R -89, the Offset becomes X -231, Y -109(!), R -87.

For a Found Pos of X -199, Y 10, R 92, the Offset becomes X -211, Y 117, R 94.

So, the Found Pos values line up well with the physical location of the part -- the R values are right about where I would expect them to be, after manually rotating the part. The Offset R values are also pretty close (there seems to be a consistent 2deg difference), but the X and Y values are way off where they should be.

This suggests to me that the Found Pos offsets are being applied in/around the wrong Frame, somehow. My best guess, looking at these numbers, is that the R rotation is being applied, not around the centroid/Origin of the part, but around a point roughly X-100 from the part's actual location. The robot picks the part correctly in the "Forward" orientation simply b/c that's the orientation I taught the Pick Ref Pos in.

I'm still at a loss as to what could cause this, though. I've re-done the TrakFrame and Vision Cal from scratch multiple times, following the steps in the manual.

So... reading the manual, and digging up some old forum posts, there's a program included with PickTool calld ADJ_OFS, which can be called to correct for XY errors caused by changes to the R rotation of the part. But I get the impression that this is intended to be used for small errors, not the 100(!)mm errors I'm seeing.

Still, for lack of any better ideas (and Fanuc not responding to any support queries), I tried ADJ_OFS. And it worked, at least partially -- I was able to get the part to pick successfully at R values near 0, or near 180. I'm still well off location for R values near +/-90, but I may be able to fix that by playing with ADJ_OFS more -- so far, I've only added an X offset to ADJ_OFS, no Y offset.

So... fixed? Maybe? 100mm still seems huge, but this is the best I've been able to achieve so far.

So, that project got paused by the customer before I got a chance to try fixing it. But my conversation with Fanuc tech support suggested that the Vision calibration and/or the Tracking Frame calibration needed to be re-done. The root issue appears to be that the rotation gets applied around a point that's not located at/near the centroid of the part that the vision finds. The ADJ_OFS program is used to correct for small errors, but errors as large as I was seeing (100+mm) usually indicate something seriously wrong with the frame setup.

Quote from Fabian Munoz

Guys, I gave up on that problem years ago.

when I have parts with 360 rotation I use model ID, 1 between 0 and 179.9 and 2 between 180.01 to 359.9.

Yes I just double the amount of work but also I cut the error in half

Well, in my case, even a 90deg rotation was throwing the robot 100mm or more off target, so that's not a workable solution. I wish it was, would make things a lot easier....

Quote from Trav_1992

You need to open up the vision pick boundaries

How is that going to help?

Yes. It's as if the Z rotation is being applied around a point far removed from the centroid of the irVision GPM Locator. In my case, it seemed as if the point the Z rotation was being applied around was positioned correctly in every axis except the X axis of the Tracking Frame. This suggests that the root cause was some sort of error in the calibration between the irVision reference frame and the Tracking Frame.

What I was unable to figure out was how the error occurred. When I set up the irVision and Tracking Frame, I deliberately used an irVision calibration grid taped down to the conveyor, and used the grid origin under the camera as the origin of the Tracking Frame. As I understand it, that should have eliminated any chance of errors between the vision frame and the Tracking Frame.