Multiple up-looking cameras.

[Mat S]

Hello all. 

I wonder if openpnp can handle more than one up looking camera. 

Reason:

- One camera with wider field for bigger parts. Second with

small view area for small parts and for find-pith components. 

I do not see any option to assign part co camera. 

Does anyone know if it is possible to setup 2 up-looking cameras?

Thanks in advance.

Mateusz

[tony...@att.net]

Hi Mateusz,

I believe OpenPnP supports adding multiple up cameras (although I've never actually tried) but I don't believe there is currently anyway to specify which camera to use for a particular part.  I know some folks are interested in multiple up cameras so that they can align parts on multiple nozzles simultaneously but I don't believe any real work has been done on it.  Is there a specific reason you need two different camera for what you want to do?  You can always use AffineWarp and AffineUnwarp pipeline stages to effectively crop the image down to work on small parts.  Of course the resolution won't be as good on the small parts but that is rarely a problem.

Tony

[Mat S]

Hello Tony, 

We are placing large parts 40x40mm and also tiny ones 0201. 

I am working on bringing Neoden4 driver fully operational. 

Default camera is not good enough for both parts. For 40x40 it

has too small view. 0201 have only about 20x10px. 

Probably this problem will not be very often. 

Thank you for response.  

[Jarosław Karwik]

OpenPnp supports adding multiple cameras ..... but only first one is ever used.

Long time ago I was working on adding support for commercial  SmallSmt machine which does have two cameras. It requires several changes in code ( it was never merged as I sold the machine).

I heard that there is a trick which allows using scripts to "switch" active camera, but I have never seen it.

[Thorsten Wilmer]

Hi

I think the best approach would be to have a 'compatible' check mark for camera vs. Packages similar we have it for nozzles. One could have a script/button which could guess this setting from the package size.

Btw, I would have even the use to on the fly reconfigure the camera/two virtual cameras. It's of no use to transfer a complete 8MP picture. I would like to configure two sources depending on which source is used the camera is reconfigured to output a scaled down or cropped image.

Another use case is to have a camera per nozzle. There one would have a compatibility camera/per head. Or the function calculating moving the part to camera can use the 'next' suitable camera. And accidentally the next part is already over the next camera.

Kind Regards

 Thorsten

--
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/963b0b15-fa56-4c7b-b946-25b7a5ed55ecn%40googlegroups.com.

[ma...@makr.zone]

Hi

IMHO it would be ideal if one could choose the camera in the ImageCapture pipeline stage (but only if you want a different camera than the default). The pipeline and the camera (and light) form a vision setup together, i.e. often the pipeline properties need to be tuned to work with a specific camera (or light). Having it in the pipeline would also make it compatible with these plans:

https://groups.google.com/g/openpnp/c/7DeSdX4cFUE/m/VYDG6x6-AAAJ

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAKMJ56x-9S5r2gyHr2uPBNxajhEZ1b51%2BZ0C1aZrVRGscaVq6A%40mail.gmail.com.

[Mat S]

Hi, 

changing camera resolution according to part size is also needed in my case (Neoden4). Acquiring frame in full resolution takes much longer time than half of resolution. 

Can it be acquired currently? Maybe scripting can help?

Regards,

Mateusz 

[Mat S]

Hello, 

Is it possible to alter camera setting (resolution) based on part size by using scripting mechanism?

Regards,

Mateusz

[ma...@makr.zone]

In theory, yes. There is a ScriptRun stage that could do it in the relevant pipelines.

However, I doubt this actually works in practice. I never formally measured this, but experience tells me it takes a long time to (re)initialize a camera with changed settings. Might be camera specific, though.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77926337-4572-4ae8-bfe7-29dc7651a50dn%40googlegroups.com.

[Jason von Nieda]

Yes, all the properties are available for you to do this via scripting, but I would strongly recommend against it. Changing resolution means changing units per pixels and lens calibration, at a minimum. Instead, I would recommend using the higher resolution always and just modify your pipelines to ignore the areas you don't need.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77926337-4572-4ae8-bfe7-29dc7651a50dn%40googlegroups.com.

[Mat S]

Hello Jason & Mark.

Thank you for your insight. 

In Neoden camera driver "resolution" is basically how big part of view is gathered. Full view is 1024 x 1024, 

Resolution 512x512 (offset 256x256) means that i gather 1/4 pixels in the center of view. Gathering full view

takes about 2-4s. Gathering 256x256 takes 200ms. That is big difference. 256x256 is size about 3/4 of nozzle.

This is enough for all passives part and half of my ICs. By dynamically switching this parameter i can save 50%

of time. Start a job -> place all parts that require small view 95%, then change to full -> place rest. 

This do not change pixel per length. Changing resolution do not require any additional time, since

you specify resolution+offset every time you want new frame to be gathered. 

Another approach would be to place bigger parts using small field of view. Have you 

considered (or maybe it is possible) to align bigger parts by looking to corners of part?

In orginal Neoden software there is that option - it does not work because of many

reasons, but in openpnp this should work - here we have proper calibration (lens + geometry). 

Regards,

Mateusz