Add visual localization features to the automatic feeder.

[bing l]

          Although visual positioning may be slower, it will definitely improve accuracy.  The  diy PNP and feeders cannot achieve the level of factory precision in processing. So  transplant the visual localization from the ReferenceStrip feeder to   ReferenceAuto feeder  is  a  good  idead.  So I  open a new pull request  to complete it.   

         In the past, many people, including myself, used ReferenceAuto feeder to call their own designed automatic feeder So adding visual localization functionality to the Reference Auto feeder would be very valuable.

          There is currently only one issue that needs to be resolved.
          The problem is probably like this: because the spacing between the sprocket holes is 4mm, push-pull feeders like 0816 can only move forward 4mm at a time. If you want to pick up parts like 0402 with a 2mm part pitch, you just need to repeatedly change the position of the nozzle by 2mm.  Then have the feeder push forward 4mm after every two pickups.

            Another type is automatic sprocket feeder, where the sprocket feeder we can see achieves an accurate 2mm advance each time. So every time the nozzle picks up 0402, the position is fixed. But each time the sprocket hole moves by 2mm, so the sprocket hole cannot be used as a visual coordinate.   

            Should we abandon the 2mm step spacing and only use the 4mm step spacing？Make it look like 0816.

            But only advancing 2mm each time is valuable because it can minimize the exposure of 0402 and reduce jumping out（Because if you move forward 4mm like the 0816 feeder, two 0402s will be exposed at the same time. When you pick up one of them, the other may jump out due to vibration） .   In this case, how should the sprocket hole be utilized as visual coordinates？  

            

            

            

           

           

          

          

[Toby Dickenson]

ReferencePushPullFeeder has some nice related features. It understands
"Part Pitch" and "Feed Pitch". That means the feeder can trigger the
push/pull cycle multiple times for parts which are wider than a single
sprocket hole (Part Pitch > Feed Pitch). It can also pick both 0402
parts exposed by a single 4mm advancement (Part Pitch < Feed Pitch).
Furthermore, ReferencePushPullFeeder has the "Feed Multiplier" which
lets it perform N push/pull cycles to advance the tape N*4mm and
expose 2N 0402 parts. It might be nice for ReferenceAutoFeeder to have
the same API.

For vision, note that there are some pull requests pending for
ReferenceStripFeeder vision, including a parallax mode which works
with transparent tape. It would be nice for ReferenceAutoFeeder to
have the same features and API there too.

A refactoring of feeder classes feels overdue. There are lots of
features in common, but not much code in common. And the code it does
have in the common base class is mostly a liability (I was looking at
usage of the Location attribute yesterday :-(

Toby

> --
> 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 visit https://groups.google.com/d/msgid/openpnp/8b0c308c-e004-476b-acfa-3e753bbc4f29n%40googlegroups.com.

[Jan]

Hi Bing!

On 04.02.2025 11:37, Toby Dickenson wrote:
[...]

> A refactoring of feeder classes feels overdue. There are lots of
> features in common, but not much code in common. And the code it does
> have in the common base class is mostly a liability (I was looking at
> usage of the Location attribute yesterday :-(

I was thinking exactly the same: we have a tone of different feeder
types in very different states ranging from very advanced (like
ReferencePushPullFeeder) to shall-be-considered-deprecated. This makes
maintenance very difficult, increases the frustration for users not
knowing which feeder to choose, causes desires to port certain features
and causes increased support.
To me - bare with me if my understand is incorrect - the auto feeder
and the reference push pull feeder are not that different in their
working principle. Both use actuators to advance the tape. The auto
feeder sends a trigger signal to a controller requesting the feed while
the push pull feeder uses a head mounted actuator to perform the feed.
If we'd combine them into one, the feed action would be the only thing
that's different.
We could then take this one step ahead: the difference between such a
new auto-push-pull-feeder and a strip feeder is also very little: the
strip feeder does not support a feed feature. Hence it would just not
provide any feed configuration options. This this, we'd likely cover
most of the feeders that are commonly used today. (I currently don't see
how tube and tray feeders could be integrated as well.)
For personal interest I'd add a drag-feeder option to such a new class:
like push-pull feed option but with much less parameters and instead
additional peeler configuration.
This sounds very appealing to me. However, I've to admit, that this
might be difficult to add if we'd try to avoid breaking existing setups
(using a commit() overwrite will very likely solve that).
Concerning your 2mm/4mm feed question: the referencePushPullFeeder uses
feedCount to handle pitch != feed. I'd suggest to do the same for
autoFeeder to support the best user experience. I'd say that it shall be
possible to either expect the sprocket hole at a certain location
(including 2mm part pitch awareness) or to extend the detection to
automatically handle 2mm offsets using a single vision location.

Jan

[PP.ca]

Take a look at the BambooFeeder - essentially an AutoFeeder with Vision which initially started as a proposal for a new generic AutoVisionFeeder.

Also, the current RefLushPull does support drag feeders and peel actuator already…

[bing l]

I just tested BambooFeederAutoVision, which can directly drive the Bingfeeder and 0816feeder I am using .   

I checked the log and it basically integrates the visual function and two pick function of Reference Stripfeeder on Reference AutoFeeder. So I suggest openpnp merge Bamboo Feed AutoVision and Autofeeder into one Reference AutoVisionFeeder. Otherwise, Otherwise, many people may mistakenly believe that Bamboo FeederAutoVision can only be applied to Bamboo .  Actually, as long as the automatic feeder you create uses the same M600 N5 F4 command as the 0816 feeder. So it can be driven correctly.   

As Jan mentioned, we need to reduce the difficulty of users' choices and not make openpnp too cumbersome. 

[PP.ca]

This was the initial thought for the type of feeder but it didn't work out. The only thing that is actually shared in code between BambooFeeder and ReferencePushPullFeeder is the vision and calibration part that was isolated in a Utils class. 

Blinds feeder is a different animal and doesn't share any vision or calibration code.

See  https://github.com/openpnp/openpnp/pull/1615

[bing l]

I put forward this idea on July 8, 2024, because I saw a Chinese feeder that solved this problem before  by  this  way, Of course, there may have been earlier people I didn't know were picking up 0402 in this way . I didn't expect it to eventually become a bamboo I don't think this is appropriate. This is a feeder  that combines the creativity of many people.  I hope it's not a proprietary feeder.   

 The calculation of component position by scanning sprocket holes has long existed on the RefereStrip feeder，There is really no need to turn an open design into a closed design.   Of course, what can be seen is that it is more advanced because its automatic setting function is better.

[bing l]

How about calling it first name : ReferenceAutoVisionfeeder?   An open name that can be used by all Autofeeders.  

在2025年2月5日星期三 UTC+8 01:56:42<PP.ca> 写道：

[Toby Dickenson]

Thank you for sharing that link in this conversation. It is a good
explanation of why we have fragmentation in the feeder
implementations.

[Jan]

Hi bing!
I now remember that I followed the old discussions! It would be really
nice to restart this approach with the ideas I mentioned in my fist
response. The discussions stated - at least to me - very clearly, that
they are very welcome (and they still are) but faced two issues: a)
separating the feeder into a different machine - as you mentioned
yourself - is not very helpful and might even cause confusion for new
users while it "just" provides a simplified way of merging stuff and b)
the refactoring was not complete. However, it also reveals the old and
well known problem that SimpleXML is opposed to modernization, which
will hopefully get better if we manage to get Jackson to replace it.
As of today I would be more then happy if someone would refactor the
referencePushPullFeeder as it turned into a very heavy monolithic beast
over the years. As for your purpose, I'd suggest to factor out the feed
action it contains adding a new one which serves AutoFeeder purposes.

Jan

On 04.02.2025 19:27, bing l wrote:
> 微信图片_20250205022404.png
>
> How about calling it first name : ReferenceAutoVisionfeeder?   An open
> name that can be used by all Autofeeders.
>
> 在2025年2月5日星期三 UTC+8 01:56:42<PP.ca> 写道：
>
> This was the initial thought for the type of feeder but it didn't
> work out. The only thing that is actually shared in code between
> BambooFeeder and ReferencePushPullFeeder is the vision and
> calibration part that was isolated in a Utils class.
> Blinds feeder is a different animal and doesn't share any vision or
> calibration code.
>

> See https://github.com/openpnp/openpnp/pull/1615 <https://
> github.com/openpnp/openpnp/pull/1615>

> acfa-3e753bbc4f29n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/8b0c308c-e004-476b-
> acfa-3e753bbc4f29n%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

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/46a7590e-44c9-4604-a4e6-61505f7d9d7an%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/46a7590e-44c9-4604-
> a4e6-61505f7d9d7an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[PP.ca]

Well, one good thing out of the BambooFeeder implementation was the separation of the vision calibration in the Utils class, so it makes it a bit easier to improve the push-pull feeder.

On the other hand, it's super-easy to rename the BambooFeeder to ReferenceAutoVisionFeeder if everyone agrees...

[PP.ca]

Jan, take a look in the Pandaplacer folder. There's a nice abstract class for vision feeders to be used as base for concrete feeders with or without actuators. It could be renamed to AbstractVisionFeeder.java and then have feeders built on top: Auto, PushPull, Blinds, etc.

[bing l]

I admit that the bamboo feeder has new improvements based on the autofeeder, but now when I want new openpnp players to recommend it for the 0816 feeder or bing feeder, yamaha CL feeder , Siemens electric feeder (we have changed Siemens feeder to high level trigger). I have to spend time telling them that it doesn't need any new settings, and the command it triggers is also M600 N1 F4. You can use the current  0816 controller directly. It just changed its name. As long as your feeder controller can push feeder 1 forward by 4mm after receiving M600 N1 F4, you can use it.    

If it's just for the developer to use, there's no problem. For example, the feeder controller of 0816  can be renamed as 1234 or 5678  feeder  controller, as they both receive M600 N1  F4  commands and send different pulses to the SG90 servo to control the angle. But you definitely can't add 1234 feeder or 5678 feeder in the stable version of  the official openpnp .

How meaningless this is, openpnp feels like a closed source project . Just like many finished openpnp machines you have seen. They changed the name of openpnp  software to  Apnp  or  Bpnp  and claimed that everything was developed by themselves.

That's also why I am applying for a new PR for RefereAutoVision feeder. 

[bing l]

I saw from this automatic feeder  know  how to advance 4mm a time then pick up 0402 in two time. It has been in existence for at least 3 years. I don't know if there's an earlier one.    

   

[PP.ca]

I am not against renaming and moving the Bamboo feeder. I wrote it initially to be generic, one of the Reference feeders and would be happy to see it become that eventually.

Making it specific for Pandaplacer was just a workaround to get the code merged since I didn't have the time to completely overhaul the PushPullFeeder.

[bing l]

the PushPullFeeder >>>This is no longer used by many people, there is no need to improve it again. The BOM cost of our  sprocket feeder is only $8.  I can open source it for anyone to use. I sold it for $16 just because packaging its accessories was troublesome and I couldn't work for nothing.

[PP.ca]

It would be great to open source it!

As for the ReferencePushPull - I personally think it is worth keeping around. 

If someone has the patience to modify it to use the abstract class AbstractVisionFeeder, it would be simplified dramatically. 

Unfortunately I don't have the time to do it myself.

The basic idea with the abstract class was: define a generic feeder that has vision calibration and then implement concrete feeders for different types of feed operations - motor based, head/nozzle motion, etc.

That was because the tape holes and part location are absolutely the same no matter what feed operation you use. 

For the sake of example we could even build a feeder with vision calibration, motor for advancing the tape but different actuator for the tape cover peeler... if anyone needs such a thing.

[vespaman]

onsdag 5 februari 2025 kl. 17:19:47 UTC+1 skrev tianl...@gmail.com:

the PushPullFeeder >>>This is no longer used by many people, there is no need to improve it again.

Hm, what do you base this on? I think there's a lot of us that is using the ReferencePushPull feeder.

 

 - Micael

[bing l]

Okay, my statement is incorrect.

[Jason von Nieda]

On Wed, Feb 5, 2025, at 9:54 AM, bing l wrote:

I admit that the bamboo feeder has new improvements based on the autofeeder, but now when I want new openpnp players to recommend it for the 0816 feeder or bing feeder, yamaha CL feeder , Siemens electric feeder (we have changed Siemens feeder to high level trigger). I have to spend time telling them that it doesn't need any new settings, and the command it triggers is also M600 N1 F4. You can use the current  0816 controller directly. It just changed its name. As long as your feeder controller can push feeder 1 forward by 4mm after receiving M600 N1 F4, you can use it. 

If it's just for the developer to use, there's no problem. For example, the feeder controller of 0816  can be renamed as 1234 or 5678  feeder  controller, as they both receive M600 N1  F4  commands and send different pulses to the SG90 servo to control the angle. But you definitely can't add 1234 feeder or 5678 feeder in the stable version of  the official openpnp .

I don't understand what you mean here. You can add any feeder you like to official OpenPnP. If you want to make a BingFeeder class and include it with OpenPnP it's very easy. Or a 1234Feeder or anything else. This is why we have the org.openpnp.machine hierarchy.

How meaningless this is, openpnp feels like a closed source project . Just like many finished openpnp machines you have seen. They changed the name of openpnp  software to  Apnp  or  Bpnp  and claimed that everything was developed by themselves.

Can you expand on this? How is it closed source? Are there entities distributing OpenPnP without providing source?

Thanks,

Jason

[bing l]

Can you expand on this? How is it closed source?

What I mean is that when it's called a ReferenceAuto feeder, the name doesn't have any special meaning. People can design their own automatic feeder and trigger it through M600 N1 F4.   

When ReferenceAuto feeder added visual localization features on top of this, its name became bambooAutoVision feeder. Any M600 N1 F4  triggered automatic feeder that requires this feature must be triggered  by bamboo. This makes people feel that all automatic feeders come from bamboo. 

So I hope this bambooAutoVision feeder, which can drive all automatic feeders  which  is  drived  by  ReferenceAuto feeder  before  , can be called back to its original name, ReferenceAutoVison feeder.    

This is different from Rapid feeder, Schultz feeder, Neoden4 feeder, and PHoton feeder, as these four feeders can only drive themselves.

BingFeeder class

 This is not necessary because it   can  completes  all the actions by the  ReferenceAuto feeder.   

Are there entities distributing OpenPnP without providing source?

I can't confirm this, I just accidentally saw someone change the name of openpnp, add a few features, and then tell people that this is self-developed and different from openpnp open source software.

[bing l]

It  necessary  to separately store the Bing feeder documentation on GitHub and then  add  the    link  on   https://openpnp.org/hardware/     to allow everyone who needs them to create them themselves?   People can get it themselves for $8 without me manufacturing and packaging it, and then add the RS485 features they want or redesign the 3D structure they think is good.

在2025年2月6日星期四 UTC+8 01:22:45<Jason von Nieda> 写道：