ReferenceStripFeeder working?

[ma...@makr.zone]

Hi

(I'm re-posting this first part of the conversation in the right mailing list, was really, really too tired yesterday...).

I'm too tired to follow this one up today, but is everybody sure the Strip Feeder is working?

In the NullDriver test job the strips are deliberately offset. Vision gets the holes alright but nothing is corrected in the pick location.

Unfortunately the Test Unit does not seem to test whether it actually picks at the right place.

Need to go to bed...

_Mark

 

Wrong mailing list, I think, Mark. :)

Easy to test this using the UI in simulator mode, as you'll see the camera go to the corrected position. I know it was working as of a month or two ago as someone submitted a fix that significantly improved the vision and I tested it quite a bit then.

Jason

 

That's exactly what I did. And I'm repeating it now, slept and with plain develop, so none of my new code in it.

Steps to reproduce (for others too):

1. Exit OpenPnP
2. Rename machine.xml
   
3. Restart OpenPnP
4. Enable+Home
5. Got to Feeders Tab
   
6. Move Camera to Upper Strips - 1
   
7. Capture the Reference holes to be off by ~2mm, e.g. at a twisted angle, i.e the first hole off to the left, the last hole off to the right.
   
8. Apply
9. Perform a feed.
10. Observe how vision works very well, but pick location is terribly wrong.
    

https://makr.zone/ReferenceStripFeederBug.gif

_Mark

[Jason von Nieda]

Hi Mark,

It looks like the part pitch it set wrong on that GIF. 8mm instead of 4?

Jason

--
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/f82ba87f-3e39-471b-9b12-23071e1a06b5%40googlegroups.com.

[Tony Luken]

As far as I've been able to determine, the vision correction only corrects for axial (along the tape length) errors but not lateral (across the tape) errors.  So if your starting and ending hole locations have a lateral error (like you show in the gif), the pick location will have that error as well.  I'm currently working on a change to the strip feeder to not only fix that but to also use all the holes it finds on the strip so that it can "ride over" a hole that is not detected.

Tony

[Jason von Nieda]

I don't have time to test this right now, but it sounds like the issues you are both describing are maybe caused by not using auto setup? The vision pick position is calculated from the line formed by the two holes closest to the part using the tape spec and part pitch, so if the two holes are found correctly so should be the part.

Could you both retry with auto setup and correct part pitch and see if it works?

Note: This may not be the use case you are interested in, but it is the one that I think most people use and the one that the vision was designed for.

Thanks,

Jason

--
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/5bebe1e1-cf0e-4ab5-b3f7-b135b674b0d2%40googlegroups.com.

[ma...@makr.zone]

OK. A simpler case, so we're positive it's not something I'm doing wrong.

1. Check my working assumptions: it is the job of the Vision to correct offsets, that may have happened since the feeder was "last seen". Due to a magnet mount shifted, the homing fiducial or end-stop slightly moved, your steps per mm tuned, a fresh belt mounted or whatever can happen on a DIY machine. If the assumption is wrong, we can probably stop right here :-)
   
2. Otherwise, start fresh with the OpenPnP test case
   
3. Manually change each hole X coordinate by -1mm. So the distance of the holes remains constant, the feeder is just shifted in X, as it might happen, after you had an X end-stop crash or whatever.
   
4. Apply.
5. Then use Feed, repeatedly.
   

https://makr.zone/ReferenceStripFeederBug2.gif

It seems as if it was trying to gradually adapt to a "running average hole position", instead of just taking the holes as definitive guides.

This might make sense when your hole recognition is completely unreliable and you can't trust the last result alone. If that was the intention, then maybe that's OK.

_Mark

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

[Jason von Nieda]

On Wed, May 13, 2020 at 10:59 AM ma...@makr.zone <ma...@makr.zone> wrote:

OK. A simpler case, so we're positive it's not something I'm doing wrong.

1. Check my working assumptions: it is the job of the Vision to correct offsets, that may have happened since the feeder was "last seen". Due to a magnet mount shifted, the homing fiducial or end-stop slightly moved, your steps per mm tuned, a fresh belt mounted or whatever can happen on a DIY machine. If the assumption is wrong, we can probably stop right here :-)
   

This is wrongish. The (original intended) job of the vision is to make it easier to set up strips quickly and to correct drift over the length of the strip due to inexact original reference hole captures. If the strip has moved significantly since last used I'd expect you to rerun auto setup. I understand this doesn't cover the use case you are describing, and it would be good to cover that case.

2. Otherwise, start fresh with the OpenPnP test case
   
3. Manually change each hole X coordinate by -1mm. So the distance of the holes remains constant, the feeder is just shifted in X, as it might happen, after you had an X end-stop crash or whatever.
   

If you have an end stop crash and don't rehome then your bottom camera position, home location, drop bin location, positions of auto feeders, etc. are all incorrect. The machine needs to know where it is :)

2. Apply.
3. Then use Feed, repeatedly.
   

https://makr.zone/ReferenceStripFeederBug2.gif

It seems as if it was trying to gradually adapt to a "running average hole position", instead of just taking the holes as definitive guides.

I can't remember offhand the reason for this behavior, but I think the first reference hole is used as the definitive reference for the line, and the other end of the line is based on the vision hole. I think there may even be a Github issue filed about using all the vision holes as the guide.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/489a10b2-f032-56c5-ed2f-27f22506ff06%40makr.zone.

[Slavko Kocjancic]

On 13. 05. 20 18:08, Jason von Nieda wrote:
>
>
> On Wed, May 13, 2020 at 10:59 AM ma...@makr.zone <ma...@makr.zone> wrote:
>
> OK. A simpler case, so we're positive it's not something I'm doing
> wrong.
>

> 1. Check my working assumptions: it is the job of the Vision to

> correct offsets, that may have happened since the feeder was
> "last seen". Due to a magnet mount shifted, the homing fiducial
> or end-stop slightly moved, your steps per mm tuned, a fresh
> belt mounted or whatever can happen on a DIY machine. If the
> assumption is wrong, we can probably stop right here :-)
>
>
> This is wrongish. The (original intended) job of the vision is to make
> it easier to set up strips quickly and to correct drift over the length
> of the strip due to inexact original reference hole captures. If the
> strip has moved significantly since last used I'd expect you to rerun
> auto setup. I understand this doesn't cover the use case you are
> describing, and it would be good to cover that case.
>

Now I know why I have trouble. I taped my strips on piece of MDF and
this placed onto machine. Precision of placing inside 0.5mm. When I run
other set and then goes back I have some misplaced parts and didn't know
why. So More or less that feeder is unussable in that way (to tape bunch
of them to holder and swap that.)

[ma...@makr.zone]

Hi Jason, Tony

I've implemented the pick and place location check. It recognizes the pockets in the strips and the placements on the boards.

Assuming a tolerance of 0.1mm (adequate for the 0201 parts in the example), I had trouble with the accuracy and this uncovered more issues.

The ReferenceStripFeeder  standard pipeline has a Canny edge detection in front of Hough Circles.

But Hough circles has its own Canny edge detection in-built, so this will create "the edges of the edges". What Hough is seeing is this (simulated with two Cannies in a row):

Sometimes it will therefore fuse parts of the outer and inner circles together and create this:

That's easily observable in the NullDriver Auto Setup.

The Canny should be removed.

Also, I don't think a Median Blur is a good thing before edge detection, it will amplify aliasing. Just leave the Gaussian blur in.

When I disable Canny and BlurMedian I get this:

Now I can successfully pick 0201. Well in the NullDriver... :-)

That's what I'd recommend. But as @tonlyluken is on it, I hope he can consider and integrate this:

<cv-pipeline>
   <stages>
      <cv-stage class="org.openpnp.vision.pipeline.stages.ImageCapture" name="original" enabled="true" settle-first="true" count="1"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.ConvertColor" name="gray" enabled="true" conversion="Bgr2Gray"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.BlurGaussian" name="predetect-1" enabled="true" kernel-size="5"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.DetectFixedCirclesHough" name="results" enabled="true" dp="1.0" param-1="25.0" param-2="20.0"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.ImageRecall" name="recalled" enabled="true" image-stage-name="original"/>
      <cv-stage class="org.openpnp.vision.pipeline.stages.DrawCircles" name="display" enabled="true" circles-stage-name="results" thickness="1">
         <color r="255" g="0" b="0" a="255"/>
      </cv-stage>
   </stages>
</cv-pipeline>

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jxCWJR5L%3DEets7g5HA0hVinZR%3D%2B-24d5hwf6E1mD9y8Sg%40mail.gmail.com.

[Marek T.]

I'd try to use a Normalize yet.

[ma...@makr.zone]

Marek, I don't understand.

[Marek T.]

I'm not any expert about the pipelines but remember that often use Normalize stage after blurs and it gives good effects.