Practical ideas from Stephene Hawse and their PnP kit

[Vinay Dand]

Many of you may have noticed recent calibration and vision setting ideas from Stephane Hawse used in their LumenPnP kit on their youtube channel.

https://youtu.be/GoLCS8zTNdU

You may find good inspirational points and calibration PCBS available from them.
Which may be useful in our existing or incoming machines.

Would like to get your opinion on suitability of the same with newer test branch which is getting improved and more and more user friendly very rapidly thanks to efforts lead by mark, tonyluken and many community members clubbing their time, effort, knowledge and testing in real world scenario.

Best Regards,

Vinay

[mark maker]

Duh...!

Stephen Hawes should really follow the OpenPnP discussion group and use the testing version. I really can't believe this!

1. The point pattern lens calibration (0:35) is obsolete. Instead we've added Tony Luken's fully automated Advanced Camera Calibration featuring not only lens distortion compensation, but also camera tilt compensation.
   
2. The automatic Units per Pixel calibration (1:39) that he talks about as "down the road" is also already integrated in the automatic Issues & Solutions preliminary calibration (and refined in the above-mentioned Advanced calibration). Plus we also do it in 3D, so the Units per Pixel will be right on different Z levels, such as mounted feeders etc., i.e. at different camera distances! All automated and available right now in OpenPnP.
3. The automatic exposure calibration (2:16) is a valid idea. But it should be verified, taking the OCR labels of various new feeders classes into consideration, i.e. to check if those can't be brighter (conversely, the silk-screen seems half transparent). Plus such a rig should support our new automatic white balance calibration.
   
4. The automatic precision nozzle tip to camera offset calibration (2:56) that is announced but "down the road" is also already implemented in Issues & Solutions, using the confetti method.
   Frankly, I doubt his method will work with edges at plus/minus 45° angles. Users then need to set the outer tip diameter manually, not only a pain, but also a source of error. If there were three or better four edges at 90° steps, it could work, because then you can cancel out the nozzle tip diameter. This would also cancel out the typically large manufacturing tolerances of such PCB edges, at least relatively to each other, there might still be an absolute error relative to the homing fiducial.
   

Shipping the machine with a calibration rig is certainly a very good idea, but LumenPnP should really adopt our ways in the OpenPnP software and/or start talking with us if they think their ideas are better.

I'm very open there, but really? Following our project closely and using and understanding the testing version is a MUST!

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

_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/e360e0e1-2a58-4207-9922-4e4e9449297fn%40googlegroups.com.

[Jon Raymond]

I was also wondering how they are planning to do nozzle touch probing with a CP40 nozzle.. which is non conductive plastic?

[Stephen Hawes]

Hey _Mark!

Meant no offense, I'm sorry if I caused any!

I'm aware of these other features you mentioned, and was not at all trying to discredit their validity or usefulness. I definitely should have been more communicative in that last video about the current state-of-the-art in OpenPnP; I'm sorry for that. We have some ideas about other ways to perform some of these calibrations, and want to give them a try is all. I know y'all have a ton of expertise and nuanced understanding that goes into developing this piece of software, and definitely not trying to say that our "ideas are better." I thought some of the things we thought about doing were interesting and wanted to share it with the folks following the LumenPnP project. Was planning on playing with them using some Python scripts, not necessarily implementing them into upstream; was not trying to be presumptuous there. Definitely just want to play around with some funky other options and see what works!

Again, I'm sorry if I caused offense, I really appreciate OpenPnP and all the work that goes into developing it!

-Stephen

[mark maker]

Hey Stephen,

Oh, you misunderstood, I didn't take offense. Rather, I genuinely thought that you simply missed these developments and that Lumen users will therefore now miss out on them too (plus with some permanent hurdles erected).

And when I said I was open to better ideas, I really meant it, all it takes is good arguments, or better yet, a proof of principle. 😎

I hope you agree that we should talk freely about tech. I can assure you, my pointing all this out was genuinely well-intentioned, i.e., had the best interests of (future) OpenPnP/Lumen users in mind. I know my passion for these goals can be a bit intense at times. 😅

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c2082d22-1723-454c-b3ff-1079adabeed3n%40googlegroups.com.