Hi,

in our PC based UR robot application we would like to provide a control panel for manual robot control of an URe robot like you know it from the UR robot teach pendant. That means the user should be able to manual move the robot in tool space (with respect to tool) and in base space (wrt base). We are almost there. We use the servoj command to implement this kind of control. To do this, we manipulate the pose that is given in cartesian space and then convert this with the get_inverse_kin function into joint position that are passed to the servoj function (see the thread jog_thread(): function here: https://gitlab.com/gitlabuser0xFFFF/ur_rtde/-/blob/uk_dev/scripts/rtde_control.script).

A UR robot pose is given as p[x,y,z,ax,ay,az], where x,y,z is the position of the TCP, and ax,ay,az is the orientation of the TCP, given in axis-angle notation. The x, y and z coordinates are seen from the Base position whereas the Rotation (ax, ay, az) of the Tool head is seen from the tool head position itself. To move with respect to the base frame, we can simply add a value to the x, y, z coordinate of a pose. To move with respect to the tool, we use the pose_trans function like it is written here (https://www.universal-robots.com/articles/ur/urscript-move-with-respect-to-a-custom-featureframe/). To rotate with respect to the tool, we can simply add an angle to the ax, ay and az part of the pose. This all works perfectly fine. But in the teach pendant it is also possible, to rotate with respect to the base frame. And this is something that we do not know how to implements this. That means, we do not know, how to translate a pose rotation wrt to the tool into a rotation wrt to the base frame.

Hi Uwe,

You should be able to use pose_trans to accomplish this. A pose p[x,y,z,ax,ay,az] describes the TCP completely in base coordinates. Your statement makes me believe this is a misunderstanding.

p1=p[0,0.5,0.5,2.22,-2.22,0]
#movej(p1)
textmsg("p1 ", p1)
pr=p[0,0,0,0,0,1.57]
p2=pose_trans(pr, p1)
textmsg("p2 ", p2)
#movej(p2)

We have not figured it out yet ourselves. But based on the idea above have one idea. 

@ukindler Ahh I misunderstood. It's actually just switching the parameters of `pose_trans`

p1=p[0,0.5,0.5,2.22,-2.22,0]
#movej(p1)textmsg("p1 ", p1)
pr=p[0,0,0,0,0,1.57]
p2=pose_trans(p1, pr) # params switched from previous example
textmsg("p2 ", p2)
#movej(p2)

I believe that still just rotates around the z axis of p1, since it’s aligned with the base it works but if you rotated the tool to be not aligned in the z axes I believe that will not work, at least as I understand the use case. The frame of reference for the pose_trans is still P1

Here's a quick GIF that I put together showing the tool not aligned in the Z axis of the base frame, you can see using a pose_trans with p1 that only wrist 3 rotates since the pose_trans (or pose_add) is rotating in the tool frame of reference.  If you put the arm into the p1 position on the move screen and then in base frame use the +RZ button you will see that more than just wrist 3 rotates.  That is the use case that I would like to solve for or understand how UR does that on the move screen.  @ukindler assume that what I captured in the GIF is not the behavior you are looking for either correct?

Well I repeated the same mistake and misunderstood.

Third time is the charm?

p1=p[0,0.5,0.5,2.22,0,0]
movel(p1)
textmsg("p1 ", p1)
pr=p[0,0,0,0,0,-1.57/2]
p2=pose_add(p[p1[0],p1[1],p1[2],0,0,0], pose_trans(pr, p[0,0,0,p1[3],p1[4],p1[5]]))
textmsg("p2 ", p2)
movel(p2)

p1=p2
p2=pose_add(p[p1[0],p1[1],p1[2],0,0,0], pose_trans(pr, p[0,0,0,p1[3],p1[4],p1[5]]))
textmsg("p2 ", p2)
movel(p2)

p1=p2
p2=pose_add(p[p1[0],p1[1],p1[2],0,0,0], pose_trans(pr, p[0,0,0,p1[3],p1[4],p1[5]]))
textmsg("p2 ", p2)
movel(p2)


p1=p2
p2=pose_add(p[p1[0],p1[1],p1[2],0,0,0], pose_trans(pr, p[0,0,0,p1[3],p1[4],p1[5]]))
textmsg("p2 ", p2)
movel(p2)

@jelms that is awesome, thanks for that.  I had tried something similar last night but forgot the pose_trans as an argument.  I have tested in the simulator and that appears to do exactly what we have been looking for.  I wrote a small script function that would make this easier to use in an actual program, it works like a pose_add but adds the rotational element in the base frame.