Feeder questions, mainly about expanding pushpull

[Chris]

Has there been any consideration to consolidating feeder types, or expanding the pushpull type? 

The capabilities that are baked into the pushpull feeder type sound amazing, but they don't appear to be usable with the feeders I have. I have an afarco mini3.2, which gets setup as either autofeeder, or slotautofeeder. I would love to be able to use the QR/OCR reading for setup, or the vision features for figuring out how consistent the pick location is. But it appears that I can't because there isn't support for actuating auto feeders. 

It seems like there is an opportunity to combine pushpull, auto, slotauto, and potentially other classes into one more general feeder type. pushpull seems 1 step away from working with auto feeders, it just needs the ability to control AF FEEDER actuators. pushpull also seems most of the way to understanding slots. It would be awesome to see these rolled into one more generic feeder type that can be configured to work with a number of different feeder types. 

It looks like I can kind of hack a push pull to drive an AF feeder if I write a script actuator to command the feed, but this feels like a work around to something that would improve OpenPnP by having it be natively implemented. 

[Toby Dickenson]

Hi Chris,

Yes, the openpnp feeder classes are not an example of great design.
Individually each feeder is useful, but collectively there is
duplication, and feature gaps. The issue is acknowledged, but I dont
think there is a plan to fix it.

PushPullFeeder is configured with two actuators. Both are treated as
boolean actuators, and actuate(true) then actuate(false) during each
feed cycle. Is that enough to drive your afarco feeder?

BambooFeeder shares some of the vision capabilities with
PushPullFeeder, but with a different actuator feature. Does that work
for you?

> --
> 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/a712f316-5277-48fe-ae28-2189a704477fn%40googlegroups.com.

[Chris]

Yes and no. Bambuboo or BambooFeederAutoVision as it shows up does allow the use of the actuator that I need for driving the feeder. And it does allow the use of the vision (if I can get the vision pipeline to detect the holes with the weird reflections from my feeders), but not the auto part detection through labels. 

I do think I can bridge the gap with the pushpull by using scripts. I've been able to write some python scripts that command the feeders, so if I can find a way to pass the feeder address I can make pushpull work by using a script actuator. I'll keep working on it. 

It just seems like feeders present a huge opportunity to simplify down to a smaller number of feeder types with various options to enable or disable and reduce the gaps/overlap between each type. 

[Jan]

Hi Chris!
We've discussed your points on feeders a few times in the past. There
is certainly room for improvements... Recap: automatic feeders could
feed asynchronously if the API is improved. Feeders shall provide a
"remaining" property (if applicable) and shall support to interface with
inventory systems. All this requires some code refactoring to provide a
unified GUI and behavior for common properties and reduce feeder
specific code. In addition, feeders like the PushPull feeder could be
extended by providing different options to execute a feed. This way they
could operate automatic feeders while providing their specific features
like automatic vision setup and cloning.
However, all this changes cut very deep into the code base and can
easily distort the user experience. Therefore it requires great care and
enough users with different feeder setups to test with...

Jan

> <https://groups.google.com/d/msgid/openpnp/a712f316-5277-48fe-
> ae28-2189a704477fn%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/

> eed15292-63e6-4ae5-8124-7968fd328810n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/
> eed15292-63e6-4ae5-8124-7968fd328810n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.