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.

  • AD
  • 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.

  • Hi! Im struggling with the same issue that you were having. Did you find a solution to this? When my part comes down the conveyor in the same orientation as it was taught it works as it should. But when the part comes in a different orientation it seems as the robot thinks the conveyor orientation changes with the part orientation. (part twisted clockwise and robot tries to pick it from the right side and when the part is twisted counterclockwise it tries to pick it from the left side)

  • 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.

  • 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

    Note: depending how you taught the part. The angles on the model id could be -90 to 90 and 90 to 270.

    Test it an see the results

    Retired but still helping

  • 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....

  • Hello!

    I had the same issue in 2019. Many calls and a visit from Fanuc later the solution was to change the software edition to a previous version.

    Never had this problem since then.

    Below is the version info from that controller before it was fixed. i guess you are working on newer versions anyway so maybe not so helpful info.



    LR HandlingTool 7DF1/15

    S/W Serial No. : 88340

    Default Personality (from FD)

    LR Mate 200iD/7L V9.10P/15

    Servo Code : V04.00

    Cart. Mot. Parameter: V3.00

    JNT. Mot. Parameter : V3.00

    DCS : V4.2.6

    Stop pattern : C

    Software Edition No.: V9.10P/15

    Update Version : None

    Customization Ver. : None

    Root Version : V9.10121

    Boot MONITOR : V9.10P/10

    Teach Pendant : 7D0A/01P

    Browser Plugins : V9.10121

    TP Core Firmware : V9.10P/15

    TP Operating System : 01.4/7.0

    FPGA Version : 13

    Media from FRL 11/21/2018

  • I'm currently having the same issue, and I found that the robot x - axis (Track Y-Axis ) is being offsite in along with R as the part rotates by any angle. hope someone has an answer, I'm still working on it

  • looking more into thins, I'm seeing that the IRVision locates the part correctly, but the problem happens when the Offset of the VR1 is generated, and this where the x and y are changed drastically from what they're supposed to be

  • 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now