question about directional backlash compensation

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

I ran the Issues and solutions for my x-non-square axis successfully. I specified tolerance +-0.030 and got the result "DirectionalCompensation" with with a backlash offset 0.065.

Here is the issue I see. When I ask for a 0.01 jog in the Jogging window (say, to the left), the machine moves by 0.065 (or so, hard to tell). If I apply a second jog in the same  direction (left), it moves the correct amount of 0.01.  If I reverse direction and ask for a 0.01 jog to the right, the machine moves by 0.065 (again hard to tell, but a large jump.) Then the second jog in the same direction (right) gives a proper jog.  Is this expected behavior? I guess what I was expecting was that for a jog of less than the backlash offset, the machine would jump in the opposite direction by more than the backlash offset, then add the appropriate amount to return the the (jog to) spot.

Best, Jim

[mark maker]

Hi Jim,

That's the expected behavior. DirectionalCompensation is the "gold standard" of the compensation, i.e. your machine seems to exhibit a very consistent behavior over different speeds and distances, which suggests the mechanics are nicely stiff.

Whenever it reverses direction, it needs to take up the slack or play.

(From the Wikipedia page about Backlash in Engineering).

https://github.com/openpnp/openpnp/wiki/Backlash-Compensation

If you look in the camera, i.e. by how much the machine physically moves, does it not appear as expected?

_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/c45335c6-79ca-4bb8-a0d0-f296f171af7bn%40googlegroups.com.

[Jim Freeman]

Thanks, Mark. I tried to make a video to show what I am seeing. In the video there is a vertical scratch that I step around in X. I step in one direction (hit the 0.010mm step) and you see a "big" increment, 0.065mm (or so). Then stepping in the same direction gives the desired increment of 0.010 mm. Toward the end of the video I step back and forth by the 0.010mm step and you can see the jumps of 0.065. What this effectively means is that for my system there is no way to just do a simple 0.010 step.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bfe4c626-4d80-29f1-5f09-469477ab71ef%40makr.zone.

[bert shivaan]

It sounds like you do not actually have .065 of backlash.

If I were testing this, I would turn off backlash comp. Then while watching the camera view, jog with the smallest increments in one direction. when you see the "view" change, write down or take note of the position. Now jog in the opposite direction. As soon as you see movement, STOP. Now look at the position again. This amount should be your backlash.

Now test it in the opposite direction to see if it is the same both ways.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyDHg%2Bq-FZ_FEg9OyWcZtURsz65hgpiWw5Dax-p30C1sxQ%40mail.gmail.com.

[Jim Freeman]

Here is a better example video. I put in the reticle hash marks.

Best, Jim

On Sat, May 14, 2022 at 12:59 AM mark maker <ma...@makr.zone> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bfe4c626-4d80-29f1-5f09-469477ab71ef%40makr.zone.

[mark maker]

I can only assume that the backlash calibration vision had a problem. Because in essence it does exactly what you do, to determine the backlash.

Checklist:

1. Explain why the camera videos appear so bad and noisy.
   
2. Is you lighting strong enough?
3. Check and report Preview FPS (a lower than nominal FPS it will indicate that lighting is not strong enough, see here)
   
4. Check camera settling time and method. If lighting is very bad, you need a very long settle time, because the camera exposure raises, FPS decreases, frame lag increases). Incomplete camera settling can very well explain a faulty backlash calibration result.
   
5. Check if the fiducial diameter was correct.
6. Show the backlash calibration result diagnostics (on the machine axis)
   

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyDM_73exAwe04VOTzFADQsYEmQdbmvBXuXTsTXbKcsCxA%40mail.gmail.com.

[Jim Freeman]

Thanks Mark and Bert for the attention and comments!

1) I don't know why the camera is so grainy. It has 1.2K pixels in X and about 20mm field of view in X so that is about 16 microns/pixel.

2)The lighting seems strong enough but I don't have the "test" option you showed in your Wiki link, as I have the device set as an OpenCV camera. (I wish I could change it but I recall that requires major editing to the machine.xml file.)

3) The camera settling time is 2000 ms, (I am not in a hurry to place a lot of components)

4) In answer to Bert's comment to directly measure the backlash, I turned backlash off to measure. As far as I can tell, there is no machine backlash, as a 10micron step to one side moves the machine, the step to the other side also moves the machine. (No apparent backlash.)

Here is the diagnostics on the x non-square

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b11cdee2-9d94-51ec-2a84-9e0cbc544ae0%40makr.zone.

[bert shivaan]

So then of course Mark will come to know why the auto backlash failed I am sure. But in the meantime if you have none, use none

:)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyBQ%3DqyRfR4GL-Sxd3MteM2V09AX2-jureVX8RkAkf2YtA%40mail.gmail.com.

[mark maker]

Hi Jim,

It seems that vision is to blame.

You see the red line "Absolute Error" raising all the time?

This is indicating that Units per Pixels are not right. Unfortunately, it seems just to be within the tolerance of 0.03mm, so the calibration does not catch this. If you take that ~0.3mm error two-sided, it could be that it results in the "imagined" 0.065mm backlash you're seeing.

I'm not sure. It could also be a combination of reduced camera quality/resolution and this.

Check these points:

1. Disable Advanced Camera Calibration for now (go to the tab, unselect the checkbox).
   
2. Primary fiducial / Preliminary camera calibration done using a proper calibration rig and proper flat fiducials, as described here:
   https://github.com/openpnp/openpnp/wiki/Vision-Solutions#calibration-primary-fiducial
   
3. Most certainly not using pin holes or other stuff that has 3D depth! (I'm just emphasizing this as your videos do not show a proper fiducial)
   
4. Used the same calibration rig/primary fiducial for backlash calibration.
   
5. Truly at the same unchanged Z height! (very important)
   
6. Not having moved the camera up/down in Z in the meantime
7. Not having changed the camera video mode in the meantime.

If any of these are not a "Yes", please redo the Preliminary camera calibration using Issues & Solutions. Enable the "Include Solved?" checkbox to revisit the required solutions:

https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions

Reopen and then revisit everything in uninterrupted sequence, mostly as shown in this video:

https://youtu.be/md68n_J7uto

Other comments:

> The lighting seems strong enough but I don't have the "test" option you showed in your Wiki link, as I have the device set as an OpenCV camera. (I wish I could change it but I recall that requires major editing to the machine.xml file.)

I strongly recommend going to the new OpenPnpCaptureCamera:

1. Create a new OpenPnpCaptureCamera
   
2. Assign all the axes, as on the old camera.
3. Assign the light actuator, as on the old camera.
4. Assign any other "keepers" you find by comparing wizards.
5. Delete the old camera.
   
6. Best restart OpenPnP now.
   
7. Choose the device and video mode in the new camera.
8. Take the opportunity to prepare the device settings as described here:
   https://github.com/openpnp/openpnp/wiki/Camera-White-Balance#prepare-the-device-settings
   You might as well do the White Balance all the way:
   https://github.com/openpnp/openpnp/wiki/Camera-White-Balance
   
9. Perform the Primary fiducial / Preliminary camera calibration (see above).
   
10. Later: Perform the new Advance Camera Calibration to compensate for lens distortion.
    

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNznnEt8pC4Me25Rkktmw1hxpi2BZ0j4k%2BjsLRNGHidPAw%40mail.gmail.com.

[Jim Freeman]

Thanks, Mark. I will attempt to do this today and let you know. By the way what field of view to you find best? I picked 20mm for no really good reason. That does limit the number of pixels per mm. Is there a better choice?

Best, Jim

 

Sent from Mail for Windows

 

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/45fea9f4-e1de-0cd7-59bd-e266c91cf794%40makr.zone.

 

[Jim Freeman]

I turned off advanced calibration, then redid the top camera first and second fiducial calibrations, and immediately did the x-non-square backlash compensation. I basically got the same as yesterday, with the red curve drifting up. I redid advanced top camera calibration, then redid x-non-square backlash and got the following report: The calculated backlash is still about 0.068. This causes jumps when I do small (0.01) steps,, and the best backlash for this axis is 0, no backlash. 

I also note that my top camera has substantial barrel distortion even after the advanced calibration. The black boundaries on the side of this image are in fact straight.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/45fea9f4-e1de-0cd7-59bd-e266c91cf794%40makr.zone.

[mark maker]

The absolute error is now quite OK.

But look at the faint blue line in the second graph. That is the reversing backlash. You see how it is practically zero at the smallest reverse move distances. That is exactly what you observe with manual 0.01mm moves. It must be some kind of "reluctant backlash" that only unfolds over larger distances. Like a belt that is stiff, so it will not exhibit backlash on small move reversals, but that is not completely taut, so it will exhibit backlash over larger distances, once it has become taut again, i.e. only reluctantly stretching against its stiffness... that's just one possible explanation.

Please try the following: Instead of moving 0.01mm in one direction, then in the other, move 10mm, then in the other direction. Now you should see the predicted backlash.

I don't understand why Issues & Solutions proposes DirectionalCompensation. It should probably propose a hefty OneSided of about 0.75mm. Maybe there is a bug in the heuristics. Please send a log of the backlash calibration at TRACE level.

OneSided is the worst fallback. Maybe you can do something about it, mechanically. It could be a belt that was overstretched and now reacts  partly elastically. Belts need to be surprisingly lose. When plucked on the free side, they should sound very low-note and low-key, nothing like a guitar. But once they have been overstretched, they may be damaged 🙁.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyARbSQwz29NbdJ4Q3GNHujEnH4MVyD7EcT7koP_MbSVyQ%40mail.gmail.com.

[tonyl...@gmail.com]

Please post your machine.xml file from after the last time you redid the advanced calibration.

Tony

[Jim Freeman]

Thanks for the insight! I will investigate.

 

Sent from Mail for Windows

 

From: mark maker
Sent: Tuesday, May 17, 2022 1:32 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] question about directional backlash compensation

 

The absolute error is now quite OK.

But look at the faint blue line in the second graph. That is the reversing backlash. You see how it is practically zero at the smallest reverse move distances. That is exactly what you observe with manual 0.01mm moves. It must be some kind of "reluctant backlash" that only unfolds over larger distances. Like a belt that is stiff, so it will not exhibit backlash on small move reversals, but that is not completely taut, so it will exhibit backlash over larger distances, once it has become taut again, i.e. only reluctantly stretching against its stiffness.. that's just one possible explanation.

Please try the following: Instead of moving 0.01mm in one direction, then in the other, move 10mm, then in the other direction. Now you should see the predicted backlash.

I don't understand why Issues & Solutions proposes DirectionalCompensation. It should probably propose a hefty OneSided of about 0.75mm. Maybe there is a bug in the heuristics. Please send a log of the backlash calibration at TRACE level.

OneSided is the worst fallback. Maybe you can do something about it, mechanically. It could be a belt that was overstretched and now reacts  partly elastically. Belts need to be surprisingly lose. When plucked on the free side, they should sound very low-note and low-key, nothing like a guitar. But once they have been overstretched, they may be damaged 🙁.

_Mark

 

On 17.05.22 19:21, Jim Freeman wrote:

I turned off advanced calibration, then redid the top camera first and second fiducial calibrations, and immediately did the x-non-square backlash compensation. I basically got the same as yesterday, with the red curve drifting up. I redid advanced top camera calibration, then redid x-non-square backlash and got the following report: The calculated backlash is still about 0.068. This causes jumps when I do small (0.01) steps,, and the best backlash for this axis is 0, no backlash. 

 

 

 

I also note that my top camera has substantial barrel distortion even after the advanced calibration. The black boundaries on the side of this image are in fact straight.

 

 

 

 

 

 

 

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ee1143fb-3239-bbf3-5dba-9539a05453fd%40makr.zone.

 

[Jim Freeman]

Mark, here is the log file of me doing the x-non-square backlash.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ee1143fb-3239-bbf3-5dba-9539a05453fd%40makr.zone.

[Jim Freeman]

Tony, here is the machine.xml file.

Best, Jim

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/62B-K-IPm-A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/30aadf1f-44f2-4d52-aae3-72e61a085637n%40googlegroups.com.

[tonyl...@gmail.com]

Jim,

Looks like I screwed-up PR#1402 - I accidentally disabled all distortion correction instead of just tangential distortion correction.  Quick workaround - in your machine.xml swap the settings for disable-distortion-correction and disable-tangential-distortion-correction.  They should be set like this:

disable-distortion-correction="false"

disable-tangential-distortion-correction="true"

No need to collect more calibration data after this change.  Just restart OpenPnP, go the Advanced calibration tab for each camera, select "Skip New Collection and Reprocess Prior Collection" and click on the "Start Calibration" button.

New PR coming shortly to fix it.  Mark, this fix really should go in before merging test into develop.

Tony

[tonyl...@gmail.com]

PR#1416 submitted.

[mark maker]

@Tony, roger that.

Will you also include an @Commit handler (or similar) that fixes configs that went through the faulty version?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1ce8daec-ee3f-44ab-b6d7-edca30b5a98bn%40googlegroups.com.

[mark maker]

disregard, I saw the PR.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8ad74516-6f91-576c-8d9f-2a8407bb7112%40makr.zone.

[mark maker]

This is now in the testing version, thanks, @Tony.

https://openpnp.org/test-downloads/

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0bfaaf06-85ce-c871-3837-af9c2c2dc734%40makr.zone.

[Jim Freeman]

Hi, Tony. I did as you said and modified the machine.xml. I redid the calibration, I still have significant barrel distortion. I am including the machine.xml file. I have a question, after lens calibration is there a quantifiable way to know how well the calibration worked. If it doesn't work, then what? The same question for the up-looking camera. Also do you assume  symmetry of the lens distortion? 

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1ce8daec-ee3f-44ab-b6d7-edca30b5a98bn%40googlegroups.com.

[mark maker]

Hi Jim,

could you please redo the screenshot with the following:

1. Set the Grid reticle.
2. Center the cross-hairs to be aligned with a major line of the millimeter paper.
   

I've had the same effect at the edge in simulation. See the link for a possible explanation and fix, but @Tony and I need to discuss this further:

https://github.com/openpnp/openpnp/pull/1420

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyA23Uo-6-WfCNgTeadCwpiwy5Lmo6b6fO7cPsqe9%2Bjtbg%40mail.gmail.com.

[Jim Freeman]

Hi, Mark. Here it is. It looks to me that the correction is pretty good in the middle of the image but falls off a lot toward the edge.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/afd4bde9-16b1-3fd9-dfbd-9746c4e729d3%40makr.zone.

[mark maker]

Thanks.

Could you please post the same image but with first moving the slider all the way to Show All Valid Pixels on the Advanced Calibration tab? (screenshot)

And setting the grid to just Millimeters? (screenshot)

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyBgA-%3DFowOcTWN16SFXqV-81kOzk4E1ojM50pAe6Pju3w%40mail.gmail.com.

[Jim Freeman]

Here it is (I know I have a substantial Z rotation error, need to adjust that.  By the way, Tony suggested I update to the newest test version, I will do that and report back.

Best, Jim

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c0e457c2-acad-1702-d539-4365e70985b0%40makr.zone.

[Marc L]

Hi, I want to pitch in to say that I have the *same* problems since I upgraded to test build 2022.05.20.08.33.39.

I had trouble placing parts on my PCB, and went through the top camera<-> nozzle advanced calibration, top camera advanced calibration, and bottom camera advanced calibration, before going back to backlash and observing the same errors. Same backlash calibration errors and graph patterns as James Edward.

I have a LitePlacer. On both axes I use the DirectionalSneakUp mode. On Y axis, the automatic backlash calibration works well, but on the X axis, now I have to manually set the compensation value to 0.15 mm, from the automatically detected 0.086 mm. The calibration is performed with advanced down-looking camera calibration active. I tested using my PCB fiducials and moved 1 mm, 10 mm and 100 mm in both directions to validate that the new 0.15 mm compensation is better than the previous 0.086. I have also confirmed by moving from each fiducial of my PCB (in each corner) to a 0402 component in the middle of my board (51 x 61 mm). The new manual backlash values are much better.

I'm willing to perform some tests if useful. I have joined a few log files from earlier today

[mark maker]

Hi Marc,

I'm not saying there isn't something off. 😇 But just from your description, it is not obvious.

The default tolerance is ±0.025mm, which is often rounded to ±0.03mm (rounded up according to axis resolution/steps per mm, or if not configured, to the next 0.01mm).

This is ± "plus-minus", i.e. for a full direction reversal we allow up to 0.06mm difference.

It should be noted, that this is IMHO still sufficient precision for 0402 / 0.4mm pitch parts or even smaller.

The difference between your 0.086mm and the 0.15mm is about the same 0.06mm. So just looking at these numbers, it is all OK. 😁

The calibration heuristic will fully exploit the allowed tolerance, i.e. it will propose the least intrusive compensation method that still complies with the tolerance. Usually this is governed by the inconsistency between the smallest/slowest versus the largest/fastest moves and direction reversal.

Long story short: you can reduce the allowed tolerance to make it more conservative, if you like.

For instance, if you set ±0.01mm, what happens?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/927d03a7-1be9-4b69-9f79-099863d6fdc8n%40googlegroups.com.

[Marc L]

Hi Mark, sorry I could not describe the issue clearly. Just wanted to support the idea that this is not a one-person issue. I don't know much about PnPs,  except how to assemble and operate one :) (and then, barely, haha!)

I tried the backlash calibration with a tolerance of 0.01 mm instead of 0.03mm, and the calibration went from 0.086 to 0.108, so that helped me understand a bit. Could I set it to ~0.117 mm and get "perfect" results? Does it even work like that :P ?

When placing a part, I suppose backlash, up-looking camera position, PCB fiducial location and nozzle<->down-looking camera offset errors all add-up. Add to that the summer heat and humidity deforming everything. With 0.4 mm DFNs, your placement tolerance is about 0.1 mm (half a pad's width), so the difference between least intrusive and optimal compensation can make or break the process.

Anyway, I'm glad to understand a bit more and to have a fallback solution. Thanks!

[mark maker]

Hi Marc,

> I tried the backlash calibration with a tolerance of 0.01 mm instead of 0.03mm, and the calibration went from 0.086 to 0.108

That sounds as it should be.

> Could I set it to ~0.117 mm and get "perfect" results? Does it even work like that :P ?

If you want even more precision, just enter a tolerance of 0.005mm and redo the calibration.

But I will start to doubt, your machine can really deliver it, i.e. be that consistent between fast/slow and long/short and reversing/not reversing moves. It would be illustrative, if you made a screenshot of your Backlash Compensation tab on the Axis (the graphs).

> When placing a part, I suppose backlash, up-looking camera position, PCB fiducial location and nozzle<->down-looking camera offset errors all add-up.

Errors rarely just add up, in PnP, surprisingly often they cancel each other out. That's often the beauty of using vision (it is inherently "self-calibrating"). I might add, that both fiducial, and nozzle tip detection was improved recently. It is now delivering extremely robust sub-pixel precision. We can get extremely precise (far below one pixel) positional information from even low quality/low resolution camera images.

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

I do agree that striving for optimal backlash compensation is certainly a valid goal. 😁 However, the calibration heuristic switches between different method. If the tolerance cannot be achieved with one method it will use a more conservative method. The machine will become slower, as a cost for extra precision. It is explained here:

https://github.com/openpnp/openpnp/wiki/Calibration-Solutions#backlash-compensation-method-selection

> Add to that the summer heat and humidity deforming everything.

Most of this is either irrelevant for PnP needs (effects too small, it has been discussed many times in this group), or can easily be compensated by OpenPnP, simply by re-homing the machine from time to time, e.g. after the temperature/humidity has changed a lot.

Many facilities in OpenPnP can be configured so they will re-calibrate using computer vision after the machine was homed, either immediately or on first use.

• Visual Homing
• Nozzle tip changer (if vision is enabled)
• Nozzle tip calibration...
• ... which also implicitly precision-calibrates the bottom camera position
  
• PCB fiducials
• some of the Feeders, especially BlindsFeeder and ReferencePushPullFeeder (the latter, despite its name, can be used for almost anything: drag feeders, any type of mechanical feeders, electronic feeders).
  

Pick and place machines (unlike CNC mills for instance) do not need continuous and absolute geometric precision over the whole machine table. That is only needed within the small area of the PCB, which is first pinned down using fiducials and an Affine Transformation, i.e. including any positional, rotational, scaling and even shear errors. OpenPnP fully compensates all that, and during the short time of populating one PCB, there is hardly significant thermal expansions happening, right?

Other than that, a PnP only needs to re-find its assets. Because we first calibrate these assets using vision (with huge allowable tolerances of typically ±2mm), this is a no-brainer. When you re-home the machine from time to time, the same thermal expansion etc. will be present both when using vision to calibrate, and when actually doing the stuff we want. Any error cancels itself out.

> With 0.4 mm DFNs, your placement tolerance is about 0.1 mm (half a pad's width), so the difference between least intrusive and optimal compensation can make or break the process.

Yes, exactly. But 0.1mm is not 0.01mm, and still almost double the 0.06mm we were discussing initially 😎, i.e. there's still 0.04mm in the "budget" for other errors.

> Anyway, I'm glad to understand a bit more...

If you want to know more, look here:

https://github.com/openpnp/openpnp/wiki/Calibration-Solutions#calibrating-backlash-compensation

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a33c766c-2a64-42c5-8644-cf3cf2985efan%40googlegroups.com.