Defeating the mantis part 2

LCD glasses normally,

Polaroids, the screen is black!

write that one, so that will be a difficult one.

the LCDs in it 90 degrees.

:-)

adjust for minimal jumping

mjpeg format

streaming.

(all Linux GPL),

I suspect that full stereo vision, like full stereo hearing, is impaired by electronic processing. Subtle head motions affect sound localization. I'm reasonably sure that the brain uses tiny head motions and changes of focus vs lens flexing to add depth and space clues. You'll lose most of that by using simple camera lenses and mapping images to flat screens, just as full hearing is impaired by simplifying sound into left and right signals.

I love my Mantis.

John

On a sunny day (Wed, 09 Sep 2009 14:20:35 -0700) it happened John Larkin wrote in :

Yes, but can it do this? ftp://panteltje.com/pub/defeating_the_mantis_pic_7.jpg

LCD glasses normally,

Polaroids, the screen is black!

The brain is a pretty good image processor. I've been involved in a project in which a robot was controlled using a stereo view head mounted display and it was not difficult to control. Here is an article (I did the electronics & approx 50% of the software on the wheelchair):

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------

The image quality is not bad at all!

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------

I can't read it but I do like the way the pictures expand, first time I seen that. Mike

On a sunny day (Thu, 10 Sep 2009 15:39:42 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

Wow, that 'big dog' is very imprssive!

Looks like an almost-bridge between pins 6 and 7. :)

Jon

On a sunny day (Thu, 10 Sep 2009 17:44:50 GMT) it happened Jon Kirwan wrote in :

Na, it is a piece of fiber dust, probably from my sweater.

I like the text overlayed on top of the image!

It's a good image, how did you get that from a 640*480 webcam?

On a sunny day (Thu, 10 Sep 2009 22:01:05 +0100) it happened "IanM" wrote in :

Ah, I used a different camera this time, I have over 13 different cameras here. For the text overlay I have 3 methods.

The first one (very old) is subtitler YUV,

it will add text (even animations) to a mjpeg tools YUV stream. jp3cat can output that format, and you pipe via subtitler-yuv to mplayer, ffplay, ffmpeg etc for display. Text and image is controlled by the 'PPML' language, PPML stands for 'Panteltje's Picture Manipulation Language', a script basically.

The second method I developed later, is used in this project:

The text is basically a text file in the users home directory, and read once a second by the application, and overlayed on the screen, with full color control. As the text file format is very simple, you can write a dynamic (bash) script that for example uses RS232 data, say here from a the frequency counter freq_pic: and from the temperature measurement probe temp_pic: and any other external event basically, that can be sensed from the PC by the io_pic project: to update the on screen text.

The third method is the same, but requires transformation of the stream from the camera to individual (for example jpg or gif) images, and then used the Imagemagick 'convert' program to add text in the same way from a script, then displays the image. That method takes more CPU cycles as extra conversions need to happen, but can be more flexible as to fonts: In Linux, here is how to add text to a (almost any format) picture: convert -font helvetica -fill red -pointsize 36 -draw 'text 555,100 "Customer on line 1"' in.jpg out.jpg

So, to make it dynamic, in bash, you can do something like this: #other script reads I/O and set or clears /tmp/phone_flag1 #in.jpg is the output from the camera software for each frame. if test -f /tmp/phone_flag1 then convert -font helvetica -fill red -pointsize 36 -draw 'text 555,100 "Customer on line 1"' in.jpg q.jpg fi # process q.jpg for further display ...

Eats resources though, the mcamip method is the least resource eating way to do this, uses no CPU cycles to speak of.

I am working on increasing the number of frames per second from those Logitech E2500 webcams. Worked my way all back and am in the driver now... this will take time, rather complex. Problem is : No info on what is in them Logitechs... Hopefully it is possible.

On a sunny day (Thu, 10 Sep 2009 22:01:05 +0100) it happened "IanM" wrote in :

Here is the same image from the Logitech E2500 webcam: ftp://panteltje.com/pub/logitech_E2500_close_1W_LED_lighting.png

I could get closer (so more magnification), but that would leave no space to do anything. Already the camera was casting it's own shadow, so I used a 1W LED light bulb to light it from the side, that is why the dark shadows, These E2500 are very good with low light, but do not work at all outside.... I could change lenses on those, and get the magnification I want. The problem is however the frames per second (speed) in Linux, it is too low. After working myself through all the soft (various display programs, video 4 Linux, and the driver that I had to add this cam to in the first place), I found that the way the Linux driver was done is very simple: Run the camera in MS xp, do a USB dump, save the hex dump of the camera initialisation, and use it in Linux to initialise the camera. Of course you do not know which of the many registers and commands does what, but you get a picture. This breaks when a new model is added, so I should do the same (dump in xp). Just do not like that procedure at all, but the sensor chip seems to be under NDA, not a trace of a datasheet with register data. So, I wrote an email to the French guy who wrote the driver, as I found a posting by somebody from Logitech online that they did send him some info under NDA I think, asking the guy to just tell me how and what register to weak... Else I will have to switch to some other camera.

posting by somebody from Logitech online

That last line makes most sense. Just dump any manufacturer that keeps information for themselves. I'm doing the same with microcontrollers and SoC devices. No open source support simply means no design-in.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------

Nice to find out that my guess was probably right.

On a sunny day (Thu, 10 Sep 2009 22:01:05 +0100) it happened "IanM" wrote in :

Here is the same image from the Logitech E2500 webcam: ftp://panteltje.com/pub/logitech_E2500_close_1W_LED_lighting.png

I could get closer (so more magnification), but that would leave no space to do anything. Already the camera was casting it's own shadow, so I used a 1W LED light bulb to light it from the side, that is why the dark shadows, These E2500 are very good with low light, but do not work at all outside.... I could change lenses on those, and get the magnification I want. The problem is however the frames per second (speed) in Linux, it is too low.

I have got the functions of the sensor registers now. Found them in some other driver, no reply to my email request, hello, this is Linux, the world is a hack. So at least I can try some things to increase frame speed, maybe even get on working in strong light (should be shorter exposure = higher speed).

So at least I can try some things to increase frame speed, maybe even get on working in strong light (should be shorter exposure = higher speed).

It seems Logitech was not exactly lying when stating the E2500 webcam can do 30 fps, but it VGA mode (640 x 480) it is only 15 fps, as I noticed. This because it seems to use this controller chip (video processor):

In 352x 288 (CIF mode) it can do 30 fps, but that is really an insufficient resolution in 2009. So, the Logitech E2500 webcam are now out for 3D use, and any serious video with moving stuff actually.

I dare say Logitech does misleading advertising in this case, so watch out.

anything.

Linux,

working

Mantis 1, Jan 0.

John

On a sunny day (Wed, 16 Sep 2009 18:19:44 -0700) it happened John Larkin wrote in :

Linux,

working

Not really, how about 2 of these: ftp://panteltje.com/pub/defeating_the_mantis_pic_7.jpg

Panteltje 10, Mantis 0

Hey I am just trying some things, while you are obstructed by those glass clunkers.

Linux,

working

clunkers.

It's not hard to take a pic like that. USB microscopes start at around $50 or so. The problem is to get good illumination, high resolution, serious stereo vision, practical soldering-iron-and-hands working distance, and operating convenience. That's what you pay for in a Mantis.

John

On a sunny day (Thu, 17 Sep 2009 07:03:34 -0700) it happened John Larkin wrote in :

clunkers.

Actually the problem is getting good frame speed, and correct switching time on a LCD, and / or frame lock. Those other issues have been solved. And I do not want soldering fumes destroying my camera lenses, so maybe use some protection clear filters (replaceable).

3000 $ for a piece of glass is a rip off.

2 PAL 50 frames per second cameras are 90 $ total, 2 extra lenses 20 $, a digitiser, and an old CRT monitor ,and LCD shutter glasses (20$) is the minimum for a working system

There are many configurations possible,

2 completely separate video channels for left and right can be made for less then 200 $, with an LCD for each eye. From things you can just order (I have half of it). Just would look funny, but you can then blend in any text or simple graphics like a HUD too. And of course record it.

Still investigating what is nicest / most economic works best. Unbelievable how good PAL cameras are.