Cartesian vs Configuration -- limiting RZ

    Being a Fanuc newb, I need a bit of help here.


    I'm using a 6-axis Fanuc in a depalletizing fashion, to pick boxes from a pallet. I have a 3D vision system to get the coordinates of what I'm picking, which provides me a PR containg X,Y,Z, and Rz of the center of the top surface of the box (Rx and Ry are always 0). That all works fine.


    The one fly in the ointment is that, because I'm picking up rectangularly-symmetrical boxes, there's no disambiguation for Rz -- if the box is rotated 45deg, the Rz value I receive could be 45, or -135 -- it's literally 50/50. Now, to protect the cables and hoses, I want to limit the Rz angles the robot uses to (for example) -90 to +90. Since my end effector is also rectangular and symmetrical, all I need to do is line up the long axis of my end effector with the long axis of the box -- I don't care if I pick it up 180deg "wrong".


    From my previous experience with other robot brands, this seemed simple enough: use some IF statements to add 180 to Rz if Rz was less than -90, or subtract 180deg if RZ was greater than +90. Well, the math works, but the effect on the robot's motion is not what I expected. Despite limiting the Rz value of the PR this way, sometimes the robot simply decides to go "the long way around", even though the shortest route (in joint space) from its starting position would be the other alternative.


    What I expected was that, given my unambiguous JPos starting point, the path planner would choose the shortest joint-space path to the Vision location in the PR, but that's not happening.
    I'm guessing that I'm running into some sort of conflict between the Cartesian coordinates and the Configuration settings. But I don't know enough about how Fanuc path planning works to say for certain.


    So, my questions:

    is there some other cause for this behavior that I need to look into?

    If I'm right about the Cartesian/Configuration conflict, what's the best way to handle it? Can I "remove" the Configuration values from a motion command, such that the path planner simply chooses the "least motion" path?

    Can I do any of this in TP, or would it require KAREL?

    Doesn't 3d vision have an option to limit that angle automatically? So you don't do calculations yourself? 2d vision from fanuc does.

    There's an option MROT which should do what you want, it should be free, but needs to be activated, at least that's what Fanuc told me, in the mean time I solved the problem otherwise

    I can't remember if 3d has the same option as 2d to limit the angle. If you always start from the same joint position and manually change the r offset with an if statement you should be ok if you use either a linear move or joint mrot. I would just use linear.

    I guess:

    pick pose (cartesian) ----- IK ----> several solutions --------> match configuration (NUT000) --------> final joint value


    Default configuration of FANUC 6-aixs robot is 'N U T 0 0 0', last zero means 6th axis value should be in [-179, 179].

    If one pick pose (cartesian) is odd, try to teach a new configuration to test.


    Finally, if you confirmed the problem is related to configuration, you may need to write programs to manually/automatically set configuration filed of P[n] or PR[n].


    Ref:

    OPERATOR'S MANUAL - BASIC OPERATION
    8.1 POSITIONAL DATA

    Quote from Affaltar

    Doesn't 3d vision have an option to limit that angle automatically? So you don't do calculations yourself? 2d vision from fanuc does.

    I'm not using Fanuc vision, it's a 3rd-party system that can intelligently identify boxes in a stack.


    Quote from HawkME

    Are you using a linear or joint move?

    Joint to reach the "Above Pick" position -- basicially, the PR from the vision system, plus a World Z offset. From the "Above Pick" to the "Pick" is a Linear.

    Quote from linuxsand

    Finally, if you confirmed the problem is related to configuration, you may need to write programs to manually/automatically set configuration filed of P[n] or PR[n].

    Thanks, I'll look into that too.

    Quote from Affaltar

    There's an option MROT which should do what you want, it should be free, but needs to be activated, at least that's what Fanuc told me, in the mean time I solved the problem otherwise

    Hm! I'll look into that, thanks.

    The joint move is your problem. Having a dynamic offset on a joint move should generally be avoided because the results are unpredictable without some fancy advanced kinematics calculation. There are a few simple solutions.


    1. Change approach to linear move with offset.

    2. Use a joint move approach that is roughly above the pick area but has no offset, then use linear approach with offset and finally a linear move to pick.

    3. Install the MROT option (free option) and change the approach to a Joint MROT move.

    So, it's been a couple busy weeks, but I'm finally back to this. I have something that appears to work for my purposes, as crude as it is.


    First, Fanuc informed me I can't activate MROT on this robot without several other paid packages, so I tried one of Hawk's other suggestions: using a Joint-defined point to get my wrist set up the way I want it (with J6 in the middle of the range I want to allow), then using Linear motions to the Offset PR and the PR. I built a TP routine to keep the Rz value inside the limits I determined by jogging with the POSN window open, then built a brute-force test program that faked Rz values from -180 to +180 (my vision system won't send data outside those limits) and ran the motions.


    So, the test run looked good, and I'm reasonably confident that, even if the math fails, I'll get stuck looping in the limit-check program rather than have the robot go wild and rip the dressing apart. But if anyone spots anything obviously wrong in my code, please let me know. (please don't laugh at my crude TP, I'm not good at it yet)


    First, the limit-check program. Rs 570-575 are where I normally receive my XYZWPR data from the vision system. R574 and R573 (Rx and Ry) are always 0 for this system configuration. My production program will always subject the vision system data to this limit-check program before building PR200 for my "pick position". Everything before Line 33 is just XYZ checking.

    Next, my crude test program. PR 200 is my "pick position", processed from the values in Rs 570-575. Position P1 is my "wrist reset" point, which I always went back to for the start of each test, just as my production program will always move to a joint-defined point before performing the Linear moves to PR200.

    Looks like it should work fine to me.


    I usually go with less jump labels as my preference. I would add a PAUSE command before Line 18, Jump LBL[5]. If it fails it will be stuck in an endless loop, but with a pause it will stop the program and give you a chance to examine or adjust the 3D vision then try again.

Advertising from our partners