I’m chasing down a bug in the Palletizing template, and I wonder if anyone else has any insight on the issue. Here is what I’m observing:
In some cases during program execution, the placement of objects in the Palletizing pattern seems to be shifted as though it is using a different Feature or TCP than was used for programming the Corner Item positions. If I stop the program and manually command the robot to move to each Corner Item position, the robot moves to the correct positions.
Can anyone think of a case in which the reference points used for incrementing the Palletizing locations could be erroneously associated with the wrong TCP or Feature? Any ideas on other possible causes of this issue?
Iv’e run into a number of issues with palletizing. Position while programming and runtime are often different.
The only way I’ve found to fix most issues in palletizing is to run through the wizard again from scratch. Manual set the pallet position or TCPs also does not seem to provide the expected operation at runtime.
Our multi tool mount can mount 3 tools. No matter what TCP we set, the pallet node often picks the wrong one whether we set it specifically or “use active TCP”.
I didn’t see anything in the patch notes about palletizing but I will give it another try.
Edit: Currently program is behaving with version 5.8 but not fully tested. At least it is now picking the correct TCP for the output pallets. I can’t say why it started using the wrong TCP previously so hopefully this continues.
We did indeed have 3 separate pallet sections in the program. Input, and then output pass and fail pallets. 3 separate TCPs used in the program but only 1 TCP used for the pallet load/unload.
We are still experiencing this problem in a depalletising program where we have to be very precise, the UR10e is not going to the position that we have programmed.
To clarify, when I drive the robot to the waypoint in manual mode (local) the position is correct, then on automatic mode (remote) it can be between 2-5mm out in x, y or z.
We updated to the latest version of the Polyscope software and are still experiencing this problem. The only workaround I have is to observe the robot on auto mode and then adjust the programmed waypoint by the inverse of the offset.
This may be completely unhelpful but I had a similar issue where I discovered that my waypoint was linked to another or shared parameters with another. I would recommend doing a double check that your waypoints are not linked to others, are not J movements but are L movements instead and have no blend radii. These issues will cause a point to be slightly off of where you need it to be in automatic mode but not necessarily in manual mode. This is especially easy to miss if you are setting up relative movements. Beyond that, I have no clue what your issue could be, sorry. Hope you get it figured out though!
Editing to say that my specific issue was a waypoint that was using shared parameters with another waypoint that had a blend radius on it. This caused my waypoint to be slightly off every single time I ran it in auto mode until I removed the blend radius, then it worked perfectly.
I found the built in palletizing a little clunky and wasn’t sure how to resume where I left off if the program got stopped.
Anyway I ended up writing these 2 functions to allow for more control over palletizing routines.
The get_tray_pos function returns a pose that can be used to pick or place a tray, this pose can be assigned to a variable and used in a variable position waypoint.
The get grid XY pos function also returns a pose, in this case the position of the selected pocket (could have a part or for dropping off a part) and the origin is based on the center location of the corner pocket and the Z height can be set to whatever you need.
def get_tray_pos( tray_selected , spacer_offset = 0, z_offset = 0.047):
# Returns the pose for picking or placing a tray
# If placing, `tray_selected` should be the target
# tray position.
tray_grip_pos = p[ 0, 0, 0, 0, 0, 0]
tray_grip_pos[2] = (z_offset + spacer_offset) * (tray_selected - 1)
return tray_grip_pos
end
def get_grid_XY_pos( pocket_selected = 1,
rows = 3,
columns = 4,
X_spacing = 0.135,
Y_spacing = 0.135):
# Returns a pose variable with the X,Y coordinates
# of the `pocket_selected`.
# Can be used for any grid size and spacing
# by changing the default arguments
# Default grid: (center of Pocket 1 is X0,Y0 Origin)
#
# Y+
# ↑
# ------------------
# row3 | 3 6 9 12 |
# row2 | 2 5 8 11 |
# row1 | 1 4 7 10 |
# ------------------
# col1 col2 col3 col4 COLUMNS → X+
sync()
#Check tray part capacity
#(verify that selected part is within range)
part_capacity = 1 * rows * columns
if ((part_selected <= 0) or(part_selected > part_capacity)):
popup("Part selected is out of range!", error=True, blocking=True)
end
row = ( (pocket_selected - 1) % rows )
column = floor( (pocket_selected - 1) / rows )
XY_pos = p[0,0,0,0,0,0]
XY_pos[0] = XY_pos[0] + ( column * X_spacing )
XY_pos[1] = XY_pos[1] + ( row * Y_spacing )
return XY_pos
end