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?

    Thanks!

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

    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.

    Racermike123:
    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.

Advertising from our partners