Replace bottom camera by using top camera and two mirrors?

[Daren Schwenke]

Greetings openpnp people.

Lurker here, with a tendency to re-invent the wheel for entertainment purposes.

Wondering if anyone has tried to replace the bottom camera with two first surface mirrors and using the top camera?

I know this probably doesn't work for most of the machines I've seen as the camera is at a fixed distance from the platform, but mine isn't.

The design is a delta so the camera moves with the Z axis.

Two mirrors would eliminates the parallax and can look straight up at the nozzle.

Having the up camera moving with X,Y probably would break centering as it is written.  Rotation should work.

The camera is offset from the nozzle by only about 20mm so within the range I can compensate focus for the two bounces by lowering Z.  I can mount it closer actually, but the nozzle is in the frame then.

I only have one part rotator, but have a plan for changing the nozzles instead.

Thoughts?

[Jason von Nieda]

Hi Daren,

This should work fine. You should be able to set up two cameras (in the software) both pointing to the same physical camera, and then adjust location, offsets, and transformations for the mirrored one. Give it a try and report back :)

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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/315741cd-fa8f-4a55-bd8f-287cc7e43016%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TheCunningFellow]

Flying camera is an excellent idea and should probably speed things up over having to travel too the up camera.

Someone here (Mike maybe) has an old commercial machine with a flying camera that rotates out the mirror under the part.

I've been doodling some sketches of how I want to do it, but am just very slow at ever getting anything done.  It has no hope of being cheaper than a 2nd up looking camera.  Just hopefully faster.

[Daren Schwenke]

I would love to take credit here, but I actually had not contemplated mounting the mirrors on the effector.

That is a pretty good idea...

A 9g hobby servo mounted horizontally swinging an arm 90 degrees would easily do it.  Have the lower position employ physical stops so you precise positioning.

Arm on the servo long enough to mount along side the camera, so when it swings up, it lays flat against the effector.

You are going to make me build this I think.

[Jason von Nieda]

Let me clarify: I understood your original question to mean a fixed camera, which it sounds like you did too. That should be easy to do without changes to the software.

Flying vision is much more complicated and is not supported by the current software. Currently OpenPnP expects to stop, take a picture, perform processing and then move. Flying vision means coordination between the camera, vision, and movement systems and that will require changes.

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/34e4cf37-4406-4730-9231-2db377f58f21%40googlegroups.com.

[Daren Schwenke]

It's going to be a while, but I'd be happy to make the required additions.  

I'm getting way ahead of myself here and my target platform has other issues to work out first.

Care to point me to the relevant sections?  Perhaps this is self evident, but I recently cleaned house and don't even have a java IDE installed currently.

[Jason von Nieda]

It's not a relevant sections kind of situation. It's more like a ground up redesign of the motion system kind of situation. OpenPnP assumes that all operations are sequential and atomic. Flying vision means threading the job processor and making at least some of the motion system asynchronous. This is left as an exercise for the reader :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c59bd368-89fe-4692-809e-235a98d0eca1%40googlegroups.com.

[Daren Schwenke]

Well I may be lucky then because my current target motion platform is Machinekit (aka Linuxcnc).

Motion for that is in openpnp is currently implemented as MDI commands and therefore could be fired off asynchronously without contention.

So if the architecture allows, I could add a quick and dirty wrapper around the bottom vision code which extends and retracts on each call.

Setting the bottom vision location to something logical like the middle of the board would work if I can't disable that.

Emphasis on 'dirty', but it would work and allow it to prove it's value.

[Daren Schwenke]

It may be even simpler than that.  

I could just hook Machinekit to ignore moves to the bottom camera position and turn that it into the 'extend mirror command' instead.

The next motion command could then retract it (and move).

This would of course be screwed up by any pre-scaling of X,Y done in openpnp for compensation as the pattern would cease to match, and I've never actually tried to hook a G0/G1 either.  I don't know if that actually works.

[Cri S]

If you use top vision, and here lightning is critical, it adds 170ms of processing time per part. 

[Daren Schwenke]

If you are implying that top vision takes longer than bottom vision, I believe that would not apply.

If I understand Jason correctly, I would be assigning the same physical device as used for top vision, but openpnp wouldn't know/care about that and treat it as the normal bottom vision camera.

You would get the normal performance of the bottom vision camera, but if this works, subtract the time required to position the part over it.

As for lighting plans, top vision will be using a 50mm (something like that) halo light ring, and bottom vision a much dimmer ring which I hope is sufficient... We will see.

[Cri S]

Il lunedì 15 gennaio 2018, Daren Schwenke <darens...@gmail.com> ha scritto:

If you are implying that top vision takes longer than bottom vision,

 

No

For passives top vision is enought and it takes less time, probably less then using mirrors. Your need 120ms for camera delay, 20ms for processing, the rest for moving.

I believe that would not apply.

If I understand Jason correctly, I would be assigning the same physical device as used for top vision, but openpnp wouldn't know/care about that and treat it as the normal bottom vision camera.

You would get the normal performance of the bottom vision camera, but if this works, subtract the time required to position the part over it.

As for lighting plans, top vision will be using a 50mm (something like that) halo light ring.

Exactly that don't work for doing vision fast 

 

 and bottom vision a much dimmer ring which I hope is sufficient... We will see.

On Monday, January 15, 2018 at 2:43:22 AM UTC-5, Cri S wrote:

If you use top vision, and here lightning is critical, it adds 170ms of processing time per part. 

 

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2dff0cc8-3677-4d30-843f-d5221370101a%40googlegroups.com.

[Cri S]

The code is simple to do it, the movement must be asyncron, don't issue m400
or check g80 code.

On alignment you do normal vision pipeline, but on bottom camera, you have
to configure the location as NaN in order it don't move to camera.
This is only possible
doing it inside machine.xml and not inside gui.
On pre-alignment script, it must submit the async commands to move to placement,
enable mirror, and on post-alignment it must remove the mirror.
No need for changing anything inside code, just the part name or
package name must
be something special to engage this behaviour, in case annother bottom
camera is used.
If not, then it can always be used and don't need special char in
order to do on the fly
vision.

>> email to openpnp+u...@googlegroups.com.

>> To post to this group, send email to ope...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/openpnp/2dff0cc8-3677-4d30-843f-d5221370101a%40googlegroups.com

>> <https://groups.google.com/d/msgid/openpnp/2dff0cc8-3677-4d30-843f-d5221370101a%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

[Daren Schwenke]

Thank you for your input.  I still have a lot more research to do.

For the down light I was going to use a cool white, straight downward aiming bright led halo ring with an added sanded acrylic diffuser about 3mm away.   

That's just what I have on hand/can easily produce that seemed to fit with what I was seeing.  If that is inadequate or a more optimal configuration exists, I'm open to it.

For the up looking camera:  I'm seeing reds, neopixels, and some whites out there in straight on, square inward leaning, and round inward leaning configurations.

I have Neopixels, Dotstars, some pretty bright passive RGB and a couple cool white LEDs on-hand for that.

  

I have some 5630 high output neutral white ones coming for another project I could hijack too. 

What about just backlighting the part for up looking.

This is going to be a lot of fun.  :)

[Cri S]

If you don't need to do top vision as faster alternative to bottom
vision then it don't matter.
Top vision is only when you assembly only passives on all nozzles..
When for one nozzle you need bottom vision, then you can do bottom
vision for all nozzles, the timing penality is near 40ms..

>> 2018-01-15 9:44 GMT+01:00, Cri S <phon...@gmail.com <javascript:>>:

>> > Il lunedì 15 gennaio 2018, Daren Schwenke <darens...@gmail.com

>> <javascript:>> ha

>> >> email to openpnp+u...@googlegroups.com <javascript:>.

>> >> To post to this group, send email to ope...@googlegroups.com

>> <javascript:>.

>> >> To view this discussion on the web visit https://groups.google.com/d/
>> >> msgid/openpnp/2dff0cc8-3677-4d30-843f-d5221370101a%40googlegroups.com
>> >> <
>> https://groups.google.com/d/msgid/openpnp/2dff0cc8-3677-4d30-843f-d5221370101a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>
>>
>> >> .
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >
>>
>
> --
> 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 post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/2bb68aad-c7e8-406b-a9f3-9c408f69e02a%40googlegroups.com.

[Daren Schwenke]

I continued with this idea and have a 3d printable prototype built. Uses one servo for mirror flipping and a second one for parts rotation.

https://hackaday.io/project/45404/log/92904

[eSlavko]

I'm tempted to aproach one camera and mirror design as using 2 cameras involve trouble with bandwidth. But with mirror there are focus trouble. Does someone made automatic adjustable focus for webcam?

[Daren Schwenke]

On Thursday, February 15, 2018 at 12:44:32 AM UTC-5, eSlavko wrote:

I'm tempted to aproach one camera and mirror design as using 2 cameras involve trouble with bandwidth. But with mirror there are focus trouble. Does someone made automatic adjustable focus for webcam?

Cheap camera = tiny lens = greater usable depth of field

Not that I'm advocating my choice in camera here.  It sucks for a couple reasons.  Complete lack of control over exposure is the worst one..  However the range in which it stays focused is huge.

I also have the camera moving with the Z axis which will allow for using the same focal length for both top/bottom (with some changes in OpenPnP).

[eSlavko]

I just do quick test what I can get from cameras. One is webcam and other microscope. I set to focus on 3cm distance from front of lens. The capture area from webcam is 15mm x 12mm, and for Microscope is 8mm x 6.5mm. Fer measuring focusing distance I put little angled ruller in front of camera. So you see the focusing distance.

[eSlavko]

Ahh the picture names are removed... The top image is from Webcam and bottom image from Microscope. To set focus so close the webcam need to be opened and removed pin which prevent more than one turn of lens turning for focus.

[Daren Schwenke]

USB endoscope camera at 0, using my micrometer for the gauge.  

Equally blurry from about 38mm to 75mm.  :)

[eSlavko]

Far better than mine but probably still not enough for two mirror approach..  (camera paralel to nozzle 20mm apart)

[Daniel Dumitru]

I saw a time a go a commercial machine and mirrors where static, positioned along feeders.

However all those effort just to spare one single (5$) camera ? 

On Thu, Feb 15, 2018 at 12:05 PM, eSlavko <esl...@gmail.com> wrote:

Far better than mine but probably still not enough for two mirror approach..  (camera paralel to nozzle 20mm apart)

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6d562dc9-4ecc-45c8-a498-e2e57a93d95d%40googlegroups.com.

[Daren Schwenke]

I put the first mirror at a 66 degree angle which cut the beam path distance down considerably.

The beam path is still fairly long at about 65mm, but that is what was needed to not intersect the part from the side and still allow vertical clearance of already placed parts.

The grey cylinder here represents my maximum part dimensions and is 20x10mm.  The final version is tweaked from this which let me clear about 22x12mm.

[eSlavko]

Just got idea for one camera and mirror and near same focal distance.
But mirror need to move in 2 axis. One is rotation for 90 degrees and other is for retraction.
See sketch.
When mirror is in blue position the camera sees nozzle. When mirror is rotated to red position the camera see the board/components. When nozzle goes down we need to move mirror to some safe place. If there is some kind of cam there is possible to do booth motions at once. Mean blue position of mirror as is in sketch, but red one is closer to camera. So when mirror rotate it moves closer to camera to and frees place so the nozzle can go down.

[eSlavko]

Dne četrtek, 15. februar 2018 11.15.14 UTC+1 je oseba Daniel napisala:

I saw a time a go a commercial machine and mirrors where static, positioned along feeders.

However all those effort just to spare one single (5$) camera ? 

Not to save camera money but headache with two camera on same usb HUB trouble. 

[Daren Schwenke]

Yeah... I know. Not really worth it from that perspective.

I was targeting the beaglebone based printers I have though so usb bandwidth is at a premium, and the travel time to the camera is eliminated which could add up.

On Thursday, February 15, 2018 at 5:15:14 AM UTC-5, Daniel wrote:

I saw a time a go a commercial machine and mirrors where static, positioned along feeders.

However all those effort just to spare one single (5$) camera ? 

On Thu, Feb 15, 2018 at 12:05 PM, eSlavko <esl...@gmail.com> wrote:

Far better than mine but probably still not enough for two mirror approach..  (camera paralel to nozzle 20mm apart)

--
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.

[Daren Schwenke]

My nozzle is a fixed height with regards to my camera, so that wouldn't work for me.  

I would say use two mirrors instead and use the vertical motion of the nozzle to select which one is active.  

All the way up you get the first mirror for fiducial, nozzle down a little from there and the second mirror gives bottom vision, down more the mirror swings away for placement.

You then only need rotation of the two mirrors on a single arm for everything, and it's passive.

[eSlavko]

Hmm that's clever too. And probably more safe as it's not possible to crash mirror with probe.

Dne četrtek, 15. februar 2018 11.34.37 UTC+1 je oseba Daren Schwenke napisala:

[Daren Schwenke]

On Thursday, February 15, 2018 at 7:23:11 AM UTC-5, eSlavko wrote:

Hmm that's clever too. And probably more safe as it's not possible to crash mirror with probe.

I'm thinking mount a swing arm to gantry above stepper on a pair of bearings with the axis of the bearings parallel to the gantry so it swings out in front of the stepper.

Then mount a bearing on the arm at the bottom of the stepper.  For speed, attach a small spring to keep the bearing on the cam.

To the side of the stepper, mount a cam plate.  The cam plate has three offset levels, say 5mm,12mm,and 23mm from the stepper mount.

The bearing from the arm rides on the cam plate.  So as the stepper moves down with respect to the gantry, the bearing rolls up the three cam levels.

As the bearing moves out towards you, it swings the mirror arm out.  When it hits the 23mm level, the stepper can clear the arm for placement.

To the arm mount your two mirrors. The first lines up to the nozzle when the cam offset is at 5mm and reflects down towards the work area.  The second lines up to the nozzle when the cam offset is at 12mm and reflects up to the nozzle.

Across from your arm (or through it from the same side), your camera is mounted horizontally and static with respect to the gantry.

By making the 12mm offset flat a little longer, you could also focus on different height parts as you can move your nozzle up and down within that cam offset flat to focus.  Probably not worth the trouble, but you could.

If you need a visual aid, let me know.

[eSlavko]

Some sketch will be hopefull..


Dne četrtek, 15. februar 2018 16.02.02 UTC+1 je oseba Daren Schwenke napisala:

[Daren Schwenke]

Something like this:

[Daren Schwenke]

Yes.  It has to stop at exactly the same angle/place every time for this to work.  

I've tried to plan for this:

• The armature and linkage are designed to approach the apex of travel for the servo linkage when extended.  This extends rapidly, but then slows the mirror assembly down before it contacts with the hard stop.  It also gives me a huge range on the servo for fine tuning.
  
• I have the option of making the linkage spring loaded, or just using a digital servo as well.  I'm seeing how well the cheap ones work first since I designed around it. 
  
• A large area, hard stop for the extended position.
  
• Press fit real bearings with a little preload.
  
• Stainless pins, also press fit.
  
• Optics which are aligned and the UV cure glued into place

This seems to have worked.  For the video I was swinging the arm itself by hand, driving the servo unpowered in the process to a random angle.  If you look carefully at the video, I was still looking right down the bore of my 2mmx50mm shaft straight enough nearly every time to see the circle of light from the other end.  

So I'm hopeful..

[Daren Schwenke]

Second thing is how to setup Openpnp for more than one nozzle, and then more than one camera with mirror. Or I don't understand something...

In OpenPnP you can setup "two" cameras for top and bottom vision normally, but then can just point them to the same physical device (or so I'm told earlier in this thread).

Extending and retracting the mirror assembly will require a little code, hopefully in OpenPnP and using existing events.  

Worst case I could hook this event in Machinekit instead based on the coordinates requested matching a fake up looking camera position.  

Really worst case, I could use FUSE, clone the physical camera device as two FUSE ones, and then control the extension/retraction based on which device is being accessed.  I've written a couple FUSE modules for the "day job", and it's not really that hard actually but not a very nice solution.  I'm not sure OpenPnP would ever stop accessing the device to give me the trigger for this hook either, and so I hope I don't need to find out.

Making OpenPnP do the vision *while* moving would require core changes to OpenPnP.  That isn't happening for now.

I only have one head.  Multiple nozzles will be swapped out from a changer I have yet to design/build/steal someone elses design, and I believe OpenPnP supports this "out of the box".

[Cri S]

openpnp supports vision during move out of box, drop me a mail if you
need support for it.

2018-02-16 22:54 GMT+01:00, Daren Schwenke <darens...@gmail.com>:
>
>
> Second thing is how to setup Openpnp for more than one nozzle, and then
> more than one camera with mirror. Or I don't understand something...
>
>
> In OpenPnP you can setup "two" cameras for top and bottom vision normally,
> but then can just point them to the same physical device (or so I'm told
> earlier in this thread).
> Extending and retracting the mirror assembly will require a little code,
> hopefully in OpenPnP and using existing events.
> Worst case I could hook this event in Machinekit instead based on the
> coordinates requested matching a fake up looking camera position.
> Really worst case, I could use FUSE

> <https://en.wikipedia.org/wiki/Filesystem_in_Userspace>, clone the physical

> --
> 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 post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/d5b5bd24-e178-40b9-a4c8-86040b29d68c%40googlegroups.com.

[Daren Schwenke]

That's awesome, thank you. When I get to that point I'll let you know.

[Marek T.]

I hope I'm wrong, but for me your idea is mechanically very very hard to realize if we want get really serious repeatability and accuracy. But I believe that your project may be serious contribution to development of openPNP vision system into on-the-fly or multiple bottom vision direction.
So good luck !!! :-)

[Daren Schwenke]

There are two weak links in the mirror system as I see it right now.

1. I'm not sure that backlighting the parts is going to work as I don't have manual exposure adjustment on this camera so it may just be a glare filled blur.  So  I may need to put some lighting on the swing arm for front lighting which would make it heavier, probably forcing my arms to be thicker, and making everything slower.
2. To avoid excessive wear with the plastic stop, the stop area had to be flat and relatively large.  This opened it up to having a speck of dirt causing the optics to no longer be aligned and the two flat surfaces would tend to retain it.

If I switched it to a stainless stop, then I could mate it to a ball-end screw which would essentially be self cleaning.

I think it will work.  I guess I'll find out...  :)