I’m developing a URCap for a welding application that uses weaving. I’m using the URScript command “path_offset_set” to accomplish this. Everything’s working, except the angular orientation is relative too the tool flange rather than TCP. I need weaving to be relative to the TCP. From what I can tell, an offset in the X-direction is parallel to the path of the TCP. An offset in the Z-direction is parallel to the tool flange direction (NOT the TCP direction). And an offset in the Y-direction is perpendicular to both of the previous two (the cross product).
Is this a bug? Is weaving really supposed to be relative to tool flange coordinates? Am I meant to manually apply the rotational calibration for the TCP when using the path_offset_set command in order to get the Z and Y weaving offset directions to be relative to the TCP?
I’m already in the process of trying to find a work-around to this - by applying the rotational calibration manually. Some feedback from UR would be nice.
Hi Steven,
When you set the offset with path_offset_set, which type of offset are you applying? It sounds like you’re using type 3, the motion offset, as the extract in the script manual seems match your description. You might wish to consider sing one of the other offset types in order to acheive your required functionality. See the screenshot from the script manual below:
If you are interested, we (Olympus Technologies) have developped a weaving URCap already which encorporates multiple configurable weaving patterns, which is being released to purchase soon. If you are interested in discussing it, feel free to drop me a PM and we can talk more.
Hi Steven,
A few weeks ago I encountered this kind of problem, I noticed that the set_path_offset function doesn’t update the reference frame of the TCP if defined different from the flange one in the installation tab, as a consequence both for mode 2 and 3 if you have a different setup for the TCP than (0,0,0,0,0,0) [coincidence with flange ref frame] you will not have the expected result in the motion. As a workaraoun i wrote a script that adjust the offset considering the real TCP ref frame for set_path_offset mode 2.
#Author: Alberto Novazzi alno@universal-robots.com
#Author: Pietro Castelli pica@universal-robots.com 12/02/2020
#Poliscope version 5.6
def pose2list(pose):
return [pose[0], pose[1], pose[2], pose[3], pose[4], pose[5]]
end
def path_offset_tcp( offset ):
# offset <pose, list> : Pose specifying the translational and rotational offset with respect to the current TCP frame
tcpOffset = get_tcp_offset()
pathOffset = pose_trans( p[0.0, 0.0, 0.0, tcpOffset[3], tcpOffset[4], tcpOffset[5]],p[offset[0], offset[1],offset[2],offset[3],offset[4],offset[5]])
pathOffsetRot = pose_trans(p[0.0, 0.0, 0.0, tcpOffset[3], tcpOffset[4], tcpOffset[5]], p[offset[3], offset[4], offset[5], 0.0, 0.0, 0.0])
pathOffset[3] = pathOffsetRot[0]
pathOffset[4] = pathOffsetRot[1]
pathOffset[5] = pathOffsetRot[2]
path_offset_set(pose2list(pathOffset), 2)
end
I created a bug report for this problem, so that in the future it will be fixed, until then feel free to use this script.
Best Regards
Castelli Pietro
Thanks for your quick response! I will try your work-around soon.
Yes, I am using type 3. Just today, I added the ability to select from types 1, 2, and 3 in my URCap. The “motion” type seems to not always behave as I want, so I will try using “TCP” instead. I will mention your URCap to management of my company. Thanks!
I am having a similar issue, the tcp we have is at an angle to the tool flange. During testing, if I align the tcp z axis to the base z axis, teach a moveL in the direction of base x only, and use path offset type 3 with a variable in the [0,X,0,0,0,0] position, it should only alter movement in the base y direction, now I rotate my tcp about the z axis. The motion should still only be altered in the x or y direction depending on the orientation, no offset should be applied in the z direction, though I am seeing that the y axis of motion using the path_offset_set(type 3) is not perpendicular to the z axis of the base like it should. The documentation states that:
3: (MOTION) Use a coordinate system following
the un-offset trajectory when applying. This
coordinate system is defined as follows. X-axis
along the tangent of the translational part of
the un-offset trajectory (rotation not relevant
here). Y-axis perpendicular to the X-axis above
and the Z-axis of the tool (X cross Z). Z-axis
given from the X and Y axes by observing the
right-hand rule. This is useful for instance for
superimposing a weaving pattern onto the
trajectory when welding.
I think that the actual calculation is being done with the flange z axis, not the tool z axis.
Does anyone know a way fix this?
Hi Taylor,
In our office we struggled a lot with the weaving mode and after we found a fix for mod 2 a colleague of mine wrote a fix for mod 3.
The following script will give you the correct motion frame wrt the base frame; I attached it in a .zip file below.
get_motion_frame.zip (1.2 KB)
Best Regards
Pietro C.
Well I am glad that it’s not just me that can’t figure out the weaving. Do you have an example on how to integrate your GetMotionFrame function into the path_offset_set command?
Could you provide a sample on how to integrate the code you wrote into the path_offset command?
Hi Taylor,
Depending on the pattern you want to impose implementation may vary but should go something like this:
Suppose you have a thread in which you calculate the required offset expressed in motion frame:
Thread:
some calculations
d=p[x,y,z,rot1,rot2,rot3]
Then to express d wrt the base frame and not the motion frame you will do:
d_base_frame = pose_trans(motion_frame, d)
In the end you can easily apply the path offset in mode 0, base frame, of the quantity d_base_frame
Hi
My testing suggests that polyscope 5.9.1 has fixed this issue about the mode 2 using flange z rather than tool z when a tool with a non zero orientation is defined. However, there is nothing in the release notes about this being fixed.
Has this bug been formally addressed, can I trust that this problem is fixed for this and future releases of polyscope or do I still need to apply a work around?
Thanks
Hello @matthew.pearson,
I just ran a test using 5.9.1 and an offset TCP and can verify the issue is resolved with mode 3 as well. I ran the same setup on 5.7 and 5.9.1 to verify.
I checked with our internal team and the bug originally submitted regarding motion frame 2&3 not taking into account the active TCP offset has been marked as completed and flagged to have released with 5.9.
Thank you very much. That’s great.
We have tested as well and can confirm it’s resolved with mode 3 as of 5.9.1.
Is it possile to do weavig in cb series? If yes, culd you please describe me how?
It is possible, though I’m afraid that you have to go about it in a more brute force manner, as the path_offset functions ar not available in CB3 URScript. We have created a straight line weaving URCap for CB3 if that is something of interest to you?