uArm Z Axis Encoder error

[geoffpeters]

The Z Axis encoder in my uArm Swift Pro is not giving consistent readings. I am sending G2205 relative commands like (G2205 S0 R0 H%s F20,h_str).

h_str is +2 mm if the arm is moved up and -2 mm if the arm is moved down. The minimum and maximum limits are set and I compare the current value with a variable incremented or decremented depending on whether the arm in moved up or down.

If I move the arm up and down multiple times the actual height changes as much as 30-40 mm. The height is not repeatable.

I would appreciate any assistance.

[asantanna-applied]

We are also trying to track down problems with repeatability “drift”.

We still don’t what exactly is going on, but if one day we set up a precise
path for the robot, things are very repeatable that day. We come back
the next day and everything can be off by as much as about 2mm.

It’s very frustrating and we’re trying to figure out what the problem is.

We are working on 2 theories - currently with no data to support them but they’re the only
things we have thought of so far:

1. Maybe errors accumulate in the software somehow? Perhaps we are creating
   paths when there are lots of accumulated errors and the next day we start up the
   robot fresh and the errors go away?

2. Are there thermal problems? Do things go wiggy when the robot gets hotter?

   • I don’t know what the robot internal structure is made of but assuming aluminum, an arm length of about 120 cm, and a temperature variation of 20C, we would get worst case errors due to heat expansion of about 0.5 mm. Not enough to account for what we are seeing. NOTE: These are guessed numbers and back of napkin calculations.

   • Something else is temperature dependent? Don’t know.

We will be looking into this some more. If I figure anything out, I’ll post it here.

Andre

[jjs6w]

Yes, repeatability is within 1-3 mm for me as well. It also varies between uArm (I have 8) and some machines are just more accurate than others.

Interestingly however, the u.reset() can be run over and over until the position error is less than 0.5 mm. Looking at the code, it just runs u.set_servo_attach() before before moving the reset position. Thus, the reset position is nothing special and can be anything.

I’m just experiment with replacing the reset position to see if it improves position on the specific locations where I need it more accurate than within 1-3 mm. Don’t know yet as I am in the middle of a moving work locations.

[jjs6w]

Of course another solution is just using cameras with some zoom and adjust based on the images but it is considerability more complex (but doable).

Any of the LIDAR and topology mapping techniques don’t have sufficient accuracy less than 1-2 mm which is around what you are getting now.

[geoffpeters]

The errors I’m seeing are much greater that what you both are experiencing.

The problem seems to be worse in the z-axis, or height . I’m using relative polar coordinates. For example if I set the initial height to 60, set a high limit of 120 and a low limit of -20 (-20 just touches the table top), I can move the arm up and down on the first try as expected.

Now if I move the arm back to the maximum height and back down to the table top one of two things happen. Either the arm will attempt to travel past the table top and force the base up or the arm will stop its downward movement above the table by 5, 10, or more.

Each time I repeat the up and down motion the height is different.

[jjs6w]

Yes accuracy also depends on the position. If you attempt to move to fringes of what it can move to, the position is very unreliable.

[asantanna-applied]

Hi Geoff,

I have just placed a query in this forum for UFactory to clarify some information in their manual.
Check out that post, it may have something to do with what we are all experiencing.

Basically, it seems that it is known by UFactory that when XYZ type commands are used sequentially
(versus specifying joint angles explicitly), errors will accumulate and repeatability can go out the window.
Page 60 of their 1.2.2 user manual says something about this but it is hard to understand the translation.

Hopefully they will reply and clarify these issues for us?

Note that they already mentioned in other posts that accuracy (ie the XYZ coords you actually end up
at) is not very good. I think they said about +/- 2 mm is all you can count on. They say that other similar
robots aren’t that accurate either.

On the other hand, they do claim a +/- 0.1 mm repeatability (ie when the robot moves to a spot, it might
not be the right place but it will consistently go to the same place). We, however, are seeing repeatability
errors of 2 mm and are trying to figure out what’s going on.

Have a good one,

Andre

[geoffpeters]

Thanks Andre,

Where do I find the 1.2.2 manual? It is not where I expect to find it.

Geoff

[jjs6w]

I think they have argued that accuracy is different than repeatibility.

That is, it can be accurate to +/- 2 mm to what you set the position to. Repeatibility would be to get the same delta on subsequent tries. This I would believe.

[asantanna-applied]

Hi Geoff,

It’s a bit hard to find …

https://www.ufactory.cc/#/en/support/download/xarm

[asantanna-applied]

Hi jjs6w,

I don’t understand what you mean by “delta” in this case, but I think we agree?

Accuracy is +/- 2 mm and “repeatability” means “can be repeated” and end up with +/- 0.1 mm?

[geoffpeters]

OK, but I’m using a uArm Swift Pro…

[asantanna-applied]

Geoff,

Sorry about that! I don’t know how I got into this forum from the xArm one!

Anyway, maybe the two robots have common code and this sort of thing might apply to both?

Sorry about that.

Andre

[jjs6w]

Yes, I was a bit vague.

Say, you set position (0,0,0). It goes to (0,0,2), so the error is 2. Now, you move the arm somewhere else. Now, you move the arm back to (0,0,0). If it returns to (0,0,1.9) or (0,0,2.1), then it satisfies repeatibility, but not accuracy.

[TopgunZh]

Hi,geoffpeters.G2205 is relative displacement.You should record the current position.If you move the arm up and down multiple times,so you didn’t konw the current height,you can’t point out that the height is not repeatable.
If you sure the position is same,but the arm the physical location is not repeatable.You can upgrade uArm firmware to V4.0,and use M2123 cmd to open closed-loop stepper
system that will adjust current position.

[geoffpeters]

Thanks, can you explain what M2123 cmd to open closed-loop stepper does?

[jjs6w]

TopgunZh,

What the advantage of moving relatively as oppose to absolutely?

[geoffpeters]

I’m using joysticks for stretch, rotate, and height. For example one axis of one joystick is to control the height and move the arm up and down. When I close a switch on a joysticks I need to move the arm while the switch is closed and stop when the switch opens.

I set stretch and rotate both to zero and send a a small incremental value to the H parameter. Say 2 for up and -2 for down.

I don’t see how I can do that with absolute commands.

[jjs6w]

I don’t know if this applicable for you, but I think you need to be careful how you format floats. I don’t know about Arduino, but standard python handles float very poorly sometimes floats are formatted such that 9.0 is 9.000000004 (usually occurs when adding integers like your 1 and 2 with floats that are positions). If you unknowingly feed the latter into your g code, the uArm can misbehave. I have been changing my code so that it always rounds to at most 3 decimals in the float. I don’t why Python does this but it seems to be a known issue.