User Frame to PR Question

Hello,

First off, I am not a robot expert by any stretch of the imagination, so please forgive my ignorance!

I am working on a fixed mounted 3D vision guided application using a R2000iC/210F running a handling tool program. I've decided to create a fixed reference within the cameras Field of View, and teach the robot a User Frame (in this case, UF5) to the same origin point. From there the plan is to send X-Y coordinates to the robot for precise locating of parts.

Once I trained the camera and the robot user frame (3 point method) to the same point in space, I backed up the robot program and have been doing some offline testing in RoboGuide. But I've run into an issue that I don't fully understand, and was hoping for some help here.

I wanted to initially run the robot to the taught user frame origin, and followed other threads recommendations by setting the UFrame to a PR. The problem is I keep getting Position Not Reachable faults. Upon further investigation and reading other threads, I set all of the coordinate to 0,0,0,0,0,0 and tried jogging to that position while setting the robot's coordinate system to UF5 but still got the same issue.

So next I tried jogging the robot to the UF origin using the "Move To" function in the User Frame setup detail, then checked the robot's position in World vs User, and noticed that the w,p and r had values that I couldn't determine how they were calculated. Attached are the three sets of values for the same UF position. First SS shows the UF values from the UF setup screen, and below it the actual position in world when I drove the robot to that origin point. The 2nd screenshot shows this same position, but in User coordinates. I understand why the User X,Y,Z coordinates would be 0,0,0 because it's at the origin, but I don't understand w, p and r.

UF5 in User.JPG

My primary issue is that I plan on giving people the ability to re-teach the robot this new origin by touching up the user frame origin if needed, but programatically I need to be able to ensure the w, p, r values reflect the new correct position that will be taught. I also need to be able to jog the robot to this origin programmatically in case anyone does have to change the origin. Can anyone help explain how I can translate the w, p, r values as shown in world for UF5 setup vs what they represent when I actually drive the robot to the origin, and show the positions in User?

One thing to note: I was also getting faults when attempting to write the UF to a PR, but it was because PR_CARTPREP was set to False. Set it to true and was able to get past that. Robot was taught the UF with this set to False. Not sure if this matters, just info for you experts in case it did!

Thanks!

Quote from TitusLepic

Not an expert, but if you search the forum for "euler angles" you'll find a bunch of relevant information.

Thank you. Looks like this is going to be a bit more difficult than I anticipated!

Quote from Shellmer

the only way to ensure that you maintain the same directions while taughting the uframe is to move in the same direction as the world or putting all 0s in WPR.

So I could avoid this difference in rotation values by simply teaching my user frame X and Y direction the same as World? I can't change my w,p r values to 0 because I need them to be in these specific positions.

Quote from hoitzing

Do I understand correctly that you wish to allow people to update a userframe's origin, but not its orientation?

Because that would be possible by teaching the frame with the 4-point method, where the first three points are used to create the frame's orientation, and the origin is shifted to the fourth point.

Yes that's what I'm trying to accomplish! I'll take a look at the 4 point method and see how I can make that work.

I was also trying to put the origin and orientation (fully defined robot TCP position) into a PR, and then have a program drive the robot to that PR and set up some comments to instruct folks how to update that origin in frame setup should it ever need to be changed. I can always just do it with an internal program position with some instruction comments in the program on how to update the origin, unless there is a better way to do that part.

Thanks for the tip, I'll try it out!

Ok so similar issue and need some feedback on this. I have set the user frame with a specific TCP orientation:

When I move this User Frame 5 to PR210, then try to move to PR210, J5 and J6 twist to this weird orientation, and I cannot figure out how to keep the TCP orientation the same as how it was when I taught the User Frame. This is what happens when I try to move to PR210 after moving UFrame 5 to it:

Is it related to the CONF settings? If so, I don't know how to transform them in a way that maintains TCP orientation to the pallet the same way as the way I taught the Frame. Tried updating the CONF options but nothing seems to work.

Quote from Doctor_C

First thing I would do is make sure you put the User frame data into the PR as cartesian.

$PR_CARTREP = 1

PR[210:Uframe5] = Uframe [5]

Then you can manipulate PR[210] X,Y, or Z all you want, And stuff it back into the userframe.

(And then switch cartrep back to Zero if it causes other issues).

Thanks! Hadn't considered using CartRep programatically. Basically I'm just doing some X,Y,Z adjustments to PR210 with 2D vision and a laser for z offset, but always relative to the origin of UFrame 5 hence why I was using it as a reference in the program. I'll try this and see if that fixes it.