Workobject offset

Robot Controller
1

I’m pretty sure this can be done but the maths eludes me…

I have a workobject with its origin a good way away from the working area. When presented each cycle, it will be in a slightly different position so there are 3 laser measurement sensors to detect displacement; 2 measuring X about 300mm apart and another measuring a Y displacement. If the part is only moved by a true X and/or Y shift, then its an easy transformation by inputting the values directly into the object frame:

wobj_new:=wobj_original.oframe.trans.y:=AI_Yshift

If the 2 off X displacement sensors show different values, then that indicates a rotation has occured but whilst I can calculate the angle, I can’t figure out how to reflect these values back to moving the origin point of the workobject (about 2m away from the measuring points). Making the robtargets and hence the workobject referenced to the zero point is a customer requirement.

Hopefully the screenshot might help explain - the two plates are the ideal and probable positions of the area; blocks are the measuring devices.

As the points at which the measurement occur won’t be the same, I can’t use something like DecAccFrame as I can’t locate the exact points. Origin point is about 2m off the top of the screenshot..and hence where (I think) I need to place the offset X,Y,X,Q1 etc figures?

2

hello,

you can use an abb function for this : DefFrame

you need 3 points to make a frame, p1 and P2 to make the angle and P3 is the orthogonal on this line that defines the zero.
exemple
lets say you have 1 sensor that measure distance in X and 2 sensors that measure distance in Y.
you receive the values as analogue inputs
you know the distance from the edge of your “ideal” plate to your sensors, these are the fixed coordinates from your points

PERS robtarget p1:=[[100,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
PERS robtarget p2:=[[400,0,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
PERS robtarget p3:=[[0,200,0],[1,0,0,0],[0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

so you see that P1 is placed at 100mm away from origin and P2 400mm, so 300mm apart
P3 is 200mm away in Y

you use the analogue inputs:
p1.trans.y:=AI_Laser1;
p2.trans.y:=AI_Laser2;
p3.trans.x:=AI_Laser3;

you make a frame of the points now
frame1 := DefFrame(p1,p2,p3Origin:=3);
now you have defined a new frame with zero on the edge of your plate with the axes following the edges

then you define your pickposition from this result:
rpickA.trans:=frame1.trans;
rpickA.rot:=frame1.rot;
(where the workobject is the frame on your ideal plate)

or you can put the values in the object part of your workobject and use your ideal pickposition coordinates.

Hope this helps you

BR

Peter

3

I was looking at the possibility of using three points as a triangle after I wrote this so will have a look at using DefFrame - many thanks, Peter.

Sometime you can’t see the wood for the trees…

4

Just trying to replicate this relating to the proper workobject in my head before trying it in the real world and not sure if its going to work as the XYZ and quaternion shift will be related to the frame origin, not the workobject user origin?

5

hello,

if you suppose that your ideal plate position will return the frame with position shift 0,0,0 and angle 0, then the calculated frame will give you the position shift and angle regarding this zero frame.
if you are working with a workobject that is far away, like a car origin or so, likely your tcp is also defined on the car origin of your gripper, so the coordinates for the pick position of the ideal plate is 0,0,0?
if you use the calculated values as your pick coordinates, your gripper will reposition itself on the plate, that is when your tcp is aligned with the zero frame.
if your grippers tcp is oriented differently then your zero frame, you must recalculate the shift and angle in the tcp frame you want to use.

hope this make it a little more clear :slight_smile:

Peter

6

You are indeed right in your assumption, Peter - its a vehicle workobject.

Theoretical perfect workobject runs at something like:
[[2695.01,3458.89,2053.8],[0.70636,0.00117356,0.000562643,-0.707851]],[[0,0,0],[1,0,0,0]]]

Hence the DefFrame returns a bit of nonsense using the laser measurement values but straight in as an offset to the theoretical X and Y offsets. Just off to see if I can figure out the trig in order to recalculate the new positions of the laser “spots” and possibly used DefAccFrame instead as this might work…

Its not a gripper, but the same principles apply in that the TCP will be going to vehicle co-ordinates. The plate position is also hence defined in car origin.