Calculated R orientation value sometimes 180 degrees off

  • Hi, I'm working on line-tracking vision system where a computer uses a camera to find objects on a conveyor (conveyor runs perpendicular to the front of the robot), and then sends their positions to the robot over Ethernet/IP. To test our numbers, we let the computer calculate a position and then we jog the robot to that position.

    We can successfully calculate proper X,Y,Z,W, and P position/orientation values, but R is a bit of a problem. All values are calculated while the part is up-stream from the robot. However, depending on whether the part is up-stream or down-stream from the robot at the moment we try to move to it, the R value may be 180 degrees off. If I remember correctly, it's when the part is up-stream that we need to change the R value by 180 degrees.

    Does this sound like anything you've encountered before? Any idea why we would have to change the R value based on the where the part is at the moment the robot starts reaching for it?


    P.S., the robot is an LR Mate 200ic with an R-30ia Mate controller

  • It sounds like the robot is going to the closest position.
    If the point is linear, the robot may determine that that rotation is closer at one end of the conveyor as opposed to the opposite end of the conveyor.

  • flatcurve:
    No, not using iRVision. I've got a couple of 3D cameras that watch the conveyor and feed the images to a computer running Halcon. Halcon calculates XYZWPR values for the parts and sends them into the robot's position registers over Ethernet/IP.

    I'll have to look into that. Shouldn't a certain set of position/orientation values always refer to the same tool orientation though?

  • Not necessarily, when the robot is moving in linear it is looking at the TCP. If the robot determines that the point can be reached quicker with the R value 180 degrees out it will choose that position. It is the same position in world.
    Pallet robots do this all the time and it is vary annoying. You could look at the position the vision has set and correct it before the robot moves to the position. You can try moving to the position in joint, but that may not work.

  • Well, that's kind of the problem. All position/orientation values are calculated by the computer while the part is still up-stream. We don't know at that point where the part will be when the robot decides to move for it. If the robot is really making decisions about how to rotate the tool based on the part's position on the conveyor at the moment the it starts to make the move, it's too late for the computer to send an adjusted R value. I guess maybe I could write some robot code that checks the part's position along the conveyor just before making the move, and then flips the R value by 180 if it's down-stream.

  • I am not sure this will help or not, but you can use the motion option wrist joint to force the robot to use the commanded wrist configuration instead of the shortest angle. It works with line tracking paths.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

Advertising from our partners