Using infinite rotation on UR3 to sand a wooden cup on belt sander

Technical Questions
1

Hello,

I am looking to program a UR3e to grab the inside of a wooden cup and sand the outside of the cup on a belt sander using a force move. In theory this seems easy but because my movement isn’t linear, I am having some issues. How would I program the movement to match the contour of the cup and simultaneously be rotating the tool? Any tips would be great as every solution I think of does not work how I imagined it to. The rotation of the tool is necessary to avoid possible flat spots from the sander.

Thanks in advance,

IMG_4849
IMG_48494032×3024 1.83 MB

2

Hello-

If I’m understanding this correctly, you would like to rotate the tool flange unlimited rotation, and at the same time make small incremental movements in z,y, and/or x-axis directions while doing this? to accommodate the cup shape?

One way that comes to mind would be to use UR script function.

  • Set up a series of MoveL commands in a script function

  • increment these by whatever value is needed in for the cup dimensions-specifically increment the pose parameter in the movel command

  • Loop this function for however long you need to complete the sanding, and however many points are deemed appropriate

Here is the UR script manual for the e-series with the latest version of Polyscope software. You can navigate to page 32 for more info on movel command: Universal Robots - Script manual - e-Series - SW 5.10

3

Another idea is to setup a plane feature on sander, and use force mode in plane z axis.
Then use movej for rotation.
There is not a lot of control over force mode parameters, so sanding should be quite gentle to avoid oscillations (along compliant axis), and position deviation errors (along non-compliant axes).

4

Does the movel command respect the actual rotational value of the tool in urscript because in normal moves, the movel and movep just ignore the rotational value I have set for the waypoint and just go to the closest 360 value. movej seems to be the only one that will respect the actual position I set for rotation.

5

You are correct-MoveJ can move with respect to the actual position you set for rotation. Be sure you are checking the ‘use joint angles’ box in the MoveJ command for this to happen.

some other options to investigate for this application can be found below.

6

I have tried the second option but I can only get it to work while doing a straight line. I can’t get it to react How I want while following the contour of the cup. This is just for a Proof of Concept right now so I probably won’t get into the tcp toolpath option but I might have to as nothing else I have tried has performed a fluent rotation. Using the force in Rz gives me the fluent rotation but I programmed a series of linear moves to follow the contour but while it is in the force move, it seems to just ignore all the waypoints and tries to just maintain its Rz rotation. Is there a way to combine force nodes? for example, can I keep a force on the Z base but also the Rz of the tool? I assume not.

7

No, one reference frame has to be selected before entering force mode.
Maybe there are URCaps that provide more advanced force control.

[edit] Looking at the picture I’m not sure why can’t you teach a feature plane parallel with sanding belt, and ask robot to apply force only in Z axis of that feature.
MoveJ should still be able to maintain position control along tool Z axis moving cup back and forth, applying pressure against sanding belt at the same time.

8

I have tried that also. The problem is that it’s not a simple enough motion that I can just use 2 waypoints. I need to program a handful of them and when I do, there is a slight pause where the acceleration is ramping down and up to the next waypoint as the blends are really small. I end up with a pause in rotation for a fraction of a second which would mean a potential flat spot on the cup. This would all be very easy to do without spinning the cup at the same time but unfortunately that was something they specifically requested.

9

Have you tried movep which is designed to maintain a constant TCP speed?

10

movep and movel don’t respect the absolute rotation value. they just go to the closest 360 position. I think we’ve come to the conclusion that it’s not possible to do without writing our own urcap so we may just stick to force co-pilot solution.

11

is it maybe posible to use this the path_offset_enable() function? link

use in the headprogram a force move in the sander belt direction.

then in the thread you use the path_offset_enable() function with the screwdriver funtion or a 1 degree turn in the RZ direction.

just a quick tought, but dont think it will work either tho.

12

It’s quite a difficult task to do with normal programming. MoveP will respect rotations, but it has to be done in small increments - like 90deg at a time. Robot will try to maintain constant TCP linear speed, so TCP has to be offset from center of the rotation - maybe on the surface of the cup.

Suggesting a major change at this point of the project is likely unacceptable, but remote TCP was designed with these kind of applications in mind. Downside is that path needs to be created in CAM software, and then imported. I’m also not fully aware if remote TCP is fully compatible with force mode.

13

Yes, I tried that also. It does work but the max rotation speed is pretty slow. it would probably take like 8-10s to do 1 full rotation.

14

How do you mean slow? if i set a verry large sinus in the path_offset_enable() thread, my forward (x direction) speed will remain the same (input) speed, but the side speed (y direction) is based on how large my sinus is. so in your case, i would think how much the rotation step is (0.5, 1, 2, 3 degree) that, that would be your speed.

offset = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
i = 0

Move to wp_1 (begin cup)
"turning" =treu
Move to wp_2 (end og cup) with right force direction 

this inside the thread:
  
if "turning" is treu
  path_offset_enable()
  Loop til wp_2 is reached 
     offset[5] = 0.02
     path_offset_set(offset, 2)
     i = i + 1
     sync()
  end (Loop)
  path_offset_disable()
  offset = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
  i = 0
else
sync()
15

I will give this another try but in order for me to succeed with path_offset_set, I need to limit the acceleration or else it will throw an error due to acceleration too high. I need to use path_offset_alpha filter with it and the max I have been able to achieve is the speed I mentioned above.

Thank you for the suggestion. I will play around some more with it.

1 Like