On Thursday 07 November 2013 12:11:03 Russell Brown did opine:
> I've been playing around with camview and a little 10mm endoscope type
> USB camera to see if I could rig such a thing up as an edge finder
> permanently mounted my mill's head.
>
> That's OK but you have to get very very close to the workpiece for even
> a half decent resolution which doesn't work when there's a collett
> holder and tool in the spindle (part of the reason for doing this is to
> avoid chucking the edge finder so I don't want a spindle type camera).
>
> I also tried a USB 'microscope' but the depth of field is very small
> again you have to get pretty close and twiddle with the focus to get a
> useful resolution.
>
> Has anyone found a USB camera with both a high magnification and a
> decent depth of field? (I've a feeling that these are mutually
> exclusive)
They are.
> or even one that can focus at a high resolution from a
> workable (~200mm?) distance?
I am in the process of trying to imagine a suitably rigid mount for a
logitech webcam, about $90 USD at wallyworld. Optically its ok with a
2540x1950 or so resolution, and has autofocus down to well within reach if
I already have a 1" long tool in the collet.
I get a camera image that would allow me to put the two sides of a PCB I am
carving more than close enough to drill half way thru the pcb from each
side, and then insert the drill bit into the resultant thru-hole with
almost non-existent error. Certainly within a thou.
Its autofocus could be a problem because if it is not mounted dead on axis,
as determined by putting the crosshairs on the target, and being able to
run z up and down with zero xy shift of the image. Any motion of the
central crosshair on the image as the image changes size from the z motion
is a mounting error.
So that is the first thing to do, and nothing else is worth doing until
that objective has been achieved.
Once that has been achieved, then the applicable XY offsets need to be
determined and should work within a thou at the 30 to 100mm ranges I will
encounter. FWIW, the camera can focus closer than that but only manually,
however the library that supports that seems buggier than a 10 day old
piece of road kill. When it dies, you have to reboot AND power down reset
the camera, a right PITA. So I have not explored the possibility of
locking the focus, then running z to achieve best focus. That FWIW, would
remove some, but not all, probably 75% of the mounting alignment
criticality.
My biggest bitch is that the image processing in camview-emc, means I have
to tap the keys to move that last 2 or 3 thou, and then wait at least 3 or
4 very boring seconds for the results of that tap to make it all the way
through all the processing that adds the crosshairs etc, and actually show
the new position on screen.
Watching the cameras raw output, its making about 15 frames a second for a
just barely noticeable lag, but all that processing of such a huge image,
about a 5 megapixel image, is ruining what enthusiasm I had for the
project. It needs to be first run thru a decimator that just throws away
everything but the mathematically centered pixels, say 240x240 at the most,
effectively converting it to a much longer telephoto without damaging the
resolution of the central image a bit.
Such a much smaller format giving a 57,600 pixel image for the rest of the
video chain to process should reduce that processing time to just
milliseconds more than the two frames delay needed by the image rotation
facility, and be hundreds of times more pleasant to work with.
So thats what I am looking for, but the V4L list doesn't seem to want to
understand what I want to do so I haven't gotten any helpful suggestions
about how to do that. Everything suggested has converted the image into a
same angle of view but worthless fuzz ball by not throwing away the pixels,
but the resolution.
They don't seem to understand that I, nor our machinery, has a quarter to
call somebody that cares if the outside 4.9 megapixels of the image are
just dropped in the dev/null bucket. For what we want to do, its exactly
what the doctor ordered. Something that most any of the framebuffering
bits of linux ought to do without even synchronizing the read/write
circular buffer pointers. Humm, have I been looking behind the correct
closet door? Maybe not.
So that is where I am at the moment. Unhappy at not being able to do
something with linux video that as a retired television broadcast engineer,
I know is being done hundreds of times a day, live on the air, or canned in
a commercial. By production software that costs up to $25k a seat.
If you find a workable answer, I am all ears.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
One reason why George Washington
Is held in such veneration:
He never blamed his problems
On the former Administration.
-- George O. Ludcke
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
law-abiding citizens.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
