Hello,
I have many waypoints who move based on a custom plane, and i need them as poses in my code. but when I make a variable display the pose, it will take the pose from the base instead of the pose from the plane im working in.
ofcourse i could copy xyzRxRyRz from every waypoint and do it manually but thats alot of work for 50+ points. How can i make the variable display the pose in the plane instead of the base.
thanks
This should transform your TCP position to Pallet_1. 
could you explain a bit more how this works, i cant seem to get it to work.
am i supposed to put my plane in a variable and place that in the spot of pallet 1?
i seem to have figured it out, thanks.
Yeah, that’s my bad. Needed a bit more explanation.
Your planes are automatically turned into variables on the e-series. On CB-series you must make it a variable in the Installation → Features.
it seems that I was wrong and I do not understand.
I did it like you showed.
var1=Get_current_tcp_pose
var2 = Pose_trans(Pose_inv(Var1),Plane2)
and then somehow the number that comes from this will be very close to the number it should be, but its not the same and most numbers will be negative instead of positive. am I doing something wrong?
Picture below is from the simulator, on my UR10e i do the same but with current tcp pose instead of the list of waypoints (they are the same)
Also, pose which comes out is very close to the real pose, but not exact.
both the simulator and the real version get the same pose.
A problem for monday it seems. 
When you use the get_actual-tcp-pose() you get the pose at a specific time.
Even when a robot arm is steady at a pose it may have small variations around this theoretical locked pose.
The encoders and the motors in each joint will try to hold a fixed position. When an encoder detects a misplacement, the motor will bring this joint back to the right position. These ongoing adjustments at the joints can course a little wobbling at the end of the robot arm. At a steady position this effect is very small but with more dynamic condition the effect is bigger.
I did a small test with an UR5 CB3. It shows that the robot on average was off by 18 ÎĽm and 52 ÎĽRad when it was at a steady position.
These values were found by polling the robot controller for the actual pose with the command “get_actual_tcp_pose”.
From a series of measurements made at a frequency of 5 Hz (0.2 second between data points) the mean was calculate for a 4 second time window.
This will probably explain why you get “almost” the right pose
Maybe you can use the “get_target_tcp_pose()” to get stable numbers.
This is the pose the robot aim to hit.
The values for the orientation (Rx,Ry,Rz) can switch signs for the same orientation.
That is, the same orientation can be specified as two different sets of values.
In the test above the values for the orientation was a mix of positive and negative numbers.
You can try to switch sign for all three orientation values. You will probably get the same pose (make that test on the simulator!).
This particular behavior makes it difficult to manually manipulate the values for a pose. But if you use functions as “pose_trans” PolyScope will handle the values for you.
thank you for your reply.
sadly its not the fault of get_actual_tcp_pose, as it will give this false location aswell when I dont calculate using the actual TCP but the actual coordinate. And the distance between the wrong pose and the pose its supposed to be is over a centimeter.
somehow there must be something else causing this mistake. I’ll keep trying things until I can fix it.
for a little more information,
The start point compared to base is:
X: 417,93 mm
Y: -747,56 mm
Z: -190,12 mm
RX: 2.20058 Rad
RY: -2.21222 Rad
RZ: -0.0305 Rad
as pose:
p[0.41793, -0.74756, -0.19012, 2.20058, -2.21222, -0.0305],
now it needs to become
X: -0.98 mm
Y: 4.43 mm
Z: 19.96 mm
RX: 0.018 Rad
RY: 3.132 Rad
RZ: 0.032 Rad
p[-0.00098, 0.00443, 0.01996, -0.018, 3.132, 0.032]
but instead it becomes
X: 0.836 mm
Y: -4.829 mm
Z: 19.878 mm
RX: -0.017642 Rad
RY: -3.131932 Rad
RZ: -0.032056 Rad
p[-0.000836, -0.004829, 0.019878, -0.017642, -3.131932, -0.032056]
the coords of the plane im using are:
X: 422.19 mm
Y: -746.77 mm
Z: -210.13 mm
RX: 0.005 Rad
RY: -0.044 Rad
RZ: -4.706 Rad
p[0.42219,-0.74677,0.21013,0.005,-0.044,-4.706]
as u can see, there is indeed only a small change in the real pose and the miscalculated one, but the -4.8mm that is supposed to be 4.4mm really ruins the whole pose. Any idea what I can do to fix or atleast try to fix this? This is just one of many points that need to be accurate
posting for anyone who might need this in the future.
It seems like I have found the problem.
this is the current program, and it works.
It takes the coordinate from the plane, turns it to the base world and back to the plane.
I just had to use pose_inv on plane instead of the variable.
I dont know if its supposed to be like this instead of what you sent, but it seems to work so I will be using it.
That’s weird. I’ve always used my method. But it’s a bit complicated to figure out sometimes…
Glad you got it working!