Depending on how complicated your palletizing actions are, you may benefit from a script that can shift a feature manually. Polyscope’s built-in palletizing can be pretty handy, but it can also be a major pain to get right. This method will also require fixed distances between parts. This will not account for any irregular patterns:
1st step: Teach a feature. This should be taught to your pallet such that you can use the arrow keys to jog cartesionally along your pallet.
2nd step: Teach all templated moves relative to this feature. This is where an existing program is likely screwed. You can KINDA recover, by switching to the originally taught feature, jogging to a waypoint, switching your feature, and clicking “Set Position” again…for every waypoint. It sucks but can be done. Teach only the actions that you need to perform per part. For example, if I am depalletizing, my pick actions are going to need to shift around, but my place actions might be a fixed drop off point, maybe on a conveyer. For this example, only my pre-pick, pick, post-pick moves need to be taught to this feature.
3rd step: Create a script function to shift your feature. This is a pretty straightforward example for how to leverage the power of features. Instead of trying to add offsets to all waypoints, we can just programmatically move the feature around, and all the moves will adjust automatically.
Imagine I have a 3x4x5 box. That is, 3 units across my Feature’s Y-axis, 4 units across my Feature’s X-axis, and 5 units along my Feature’s Z-axis. Again this assumes that this is a uniform box, with the parts I’m depalletizing at regular intervals. Then all I need is those fixed distances: an x, y, and z offset. (These can be user input at the beginning of each program run, or hard-coded installation variables). You’ll also want current_part, total_parts, x_rows, and y_column variables. The current_part becomes something the user can input to determine where to begin the depalletizing program. total_parts would be how many parts are on a full pallet (or can also be user input if you’re doing some sort of half pallet). x_rows and y_columns contain the dimensions of your pallet. In my proposed example, the variables would be as follows: (remember all dimensions are in METERS!)
And the script required to pattern, or palletize anything is this: (you can omit the “global” modifiers on the variables, I included them so they are visible during program execution for debugging.)
def palletize(x_offset, y_offset, z_offset, current_part, feature):
global z_layer = floor(current_part / (y_columns * x_rows))
global row_number = floor(current_part / y_columns) - (z_layer * x_rows)
global column_number = floor(current_part % y_columns)
return pose_add(feature, p[row_number * x_offset, column_number * y_offset, z_layer * z_offset, 0, 0, 0])
end
Here is a Polyscope program I threw together that utilizes this script. It just takes the robot to a single pose, waits for half a second, and then shifts the feature. You will notice it takes the single taught waypoint and moves it to 60 different locations. That being my length x width x height of my imaginary box. The biggest stipulation here is understanding the difference between selecting your feature from the “Pose” dropdown, as opposed to the “Variables” dropdown. The one with the _const suffix is the pose set as soon as you teach the feature, and CANNOT be programmatically changed. The feature available via the “Variables” tab does not have this suffix, and can be changed programmatically. I am assigning this non-const version to the result of my palletizing function, and passing in the “const” version of the same feature. (Another thing to note is that this const feature MUST be selected from the dropdown. Typing it out manually does NOT work, for some reason.)
You’ll notice at the beginning you can prompt the operator for a part to start at, and the script will offset to this position in the “box.”
Then of course you could take this the extra mile and develop a URCAP that condenses all the nasty script into a clean user interface. (I originally wrote this for purely x-y shifting, but your question inspired me to add the Z dimension. I’ll have to update my CAP now lol)
Anyway sorry for the incredibly long-winded post. Hopefully you can pull something useful out of it, otherwise it will be decent documentation for myself when I go to update my CAP and inevitably forget everything I’d done.
