Interpreting Backlash graphs

[David Griffiths]

I have been trying to tune my backlash using the new auto tune in Mark's test version (2021-10-12). The results have not been wonderful.

If I am interpreting these graphs correctly, I think the rising red line in the top graph is telling me that I have a gradually increasing error.

My immediate thought was losing steps. I have tried increasing motor current, drastically slowing acceleration, jerk etc but nothing I have tried seems to change the curve.

X & Y axes are similar.

Comments please.

DG

[ma...@makr.zone]

Hi David,

Thanks for testing. Something is really not working there.

I wonder if the problem could be with the vision. Could you re-do the calibration, while you zoom in on the screen, and observe in the first step tests, whether the green cross-hairs move step by step and precisely hug the fiducial? In my video it is shown here:

https://youtu.be/md68n_J7uto?t=346

Note, it has slightly changed since then, the green cross-hairs should now even have sub-pixel precision, i.e. the precise match with fiducial should even be more apparent.

Ideally, you could record it too and post the video?

If the cross-hairs do hug the fiducial, but they don't evenly move between steps, then I would look at micro-step settings. Perhaps you have switched them off?

What stepper drivers do you have?

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f5af476b-7175-4c84-88e6-821dea2e4332n%40googlegroups.com.

[james.edwa...@gmail.com]

Hi, Mark. If convenient, could you post your optical pipelines you used in this video? (Or similar)?  Thanks, JIm

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of ma...@makr.zone
Sent: Wednesday, October 20, 2021 7:35 AM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] Interpreting Backlash graphs

 

Hi David,

Thanks for testing. Something is really not working there.

I wonder if the problem could be with the vision. Could you re-do the calibration, while you zoom in on the screen, and observe in the first step tests, whether the green cross-hairs move step by step and precisely hug the fiducial? In my video it is shown here:

https://youtu.be/md68n_J7uto?t=346

Note, it has slightly changed since then, the green cross-hairs should now even have sub-pixel precision, i.e. the precise match with fiducial should even be more apparent.

Ideally, you could record it too and post the video?

If the cross-hairs do hug the fiducial, but they don't evenly move between steps, then I would look at micro-step settings. Perhaps you have switched them off?

What stepper drivers do you have?

_Mark

 

 

Am 20.10.2021 um 12:19 schrieb David Griffiths:

I have been trying to tune my backlash using the new auto tune in Mark's test version (2021-10-12). The results have not been wonderful.

 

If I am interpreting these graphs correctly, I think the rising red line in the top graph is telling me that I have a gradually increasing error.

My immediate thought was losing steps. I have tried increasing motor current, drastically slowing acceleration, jerk etc but nothing I have tried seems to change the curve.

X & Y axes are similar.

Comments please.

DG

 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f5af476b-7175-4c84-88e6-821dea2e4332n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8a3db808-eb41-c2aa-7822-48570a68d916%40makr.zone.

[David Griffiths]

Yes the green circle is hugging the fiducial very nicely. Looks good. I also thought it could be video related so I tuned the camera settling times and white balance. Sadly it didn't help.

I also have an unrelated? problem where my ELP HD cameras keep turning the auto exposure and white balance on without me going anywhere near the Device Settings screen ?? It has happened three times tonight. Starting to be really annoying!

I am using a standard Smoothieboard and microstepping is on AFAIK. I am not sure if you can disable it on Smoothie in the config.txt file ?

Video is here:

https://www.dropbox.com/s/dq33dive7eemius/2021-10-21%2000.06.55.mp4?dl=0

DG

[David Griffiths]

My machine.xml is here if that helps:

https://www.dropbox.com/s/t4cbs1cdx79vvmo/machine.xml?dl=0

DG

[ma...@makr.zone]

There is no pipeline in the calibration vision (this early in the machine setup process this would be too much for the user). It is all built-in using the DetectCircularSymmetry  method. I developed this method to be tuning-free and extremely robust. Only the real-world diameter of the circular feature is needed.

You can use the DetectCircularSymmetry stage in pipelines too, it is well documented 😎:

https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/00cc01d7c5b1%2438d75b80%24aa861280%24%40gmail.com.

[ma...@makr.zone]

It is definitely not a vision problem, i.e. the problem is either with the machine or with my calibration code.

The video is just a bit too short to judge, it stops right where it begins to be interesting. I do see some "sticking" in these first 4 steps. Each step should move the cross-hairs about the same amount.

I don't think you can switch off micro-stepping on Smoothie, not entirely sure.

If the stickiness is really there, and if you already increased currents, I don't know where the problem could be, other than just too much mechanical stickiness, belts too tense etc.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/60b63cf7-3e4a-42b1-97cf-27423c7bb624n%40googlegroups.com.

[David Griffiths]

Hi Mark,

My money is definitely on it being the machine - it is a new design by a novice designer :-)

Here is a longer video:

https://www.dropbox.com/s/vn6soncz8u8ojxz/2021-10-21%2009.25.10.mp4?dl=0

This time it is on the X Axis with current increased to 'hot motor' (too hot for my liking). The result of this calibration is the same with the red line rising steadily to about 0.4

I was already starting to suspect that I have a creeping error because my placing accuracy seems to get worse over time.

I take it by 'sticking' you are referring to mechanical inertia?

I didn't realise belts too tense was an issue - I thought having tight belts was desirable, particularly in relation to backlash.

Any thoughts on the cameras turning on auto exposure without command?

[ma...@makr.zone]

Hi David,

Please read this carefully, it is complex, and took a lot of time and effort to write down (hopefully) understandably.😉

Aaaarghhh.. the video is still too short to be completely telling. And you should keep both the cross-hairs and the step counter in the view. A screen-recorder would be much better. I'm sure there's freeware around.

You have a 1mm fiducial, and the stepping test spans over 1mm, so the cross-hairs of the camera view should exactly go from one fiducial edge to the other (this time I'm not talking about the green cross-hairs, but about the red-cyan camera cross-hairs) .

Also make sure to enable the Reticle type Ruler, or Grid in the camera view, so we'll see the camera Units per Pixel it in the next video. The grid should exactly frame the fiducial at the start of the step test. See later, as to why this is important. Right-click in the camera view:

The stepping is not completely even, but as far the video goes, I don't see an error of 0.3mm accumulating. So something is amiss.

First, make sure to set the Resolution on your axis. It should be your micro-step unit. This will make sure, the calibration steps will not be finer than what your axis actually can do (steps default to 0.01mm if the resolution is left at the default). As a guess, it seems to me like you have Resolution=0.0125mm (like my own machine),  i.e. 80 steps / mm, which is the typical resolution for 16 micro-steps, 1.8° steppers and standard pulleys. This means that every 5th step is doing nothing (and that's fine).

https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings

If you change the Resolution, the step test will do exactly the right number of steps over the 1mm span (steps can be an integral multiple of the Resolution, if it is finer than 0.01mm, or finer than the sub-pixel resolution of the camera).

I'm also having another suspicion: either your camera Units per Pixel are not accurate, or your fiducial is not at the same Z as the calibration rig where you did the Units per Pixel. Or you moved the camera up/down, or changed the video mode.

Please confirm that you did all the calibration step in Issues & Solutions as in my video, on the same unchanged calibration rig and camera configuration:

https://youtu.be/md68n_J7uto

If it in-deed is the Units per Pixel, please repeat the Issues & Solutions calibration steps. Switch the Include Solved checkbox on, and Re-open those, all at once, then do them in the right sequence.

I will try to add a Units per Pixel error detection to the calibration, that throws an error after the step test. This is also needed, because the calibration can be started from the Axis, i.e. outside Issues & Solutions.

If the Units per Pixel are right, I still cannot rule out a bug in my code.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/71ea628b-2ff1-46e7-b0b7-6b1cf440e042n%40googlegroups.com.

[David Griffiths]

Thanks for these details.

You have managed to drag me into the 21st century :-) - I now have a screen capture program installed (OBS Studio - open source).  The full 12 min video is here:

https://www.dropbox.com/s/2rkd9kskae1tffk/2021-10-21%2023-51-39.mp4?dl=0

You were spot on about the Units per Pixel.  The 1mm fiducial was appearing as about 0.6mm on the camera!  Way out.  I have no idea how though because I did the cal in Issues and Solutions. When I redid this cal, everything improved drastically. VBG

I had changed from the calibration rig (black square, white dot 1mm) to an actual fiducial, also 1mm, on the PCB - same Z.

My setup is using 32 microsteps on 1.8° motors with 36 tooth pulleys. I calculate this as 0.01125mm per microstep. I don't understand the Resolution [driver Units] setting on the axis Config page. Mine are defaulted to 0.00010. I am thinking I should increase these to 0.1125 ?

The backlash graphs look vastly better as you can see at the end. Should I be concerned that the red line on the top graph (Y axis) is mainly out of the tolerance range?

Cheers,

DG

[David Griffiths]

I forgot to add, the steps per mm that I have configured in Smoothie are 89.38 for X and 89.2 for Y. These were determined empirically by measuring actual distance travelled.

The theoretical I think they should both be 88.888.  I am not sure if I should change them to theoretical and remeasure?

DG

[ma...@makr.zone]

> I don't understand the Resolution [driver Units] setting on the axis Config page.

You mean the Wiki page is not understandable? Any hints where I could improve it?

https://github.com/openpnp/openpnp/wiki/Machine-Axes#controller-settings

Or do you mean the Wizard in the GUI?

> Mine are defaulted to 0.00010. I am thinking I should increase these to 0.01125 ?

Yes, exactly (with the 0 inserted).

> OBS Studio

I'll have a look at that one. Always wanted to get a good alternative for my commercial one.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8f358295-43f2-48bb-8850-7ece77ce6698n%40googlegroups.com.

[ma...@makr.zone]

More...

> The backlash graphs look vastly better as you can see at the end. Should I be concerned that the red line on the top graph (Y axis) is mainly out of the tolerance range?

There seems to be some problem every 36 steps (0.01mm) which corresponds to 32 microsteps with 0.01125mm.

So this is clearly a microstep issue. Somehow, your Y axis has trouble positioning to some of these microstep interval positions.

In the other post you mention having empirically set steps/mm to 89.38 for X and 89.2 for Y. This does not point to having the belts overstretched (as I suspected), on the contrary (steps/mm would be less, not more). So I don't understand. AFAIK, these belts are usually manufactured with enough precision for PnP purposes, i.e. you should be able to configure the nominal steps per mm (88.8888), and get reasonably accurate results.

Over-tightening the belts could have explained why the steppers struggle. An overstretched belt's teeth will no longer match the pulley teeth and it takes force to jam the belt teeth in and rip them out, the rubber being sticky and all.

When I built my Liteplacer there was no indication as to how tight the belts must be. I searched long and hard to find guidance and found a very good page, but stupid me has not recorded the link (and I can't refind it). When I followed that advice, it resulted in belts being so surprisingly lose, I almost couldn't believe it's right. On a typical PnP machine size (500 .. 750mm), the free side of the belt should sound very low when plucked, like the lowest key on a piano or even lower. It should be very easy to pull it out sideways one/two centimeters. This seemed to work very well for my machine; I do have some backlash, but repeatability/precision is good, considering how "DIY" the Liteplacer construction is.

If you have (or had at one point) your belts tensed to sound like a guitar, you have might have to replace them, apparently they get damaged that way. But again, the steps/mm being higher than nominal does not point to that (???)

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/95a26b95-4d08-9eb3-2084-ff007e5a3003%40makr.zone.

[tonyl...@gmail.com]

Microstepping is not necessarily very linear - some drivers are better that others.  See here where someone did tests with several different drivers - some where pretty good but one was not. 

[ma...@makr.zone]

Yes, one thing to make it matter less, is to use smaller pulleys. Replace your 36 teeth pulleys with the standard 20 teeth, this will almost halve the microstep length, and therefore also halve the positioning errors, and it will almost double the torque. I'm sure the machine will still be fast enough.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ac6c8ebd-41e1-4b6d-ada7-933d8e88752cn%40googlegroups.com.

[David Griffiths]

That sounds like a good idea. The pulleys are ordered. ;-)

Regarding the comment on the axes resolution, it would help if the units were shown (ie mm) and the pop up help could also state that this is the distance moved by one microstep.

Why does resolution default to 0.0001mm?  Surely this is much smaller than most machines can achieve.

Thanks for the help,

DG

[ma...@makr.zone]

> Why does resolution default to 0.0001mm?

That is, what the standard G-code MOVE_TO_COMMAND traditionally used through its format specifier %.4f (limiting any coordinate to 4 digits after the dot) so I set it as the default. In this case it is more a "representational" resolution, rather than a mechanical resolution, it just prevents nonsensical microscopic moves that end up in the same G-code.

I added the Steps / Unit field as an alternative reciprocal entry field. The driver unit is displayed. And I improved the tool tips, I hope:

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f9aaffa4-2332-4ecd-93e1-f48580e271d4n%40googlegroups.com.

[Harjit Singh]

Gear to step size calculator attached. Precision is more important than speed, so, I'd planned on the smaller motor pulley.

Depending on your machine design, you'll have to change your motor plate and add an idler pulley...

Would love to see pictures of your machine. I'm still designing the head.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4982b4fa-7fd4-07b2-c81c-60f3758e2ed7%40makr.zone.

[David Griffiths]

Hi Mark,

Those changes look great.  I don't understand the last sentence:

'Note, the Resolution is given in driver (not System) units'  Aren't they both in mm?

I remeasured my steps/mm and found the X axis was 0.5% over. So I changed the 89.34 steps/mm back to the calculated figure of 88.8888 and it now moves the correct distance. :-) (Not sure why it had changed but possibly I didn't have the graph paper at the right Z the first time).

The Y axis however is moving the correct distance with 89.2 steps/mm configured. This I don't understand as both axes are using the same 36 tooth pulleys (well almost the same, the bore is smaller on X, which shouldn't matter)

I did the backlash comp again and got interesting results. The major errors are now on the 32nd step instead of 36, but still happening.

Could you also expand on your wiki explanations of the 2nd 3rd and 4th graphs please. More details on what they are showing and what you should be looking for to make improvements or just to understand what the machine is doing. 

Why does the backlash go down dramatically on the bottom graph at higher speed?

There is no 'F' shown on the second graph ??

I notice the tolerance was also changed - I think it was 0.03 before. It also changed from Directional Compensation.  Which is the most desirable form of comp?

cheers, DG

[David Griffiths]

Hi Harjit,

Thanks for the calculator - very useful. 

Here are some pics of my machine.  As you can see, changing my Y pulleys from 36 to 20 teeth will be easy and I think I will get away with it on the X drive as well. If not, another 3D print might be required ;-)

    

[ma...@makr.zone]

Hi David

> I don't understand the last sentence: 'Note, the Resolution is given in driver (not System) units'  Aren't they both in mm?

Not necessarily. The driver could be in Millimeters but the user perhaps prefers Inches system units for display in the GUI. Or maybe you have retrofitted an old machine where the controller is fixed to Inches, but you still want to display everything on the GUI in mm. One user had linear actuators, that only spoke Microns. I think it is easy to see, that in these cases you still want to specify the Resolution and/or Steps/Unit in the native driver units, for them to be precise.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cb2df16a-039c-474e-9a51-847d30d8e231n%40googlegroups.com.

[Mike Menci]

Here are my X and Y axis graphs - Yaskawa servo drives:

Mike

[ma...@makr.zone]

Y looks very good. The only thing i can't explain, is the last graph: You have larger backlash, when your speed is higher. So far I've observed the opposite (and that's what I can explain, i.e. through inertia).

But the end result is good: the brown points in the first graph are all nicely within the tolerance window.

X is strange. I cannot see a consistent pattern. What happens, if you repeat? Do the graphs look similar?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1c62dfda-a96a-4211-97a5-613d320eb2a3n%40googlegroups.com.

[David Griffiths]

hi Mark,

I have loaded your latest version (2021-10-18) and rerun the backlash tests.  Unexpected results.

The X test decided on no backlash compensation. I'm sure whether that is saying the machine is so good no comp is needed ;-) or it is so bad no comp would help! Given how many of the brown dots are out of tol, I'd say the latter.

I think the only change is loading the new version.

On the Y calib, I got an error message at the end that said "There seems to be overshoot even at the slowest speeds. Check that OpenPNP has effective control of Accel and Jerk".

Here is the motion planner diags.  What is the difference between the light and dark traces? I think one is theoretical and the other actual. 

I am using ModeratedConstantAcceleration on SmoothieBoard. 

I tried the Y Backlash Comp again and it worked.

The big error in the top graph has now changed to 32 steps after I made the resolution 0.011211 (89.2 steps/mm). I think this must be a hardware driver issue ??

The last graph looks strange ??

Cheers, DG

[Mike Menci]

Hi Mark -X repeat 3x resoults:

[ma...@makr.zone]

Hi David

thanks for the ongoing testing. In-deed, these are interesting results.

Just to exclude this for sure: check camera settling. This could be one explanation for the results. Just set it to FixedTime and choose a very long settling time, then redo the calibration:

https://github.com/openpnp/openpnp/wiki/Camera-Settling

If camera settling is not the culprit, here's another possible explanation:

There are two opposing forces at play: friction and inertia.

• Friction will lead to positive backlash, i.e. the belt is taut on the pulling side.
  
• Inertia, i.e. the head/gantry weight opposing the deceleration, will lead to negative backlash, i.e. the weight is shooting into the belt, the belt is lose on the pulling side, taut on the other.

I'm afraid, my calibration does currently not expect negative backlash i.e. inertia to win out in the end. At lower speeds, the algorithm expects friction to take over (that's the whole point of testing at various speeds in the last graph). But of course, inertia can still win out, if the machine friction is low even at low speeds. I don't know enough about different types of mechanics to know if that is a good or bad sign.

On your X axis the effect is not dramatic. So choosing None is actually a valid choice. The brown points are sometimes out of the tolerance band, but they are biased to one side, so this is OK, i.e. it will cancel itself out (yes, I should center the brown points around their average in the graph).

You should still follow-up on these spikes, i.e. the micro-step issue.

On the Y axis, the graph is not from the last calibration, if it threw an Error. The last successful calibration is then retained, as are the backlash compensation settings.

> What is the difference between the light and dark traces? I think one is theoretical and the other actual. 

The dark traces are what the planner does in theory (in your case it is accounting for jerk limits). The light traces is what it then makes out of it, i.e. it converts it to the controller's motion control model, which (in case of a Smoothie) cannot limit jerk, therefore the acceleration is instead moderated in ModeratedConstantAcceleration.

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-planner-diagnostics

You could try to use Simulated3rdOrderControl. It will lower the deceleration at the end of a move step-wise and could solve the "inertia always wins" problem:

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8f0387bd-dca9-4123-974a-e36e3d15a8f5n%40googlegroups.com.

[ma...@makr.zone]

There is definitely always this strange peak, at about 0.20 mm

Could this point to some Eigenfrequency/Resonance effect, i.e. the machine/camera shaking quite strongly at certain step sizes?

My tips are very similar as those to David, just before:

1. Make sure to have adequate camera settling. First just set it to FixedTime and set a very long time. If the peak is still there after that, it can be excluded as the reason.
   https://github.com/openpnp/openpnp/wiki/Camera-Settling
2. Try to use  Simulated3rdOrderControl to subdue the shaking.
   https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/93a733cd-e4be-4728-a342-e98394e6b18en%40googlegroups.com.

[David Griffiths]

Hi Mark. Thanks for the comments. I'm learning a little each time. I did recently change the camera from fixed settling time using the tuning wizard. I will try it back on fixed tomorrow. 

I also tried Simualted3rdOrder and it caused OpenPnP to hang 😢. 

Cheers DG 

[ma...@makr.zone]

> I also tried Simualted3rdOrder and it caused OpenPnP to hang 😢.

What? Could you please set your logging level to TRACE, then retry, then send me the log? If it really hangs, the log should still be available as a file.

https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located

Or send me your machine.xml if you want.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/74c954d6-15f7-40b6-a6db-804e3d7a3d3fn%40googlegroups.com.

[David Griffiths]

Hi Mark,

The hang is 100% repeatable.  Files are here:

https://www.dropbox.com/sh/xfx0t6rutngvxpw/AABftC14OJMofBqqpXXh3uT6a?dl=0

I have a triangular pattern configured for motion planner diags. It does the first two sides and then times out. After that I can do some things, like look at the log, but not exit the program. I have to kill its task.

On the Y axis, the graph is not from the last calibration, if it threw an Error. The last successful calibration is then retained, as are the backlash compensation settings.

Yes I realise that. The graph I showed was from the subsequent successful run.

I have put the camera settling on 400mS fixed. It did not seem to make a lot of difference. Can you easily view the graphs in machine.xml or would you prefer I do a screen cap?

It might be nice if you record the date/time on each graph.

DG