Wrist 3 - wind up the cables

Technical Questions URScript
1

Hello,

i´m using the palletizing function for a picking task. In some cases the wrist 3 wind up the cables, because the way to the next picking position is shorter. How can it be prevented?

Palletizing function:

$ 1 “Roboterprogramm”
$ 2 “Pallet_1”
def Pallet_1_trans(pose):
return p[pose[0], pose[1], pose[2], 0, 0, 0]
end
def Pallet_1_rot(pose):
return p[0, 0, 0, pose[3], pose[4], pose[5]]
end
def Pallet_1_compute_pallet_waypoint(T_base_feature_taught, T_feature_referencePoint_taught, T_referencePoint_approach_taught, T_base_feature, T_base_referencePoint):
local trans_referencePoint_approach_in_feature_taught = pose_sub(Pallet_1_trans(pose_trans(T_feature_referencePoint_taught, T_referencePoint_approach_taught)), Pallet_1_trans(T_feature_referencePoint_taught))
local rot_referencePoint_approach_in_feature_taught = pose_trans(Pallet_1_rot(T_feature_referencePoint_taught), pose_trans(Pallet_1_rot(T_referencePoint_approach_taught), pose_inv(Pallet_1_rot(T_feature_referencePoint_taught))))
T_feature_referencePoint = pose_trans(pose_inv(T_base_feature), T_base_referencePoint)
rot_referencePoint_approach = pose_trans(pose_inv(Pallet_1_rot(T_feature_referencePoint)), pose_trans(rot_referencePoint_approach_in_feature_taught, Pallet_1_rot(T_feature_referencePoint)))
T_feature_approach = pose_trans(trans_referencePoint_approach_in_feature_taught, pose_trans(T_feature_referencePoint, rot_referencePoint_approach))
T_base_approach = pose_trans(T_base_feature, T_feature_approach)
return T_base_approach
end

…
…
…
if (Pallet_1_cnt < 193):
Pallet_1_lno = 1
Pallet_1_lct = Pallet_1_cnt
global CornerItem_1=pose_trans(p[0.0,0.0,0.0,0.0,0.0,0.0], pose_trans(p[-.000000000000, -.000000000000, -.000000000000, .000000000000, .000000000000, .000000000000], p[.534333881170, .036306233589, .023011090386, 2.226175968418, -2.216685620206, -.000015293369]))
global CornerItem_2=pose_trans(p[0.0,0.0,0.0,0.0,0.0,0.0], pose_trans(p[-.000000000000, -.000000000000, -.000000000000, .000000000000, .000000000000, .000000000000], p[.534090521706, .240272692895, .022798562188, 2.226601946160, -2.214743300707, -.000178770249]))
global CornerItem_3=pose_trans(p[0.0,0.0,0.0,0.0,0.0,0.0], pose_trans(p[-.000000000000, -.000000000000, -.000000000000, .000000000000, .000000000000, .000000000000], p[.257241769930, .241586239236, .022956831482, 2.225939099323, -2.215246453788, -.000121588498]))
global CornerItem_4=pose_trans(p[0.0,0.0,0.0,0.0,0.0,0.0], pose_trans(p[-.000000000000, -.000000000000, -.000000000000, .000000000000, .000000000000, .000000000000], p[.257259763612, .038083660152, .022970321133, 2.226090811413, -2.215097743479, .000053760646]))

Pallet_1_cnt_x = (Pallet_1_lct - 1) % 12
Pallet_1_cnt_y = floor((Pallet_1_lct - 1) / 12)
referencePoint = interpolate_pose(interpolate_pose(CornerItem_1, CornerItem_2, Pallet_1_cnt_x/11), interpolate_pose(CornerItem_4, CornerItem_3,Pallet_1_cnt_x/11), Pallet_1_cnt_y/15)
direction = p[0,0,1,0,0,0]
referencePoint = pose_add (referencePoint,p[0.0*direction[0],0.0*direction[1],0.0*direction[2],0,0,0])

end

Repeated movement:

$ 25 “Erzeugte Bewegungen” “noBreak”
$ 26 “FahreAchse” “noBreak”
$ 27 “Approach_1_j≔get_inverse_kin(pose_trans(referencePoint,p[0,0,-(ToolLength+OverToolPickPar-75)/1000,0,0,0]))”
global Approach_1_j= get_inverse_kin ( pose_trans (referencePoint,p[0,0,-(ToolLength+OverToolPickPar-75)/1000,0,0,0]))
$ 28 “Approach_1_j” “noBreak”
movej(Approach_1_j, a=6.98, v=3.14)
…
…
…
global Approach_3_j= get_inverse_kin ( pose_trans (get_actual_tcp_pose(),p[0,0,-(ToolLength)/1000,0,0,0]))
$ 49 “Approach_3_j” “noBreak”
movej(Approach_3_j, a=1.39, v=1.04)

2

In a MoveJ, you can check a box that says “Use Joint Angles.” This should stop the robot from taking the shortest path and instead favor getting the exact same joint angle.

3

Still the same problem :confused:

4

I’ve heard people giving the same sentiment before. It probably comes from using the Palletizing thing. Seen a lot of people post with issues using it. I have an application where I spin only wrist 3 all the way from -360 to +360 as it spins an object through a scanner. So I know this is the intended behavior of MoveJs in general. Any chance you can remove this section of code from the Palletizing template, at least just as a temporary test to see if it does what you expect OUTSIDE of the palletizing?

5

Redo your palletizing pattern with the correct gripper set active and make sure, that your wrists are at the correct poisition as well.

The palletizing assistant has a problem:

If you teached a point after the palettizing and turn it 360° at the same position and then check the path to the teached position in the palettizing assistant with the button “go to this position” it will not go to the position with the teached wrist angle, but with the shortets way / wrist twist.