Feature Frame when saving waypoints in variables

Hi!

I hope you can help me explain how feature frames and waypoints in variables works.
I have setup a few waypoints that i save in an array for future use.
Later I load these ias a waypoint and set the feature frame in the movel.

But to the strange thing, these variables have the base as origin but I have done the exact same in other programs and they have the feature frame as origin. How and why do they differ? I know you can convert them but i really need them to keep the same feature after I update the waypoints.

I took a look in the script and it has differences

From the example above I think it translate the waypoint from the Frame to Base
v705_M3Pos[0]=pose_trans(V705_Enclosure, pose_trans(p[-.266048228358, .460002755242, .073428747230, .002480685673, -.002748459979, -.000555452010], v705_M3_1_p))

Another program does this different and do not translate the waypoint
v510_M3Pos[0]=pose_trans(p[0.0,0.0,0.0,0.0,0.0,0.0], pose_trans(p[-.125411965673, .507863069974, .072258810602, .000280592855, .002182883592, -.006370729833], ScrewM3_1_p))

In the Editor on the robot these two look the same, is there a better way i should use to save waypoints in a array?

After some testing, rewriting the script that saves the array will change it back to use the base feature, I have not figured out when it changes to use 0,0,0,0,0,0 instead.

When you click “OK” and save a waypoint, a few different bits of data are stored to ensure the robot can behave as closely to how you would expect as possible. It will save: the waypoint in the base coordinate system, the feature data when the waypoint was saved, the name of the feature when saved, as well as the joint positions when the waypoint was saved (this is only used for movej calculations). You can see this when you run a program with a point saved in a coordinate system. Below is the URScript of a program with a waypoint saved in a feature, Plane_1. Plane_1 is set to be a feature with coordinates p[0.1, 0.2, 0.3, 0, 0, 0].

global Waypoint_1_p=p[-.189631536923, -.609683881651, .260971148694, 1.195733634588, 2.889959482257, .051068157969]
global Waypoint_1_q=[-1.6006999999999998, -1.7271, -2.2029999999999994, -0.8079999999999998, 1.5951, -0.030999999999999694]
while (True):
  $ 2 "Robot Program"
  $ 3 "MoveL"
  $ 4 "Waypoint_1" "breakAfter"
  set_tcp(p[0.0,0.0,0.0,0.0,0.0,0.7853981633974483])
  movel(pose_trans(Plane_1, pose_trans(p[-0.1, -0.2, -0.3, 0, 0, 0], Waypoint_1_p)), a=1.2, v=0.25)
end

You can see that to move to waypoint 1, the robot applies 2 pose trans functions. the innermost is pose_trans(inv(Plane_1), waypoint_1_p) This returns where the waypoint was in its frame, when it was saved, in the frames original data, i.e. how to get to waypoint_1 in Plane_1. This is done in case the selected frame is changed and a different one selected, or in case the frame itself is retaught. The second pose_trans then moves to that position, in the coordinate system of the currently selected feature, which in this case is still Plane_1. This is done so that if the feature is changed, the robot will still move to th same position in the new coordinate system.

If you want to fetch your positions in their respective features, you can do that by mimicking the first pose trans. If you have a pose in base that you want to convert to a different coordinate system, you do the following

pose_trans(pose_inv(system), pos)

I hope this helps

1 Like

Thank you that was a very good description.

I wonder if i confused the GUI by trying to run the program with the waypoints commented out and that caused the feature to be reset to p[0,0,0,0,0,0].
I’m a bit worried how they just changed over to no longer use the base as reference, I have to do some experimentation to see when this happens.

It seems the position “math” can quickly become quite confusing and complicated :slight_smile: