TCP pose in feature coordinates - save as a variable waypoint

[blaz.janezic]

Hi,

i tried to get a TCP pose of a waypoint in feature coordinates according to method described in the thread: How to get tcp pose in feature coordinates?
(poseInFeatCoordinates=pose_trans(pose_inv(waypointPose),featurePose))

In order to get my original pose (TCP w.r.t base) i made a call calculatedPose = pose_trans(featurePose,poseInFeatCoordinates) and the values seem coorect.
calculatedPose= p[x,y,z,a,b,c] and is the same as a waypoint pose (waypointPose) set by hand in polyscope. Which is expected.

Problem is, if i set a waypoint as a variable and assign calculatedPose which vector is exactly the same as a waypointPose, robot makes a strang and twisted move to a waypoint, never reaches necause it ends up in protective stop (joint limits or in my case self collision). If i set a waypoint “by hand” (p value is the same as calculatedPose) robot is able to make the linear move without a problem.

What the heck is going on here?

Have a great day, B.

[anna]

Hi,

Usually when that happens to me, it is because the z axis of either my TCP or my plane feature is pointing the opposite direction from what I am assuming. It is trying to orient your TCP z axis either straight up or straight down.

I got around this by defining fixed values for my Rx, Ry and Rz in the position vector I built for the target position, so that it would not figure out its own rotation, and only calculating my x and y in the feature coordinates using the coordinate transform.

-Anna

[blaz.janezic]

Thank you so much for additional insights!
But there’s the thing that I really can’t wrap my head around: Isn’t the waypoint (TCP position) uniquely defined by the pose vector w.r.t base? In that case, doesn’t that mean that I shouldn’t be observing two different moves?

Blaz

[anna]

This topic might help:

UR5+vision - coordinate system difficulties

@anna The axis angle rotation vector that a pose is generically represented as are sometimes rather hard to grasp just off the top of your head. One axis of rotations works fine, but multiple angles at a time will most likely not give what you expect - however the result is most likely right anyway. There are also multiple representations for the same angle. Did you try moving to that position, to see if the robot actually went to the expected place? You can however easily convert from rotati…

[blaz.janezic]

Hi Anna, thank you for the most useful advices!
I was able to find the solution, which was actually a two step way: I adjusted the Z-axis of my TCP to be parallel to my feature and if had experienced any problems, i just reassigned any waypoint variables. I noticed that in some cases, if i had changed my waypoints, some assigned variables (var a = waypointX) haven’t updated to new values and caused problem during moves, defined by these variables.