Pally 3.4 Vs. Pally 3.3.2 – A Study

An analysis and performance graphs of Optimove effects.

Executive Summary

Pally v.3.4, leveraging the new Optimove feature in Polyscope 5.21, significantly enhances cycle times, payload handling, and robot longevity. Our in-depth simulation study, comprising 62 simulations, confirms that Pally 3.4 delivers a substantial increase in picks per minute with up to 56.9% faster in some cases.

Key Findings

Acceleration optimization: The primary driver of performance improvement is Optimove’s ability to enhance acceleration, rather than increasing maximum speed.
Impact of safety settings: Customizing safety settings, particularly allowing higher force thresholds, can further maximize cycle time gains.
Payload effects: While improvements are evident across all payloads, the increase is most pronounced for lighter loads. Heavier payloads still benefit but are influenced by factors such as gripper type and payload stability.
Real-world insights: Early data from integration partners and lab testing indicate 20-35% cycle time improvements, validating the simulation results.

Implications

For those implementing Pally 3.4, adjusting acceleration settings and optimizing safety parameters are key to unlocking its full potential. While lighter payloads see the most dramatic improvements, heavier loads can also benefit, provided appropriate grippers and stabilization strategies are in place. These findings make a strong case for upgrading to Pally 3.4, ensuring better efficiency, reduced cycle times, and more flexible palletizing performance.

Introduction

As you may already know, Pally v.3.4 is leveraging the Optimove feature in Polyscope 5.21 which was recently released. You may also have received our newsletter about it where we highlight the key benefits like higher cycle time, improved payload handling and increased longevity of the robot. As stated in Rocketfarms public channels, we see up to 35% higher cycle times, but behind the number, there’s more to understand. As an example, we find over 50% cycle time increase in our simulations, but also as low as 2%. Needless to say, it matters what scenario we look at.

So we decided to run a simulation study, and after 100s of simulations where we had to start over a few times to create as good as possible comparable and realistic scenarios, we now have a dataset of 62 simulations which we believe gives quite good results and insights.

To add to the simulations, we also have some experience with physical installations from partners which we will refer to in the end as well.

So, let’s dig into it!

Difference between Pally 3.4 and Pally 3.2.2

Pally 3.4 is using the Optimove upgrade available in Polyscope 5.21
Improved path planning on the return path

Other fixes in release notes: Pally Official Download page

How Did We Test

Digital twin simulations made in Myrobot.cloud.
Used identical HW setup, simulating with UR10 and UR20 using a vacuum gripper with 100mm Tool Centre Point offset.
UR10 was combined with a lift, while UR20 was not.
Equal SW settings where applicable, then running it with Pally v.3.4 + Polyscope 5.21 and Pally v.3.3.2 + Polyscope 5.20.
For 3.3.2, we used Pally Max Acceleration setting = 2100 mm/s^2. This because it was what we recommended in real life and because safety stops would occur frequently over this value. For the Pally Speed setting, it was set equal to the max safety setting.
For 3.4, we used Acceleration = 40% and Speed = 100%
Tested with the payloads 1kg, 11kg and 22kg on a Europallet (1200mm*800mm)
Used URs standard safety settings, but also added custom settings where Tool Force was set to 250N (as in the default Least Restricted safety settings) combined with lower MAX TCP speed of 750, 1250 and 2500 mm/s.
The final dataset contains 31 simulation tests comparing Pally 3.4 and Pally 3.3.2. That is 62 simulations in total.
A snapshot of the palletizing pattern and simulation setup can be seen below.

Pally 3.4 is substantially faster!

Of that, there is no doubt. In our simulations, up to 56,9% Picks per minute increase was recorded, going from 8.33 to 13.07 picks per minute for a 1 kg Payload.

Acceleration is Key!

Shortly spoken, Optimove optimizes acceleration. And acceleration is very important for overall performance. While performance is dramatically increased in picks per minute, the overall MAX speed does not increase accordingly. In some tests, it actually declined.

Customizing your Safety Settings

We are aware that many UR integrators out there simply use the default “most restricted, restricted, less restricted and least restricted”. To leverage Optimove to the fullest however, allowing Optimove to use higher force counts a lot. In other words, configure your safety settings manually and increase force if you want to achieve higher robot cycle time without changing the robot MAX speed safety setting.

In the chart below, both safety settings have a max speed of 750mm/s, but in the Custom max 750, every other setting is set to the same as the default “least restricted”. Even in Pally 3.3.2, this difference is obvious, achieving an added 2,5 picks per minute. In Pally 3.4, this effect is even higher, achieving ca 3,5 extra picks per minute in this 1 KG payload example using a UR20.

The Lesser the Restrictions, the Bigger the Effect

The Optimove improvement increases in %-age as the safety settings get less restricted.

This is an expected result. As Optimove primarily improves acceleration, the more time you accelerate and decelerate during a given time frame, the more Optimove will be in use, and as result, the %-age improvement increases. So in the most restricted safety settings, the cycle time rate is not affected as much. And at the “most restricted” there´s not much to gain.

Picks Per Minute Effect for Heavier Payloads

As expected, for heavier payloads, we still see great improvement, but not as much as for lighter payloads. What is obvious, is that for Pally 3.3.2, payload did not matter that much on picks per minute. While for Pally 3.4, its payload has more impact. Maxing out on 13 picks per minute in the 1kg scenario, it maxes out just below 11 picks per minute for the 22kg scenario.

In Real Life – What to Expect

So the numbers here are from simulations, what are the real life effects?

In general, the simulations we run in Myrobot.cloud run on the same software stack as a real robot is doing in the real world, calculating and executing the same moves with the same speeds as in real life. So from a simulation perspective, it is among the most accurate you will find. With the introduction of Optimove, representing a significant change to how the robot deals with the actual physical payload in runtime though, simulating it is more difficult than before. So it is important for us to receive more data from real life palletizing with Optimove before we can state for certain what the effect is.

But although we do not have much data from real life customers yet, we do have some datapoints.

From 2 different integration partners, we have already received feedback that for two different projects where cycle time was an issue, Pally 3.4 solved the problem, with one of them responding that cycle time increased 35%.
Extensive lab testing done by one of our most experienced partners found, on their own standardized setup, a 20%-25% increase in picks per minute for payloads comparable to our 11kg simulations.
For “light”, we assume then that the simulations have a high accuracy as the impacting forces on the system are not as significant, and a real world scenario would be closer to a “pure software” environment scenario.
For heavier payloads, we don´t have much data yet, but
In general, if you already have experience in palletizing with Pally, you have your own standardized solution, and wonder how to interpret the data in your next offer; it is fairly safe to say that calculating with 20% increase in picks per minute is a good starting point.

Heavy Payloads in Real Life

The most important limitation of these simulations is that the physical behaviour of the payload during movement is not accounted for in a good way. In our simulations, we set the acceleration variable to 40% in accordance with what we experienced in real life worked well “in general” during testing Optimove in the lab.

However, for heavy payloads with a low center of gravity, combined with a gripper which does not stabilize the payload during transit, there is a high chance you may need to reduce the acceleration variable further, dramatically reducing the effectiveness of Optimove altogether.

For heavy payloads, It would be expected that a gripper with a firm grip of the product, preventing the payload entering into sway movements, would be much closer to the simulated result than a gripper having the payload “hang” freely under it.

That is, clamp gripper Vs vacuum gripper can play a major difference in Pick Per Minute performance. As we in these simulations used vacuum grippers, it can be argued that we both got the benefit from “low grab and release time” combined with an absolute stable product during transit as this is not accounted for in our simulations.

So in general, these simulation results have caveats which are important to understand. In particular when we are talking about heavier payloads close to robot limits.