Universal Robots Forum

Change Payload Based on variable and/or Grid Position?

I’m new to robots (2 years) and most of my learning was done via trial and error at the machine. Sorry if this seems basic or I’m wording it wrong. :slight_smile:

I use a grid pattern to load a CNC machine with 140 parts on a table. I use custom fingers and nudge parts into the corner of the grid to make sure it’s positioned correctly to pick up. I use the Direction function with Until Contact

When the arm is extended to the outer edges of the table, the arm swings and shakes a lot more than when it’s closer to the base. Also, and more importantly, the Until Contact seems a lot more prone to stickyness (false positives?) than when it’s close to the base.

Can I use a script to increase / decrease the payload based on it’s position on the grid, so as the arm extends out the payload increases? I’ve noticed the arm shakes less when the payload is heavier, especially when extended out.

I already have a variable that counts parts and use that to change the way I nudge parts against the stop (because I hit singularity while out at the extents). I think I could use that variable to also change the payload but I’m not sure what or how to implement it.

1 Like

Hey Rekd

Welcome to the forum. Nice profile pic :stuck_out_tongue:

Would it be possible for you to post a picture of the application? If we can’t help you with the specific script question, maybe it will be easier to help with a workaround if we see the whole thing.

1 Like

Thanks :rofl:

I have 2 UR10e’s doing basically the same thing so I’ll show picts of both to show what I mean.

When the arm is next to the base it’s fine…

When the arm extends out away from the base it loses rigidity.

Here’s where I nudge the part into the corner. Video is sped up 2x.


When doing this nudging at the outter edge of the pallet, sometimes the shaking makes it think it’s against a stop but it’s not.

Let me know if you need more info.

Hi there,

My first concern would be is the robot’s base mount rigid enough? If there is some wobble there (lack of rigidity) then this could be contributing to the problem. My 2nd question would be are you confident the payload and CoG are set properly? A good test is to place robot into freedrive and move the EOAT around. While keeping freedrive pressed, if you release the EOAT does the arm drop or rise on it’s own. If it does then payload and/or CoG is not correct.

Assuming these two things are correct then what speed do you approach the part with when using move-until-tool-contact? it should be quite low (~ 50mm/sec)?

The other question is what version of Polyscope are you using?

The base and the pallet table are lagged together and then lagged to the floor. We use the same vention design for both. The base itself seems fairly rigid.

I re-calc’d the payload a few months ago when I was having some other issues. It does not float when I release the tool in freemode (or didn’t the last time I had to move it, I will check again when it finishes this pallet).

For nudging the parts like in the .gif above I’m at 0.5in/sec (12mm).

One thing about the speed when using Until Contact… I’ve found that the slower I go the more prone it is to those false positives I mentioned in OP. If I go faster it makes it through some of those bumps but seems to hit the stop pretty hard so I try to find that thin line where it will not stop on a burr but will not bang into the edge when it touches something.

So I take it from your line of questions you don’t think I should be doing something like what I suggested to try and calm the robot down while it’s extended?

What other options are there? The pallets and bases we set up were agreed upon by the rep that sold us the two UR systems.

Polyscope v5.8.2.

OK, what you are suggesting might work but it’s not what we would normally recommend. There are script functions to do this of course.

However, I would like to see you upgrade to 5.10 first. There have been some changes to 5.10 to improve motor control of the joints at low speed to avoid these sorts of problems. If you could try that first I think it would be best. Also, can you tell me what the s/n of your robot is?

Here is a link to the release notes for 5.10 and you can see what I am referring to WRT motor control optimization :
Release Notes 5.10

I’ll update Polyscope tomorrow.

Robot s/n is 20205000588

Very nice application.
Could it be that the tool actually are detecting a it correctly, but that the first contact is unintended due to the vibrations you mentioned.

Maybe a work around could be to add a retry?
Let say that you store the first contact position and make it retract and then try again. If the second contact position is the same, it is a positive contact. If not, the arm have fund another contact and the first one was false.


Thanks, it’s a work in progress. It’s nice because I do a LOT of “new” parts on the Cobodrill (that’s my name for the cobot on the Robodrill CNC (yellow door), the other one is Cobosan, cuz it’s on a Doosan ) so I’m always running in to new issues to learn and solve. (I love my job! )

Anyway, you’ve set me down another rabbit hole. As soon as I read “due to vibrations” and “add a retry” my mind took off in a dozen different directions looking for solutions. At first I thought adding a longer wait between nudges as the arm got further away, but your suggestion r.e. a retry and / or a specified “finish point” has a lot more functionality in the long term.

I’m going to research some different approaches and will likely be back here for advice on how to implement the code I’ll need (I’m still new to this and haven’t really touched the scripting side of it yet).

Thanks much for the help and advice!

1 Like

Cool. Glad we could help. Enjoy the learning journey. Looking forward to seeing you around here again.

1 Like