There are a couple items that need to get into the pipeline first, so the PropCAM can be connected to one's system. These are the DB-Expander board, which breaks out the PropCAM's 2mm 2-row header into a 0.1"-pitch SIP, and the MB Extension Cable, which permits a 6" separation between the PropCAM sensor module and the connected system. Because these items are also compatible with Parallax's MoBoStamp and daughterboard product line, Parallax will be carrying them and is having them produced. I've submitted the design files for both, so hopefully they'll be available soon.
Ultimately, there will be a Propeller motherboard which the PropCAM can plug into directly. I have a working prototype of this board but anticipate a couple more revs before the final design is nailed down. That's why the expander board and cable will be necessary in the short run.
I appreciate everyone's patience in waiting for the PropCAM. My announcing it so many months ago was like putting up a restaurant in the middle of a cornfield. Now it's a matter of building the roads so people can get there!
From the pictures, I assume this is a daughter board for the MoBoProp. Am I right?
····Yes.
If it is, can we use our own propeller boards and adjust the code to use different pins if necessary?
····Yes. Parallax will soon have a SIP adapter and extension cable available that will allow the PropCAM to be used with any Propeller board. However, the four data lines must be connected to ports A0 to A3. The four control lines are a little more flexible.
Does the lens you picked have a built-in IR filter and is it removable?
····No IR filter.
Have you tested or would you recommend a color wheel for the unit? (It would be nice to standardize on one if this is an open project)
····I have not. It would be easy enough to make one using a servo and some of the plastic filters that Edmund Scientific offers, though.
Have you compared notes with Andre' on external memory? (He is working on a RAM module for the HYDRA that may be perfect for image processing)
····His module sounds interesting, and his use of a CPLD to control everything is the approach I would have taken. However, for speed reasons, such a memory module would have to be interposed between the PropCAM and the Propeller. There just isn't time to write a frame to external memory as a separate operation. That would likely require a custom CPLD configuration.
Can you share with us the camera module you are using?
····Yes — eventually.
It has been a couple of weeks, any update on progress, cost, or availability date?
····No, I'm sorry to say. I've been up to my eyeballs finishing up daughterboard designs for the MoBoStamp-pe. But once the SIP adapters and extension cables are online, the pressure will be on to document the PropCAM and get some assembled. I'm really sorry this is taking so long!
Thanks in advance, I am interested in adding (stereo?) vision to some Bioloid robots I am planning
····Stereo vision is something I've planned for in the design. With a simple adapter, it will be possible to interface two PropCAMS to the Propeller and acquire their images simultaneously. I haven't yet figured out a way to display the images as an anaglyph, but frame sequencing for shutter glasses should be easy (to program — not on the eyes!).
Len
Thanks, Len, and everyone, for your continued interest and patience!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/2/2007 4:36:00 AM GMT
I have been desperately trying to understand how to interface with an OV6620 Camera, or something similar, would you be willing to help me with the communication protocol. I've read the data sheet but I still don't inderstand how to communicate with the Camera.
As much as I'd like to help, I've never worked with the OV6620, so it would be a complicated and time-consuming undertaking for me as well. When I designed the PropCAM, I looked at this sensor briefly, but decided it wouldn't be as good a match for the Propeller as the one I eventually picked. Since the OV6620 has so many pixels, it would be necessary either to:
1. sample a small portion of the overall frame,
2. have some auxilliary RAM available to store the entire frame, or
3. process pixels on the fly.
I believe this is the same sensor used by the CMUcam and that they use method 3, above, with a 75MHz SX, in version 1 and method 2 (using an additional FIFO buffer) in version 2. The SX at this clock rate is capable of 75 MIPS, compared with 20 MIPS for each Propeller cog. Moreover, with method 3, it's not possible to separate image acquisition from image processing, which makes the necessary code trickier and more "brittle". I would definitely recommend method 2, as a result. In any event, if you want to pursue this with the Propeller, it may be helpful to consult the CMUCam docs for ideas on how to interface it.
I'm sorry I can't be of more help, but I'm pretty saturated with work right now, and this would be a large undertaking for me. I would recommend taking an incremental approach. It will seem less formidible that way. For example, try:
1. reading and writing to the sensor's data registers.
2. generating the necessary clocking signals in sequence — not bothering to acquire any pixels. (An oscilloscope will be essential here.)
3. shifting in just the most-significant Y data line and see if you can draw a thresholded image.
This way you can create simple building blocks, perfecting each one before moving on to the next. If, once you get started, you have specific questions that could be addressed in the forum, I'll be happy to jump in when I can help.
Just a quick point of reference...if you're trying to figure out how to interface to the OV6620, I have a ton of GPLed source code up on my website for interfacing to this camera from an AVR mega8 microcontroller. My AVRcam has some overlap with the PROPcam (real-time blob tracking), though the two also have their differences (the AVRcam was made to track up to 8 different objects of up to 8 different colors at 30 frames/sec).
Anyway, check out:
www.jrobot.net/Projects/AVRcam.html
and
www.jrobot.net/Download.html
for links to the embedded source code for interfacing to the camera.
Regards,
John Orlando
www.jrobot.net
P.S. I've been bitten by the bug to start working on a new vision project, and was poking around when I came across the PROPcam...pretty cool. I'll be interested to see how this progresses.
Thanks for that information...I had actually seen this information before... I'm still trying to find the stuff I need.. I'm having a hard time deciphering all of the code.
I just looking for the basics of setting a register on the camera. Can· you help with that?
I have been looking at the Propeller... and am still a little dazzled by it all. So, here's what I'm thinking:
First, an incredible amount of work is being done a relatively few people... and if we really want to have products like the Propeller come around again, we should all make an effort to evangilze the product and company a little.
And we don't want to let these guys down.
I was looking at the educational program... and my first impression was that there should be directed at the 6th graders... sort of a "Propeller Shack."
And then at the other end of the spectrum there are a lot of really good scientists... stuck in their own sub-specialities... who look for brain toys so that they can understand what is going on at the other end of the campus...
I have absolutely no direct hands on electronic experience ... at all. I'm a hack programmer at best. But what I have found is that if I can figure out how to talk to people... in a particular specialty... the most amazing things can be made to happen. But... it requires the development of relationships... usually over long periods of time.
Long before I found the propeller I came across I saw some undocumented video chips... I actually don't need one... but there was a place that put out a challenge to see if anyone could make an undocumented video chip work... and it took a guy six months... but he got it done.
I used to have a company that produced digital angiography systems... sounds real complicated... but when you broke it down to the component level... it was actually really easy... it was mostly an integration problem. We solved it pretty easy because Kodak had some cameras on the shelf that they wanted to get rid of and told us basically where to go for advice. All we had to do was listen... then our marketing agreement with a local company got sold off to a company that Kodak just didn't like and the cameras disappeared. So I hired a micro-controller geek and tried to integrate a new camera... which actually was completely document... It was all Windows and C... I was a Mac and Pascal guy at the time... I had no time to help the guy and a year later we still didn't have a camera.
Then I came across Phil's stuff and was pretty impressed except that I don't know what is going on with him... But this thread has the second largest number of views on the entire forum.
Then I saw Eric's question... And I thought Phil gave him a fair and complete answer... didn't solve his question but gave some advice and was very nice about it.
So, my take on the problem is that I hate camera integration problems and I am thinking about doing something about it...but I would only do it if I could do it in full public view. I'm sure this is the right place but I'm not sure that this is the right time.
How you do things is sometimes more important than what you do... and I tend to beat a problem to death.
Anyway thanks for you replies.
For anyone trying to figure out how to make a hobby into a few bucks... write an intro to electronics... and implement every instrument on a Propeller ... and then sell the whole thing for $39.
What holds me back at this point is not wanting to disperse the efforts of the usual contributors to the forums...
What I most fear is starting something that everyone finds really interesting and thereby deflect their attention. So, if we just let everyone know that its ok to post questions to the thread but not answers from the usual sources... I think that takes care of my issues.
So, unless you have serious reservations about the timing... what I would do is put an open call for new contributors... what I would be looking for is a specialist with some reasonable amount of time on a regular basis, some electronics experience but no experience with video chips or micro-controllers... we would then interact with someone-- possibly Eric...who knows about micro-controllers but is struggling with video and do the whole thing so that folks learn something and we come up with an approach that is generally useful... and do it all in the public domain. I would try to make it as entertaining and informative as possible.
I wouldn't want Parallax engineers to have to respond at all...
Just wondering what bandwidth I'd need to send a PropCAM image serially? I understand that it's doing 30fps @ 4-bit grey-scale, and 128x96-pixel resolution, so am I correct with teh following?:
128 x 96 = 12288 pixels x 4-bit = 41952 bits x 30fps = 1474560 bps right? (You can tell I'm tinking out-loud!)
Hmmm, 1.5Mbps -- and that's assuming there's no over [noparse]:([/noparse]
OK, so will I be able to reduce the frame rate to (say) 5fps, or the even reduce then resolution?
I'm also assuming that the image data is held in hub RAM, so I'll be able to have a COG stream that data out using FullDuplex.spin?
Hmmm, lots of assumptions there!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
Please note that for video capture methodes like "sample a small portion of the overall frame" and "process pixels on the fly" to work the captured picture must be absolutely static!. I doubt a picture from a camera mounted on a model helicopter counts as "static" .
If your video interface can't grab a whole frame in one go, then the only option is to capture the whole frame in an external memory.
Looking forward to this!! My employer uses antique(!) robots (ABB IRB 6400 series) (Literally thousands of 'em) and this could very well be the gripper-mounted unfixtured part acquisition solution we've been looking for. A simple comparison of certain light and shadow patterns would do the trick. The robot needs only a discrete input and not having a fancy cable snaked through the robot spine and base (With the millions of flexing cycles) would be a BIG plus. As for image processing, detecting a certain pattern of light and shadows would do the trick, maybe even verify the correct part!
In regard to the Procam, is this for real?.
I would like tp buy one if I could.
When this thing is be sold?.
I heard so much about this and still nothing,
Looks like a vaporware so far.
Martin, the propcam has a global shutter so one frame is essentially completely still. To sample a section you just have to ignore some of the pixels when reading.
I've been kinda quiet lately, I know. Yes, the PropCAM is real and ready from a technical standpoint. But I've hit a snag sourcing a critical component for production. It will get ironed out, but it will take a little more time, unfortunately.
Now to the other questions: The frame rate is entirely under user control. If you wanted to take a single snapshot, you could. The captured data is completely static and fits in the Propeller's RAM with room to spare. So you could take a snapshot and upload it to another processor at your leisure before taking another one. The captured data can also be superimposed on the video output, if you want to record it that way.
I hope to have more to say soon about availability. I know the wait has been tedious for all concerned — myself included! I apologize for that, and I'm working diligently to overcome the production obstacles that have recently arisen.
Thanks for your continued interest and patience!
-Phil
Shame about the added wait, but I just know it's gonna be worth it
Thanks for the extra info' (don't suppose you know of any way I could wirelessly transmit (say) 10fps do you?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
I won't pretend I'm an expert on digital camera modules, but I do know that they work with CMOS sensors. These sensors are like DRAM cells. Each "DRAM" cell is "filled" with a charge, and then exposed to light. When light shines on the DRAM cell the charge leaks away. So after a short exposure time unlit cells still have some charge left, and lit cells have their charge leaked way. After the exposure time a "bucket brigade" system is used to transport the charges of individual rows of cells to the output detector, where the charge is converted by a fast DAC to a digital signal.
All this, means that there is a finite time between the exposure to light and the moment you have to capture the exposed digital data.
In other words, the camera module does -not- have an internal static memory which holds a complete frame for you to download at leisure.
Yes, one frame is "completely still", but it only last for 1/60'th of a second!
If the video capture hardware can't capture this whole frame as it passes, it will need to wait for the next frame, which will have a -different- picture if the object you are filming is not completely "still".
In other words, capturing only a fraction of a video frame will work only if you have the camera pointing at a "still life" of some sort, but it won't work that way when you are filming a rapidly moving object.
The Mars rovers have various cameras with various filters. In order to get the 3D info that NASA wanted out of the cameras, it had to account for the acquisition process, lens design & distortions, etc. The entire approach is completely documented...
I think that generalities about how CMOS sensors work are useful, but we have to remember that the advantage of CMOS sensors is that you can add pixel logic right onto the sensor... so exactly what any sensor can or cannot do is a function of exactly what the designer wants it to do.
That's why I'm so interested in the propcam... apparently it is a one-off design. I am very interested to see what supporting pixel logic it might have...
It used to be that a company had to be dedicated to camera chips... now anyone with a CMOS foundary can build a camera... so, I would be interested to know if there is a new kid on the block ... too!!!
you said "sample a small portion of the overall frame". This technique does not imply that the data needs to be read out at leisure. All you do it let all the data flow at its full speed but only store the part of it you need, so you might clock 1000 pixels but only commit 100 to memory.
Ah, now I think I understand the confusion, I assume Phil mean't use a small portion of the array, a region of interest. You have assumed he means read out a ROI then read out another and build up the image. Only Phil can say which he meant.
Rich, I assumed the silicon of the propcam was just a fairly standard CMOS device with a nice shutter, the product is the fact it is ready to go on a PCB with lens and complete with libraries. In capabilities its much like the arrays I have bought from Micron.
ps... for Martin... for machine vision problems... if you can get complete control of all of the timing... you can stobe samples with structured light and do all kinds of interesting things... which is another strength of the prop... you can depend on timing and where critical... actually measure it.
Yes, my idea of the problem was that the prop just wasn't fast enough to transfer the video capture data to the internal RAM of the prop.
I remember a Video capture card for an Apple ][noparse][[/noparse] that used a technique like I described. They used some extra hardware, a crystal clocked counter synchronised to line sync, some programmable comparators, and some latches, they could set up this hardware to only latch every fourth pixel. So with this set-up the Apple ][noparse][[/noparse] hardware could keep up with the video stream. For example they would first capture pixels 1..5..9... etc then at the next frame they would capture the pixels 2..6..10 etc, so after 4 passes they could assemble the whole picture. p.s. I don't remember the exact details anymore, it could be they captured every eight pixel for example.
Capturing only a windowed area of the picture of course also makes perfect sense if you want to downgrade the memory used. However, the pixel resolution described is already quite small, but maybe you are right, it depends on the intended application.
Comments
I guess you're busy with the final touches to this now -- right? Got any launch date and pricing yet?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
There are a couple items that need to get into the pipeline first, so the PropCAM can be connected to one's system. These are the DB-Expander board, which breaks out the PropCAM's 2mm 2-row header into a 0.1"-pitch SIP, and the MB Extension Cable, which permits a 6" separation between the PropCAM sensor module and the connected system. Because these items are also compatible with Parallax's MoBoStamp and daughterboard product line, Parallax will be carrying them and is having them produced. I've submitted the design files for both, so hopefully they'll be available soon.
Ultimately, there will be a Propeller motherboard which the PropCAM can plug into directly. I have a working prototype of this board but anticipate a couple more revs before the final design is nailed down. That's why the expander board and cable will be necessary in the short run.
I appreciate everyone's patience in waiting for the PropCAM. My announcing it so many months ago was like putting up a restaurant in the middle of a cornfield. Now it's a matter of building the roads so people can get there!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
You can add me to that list - nice one..
A couple of questions and comment on the PropCam.
From the pictures, I assume this is a daughter board for the MoBoProp. Am I right?
If it is, can we use our own propeller boards and adjust the code to use different pins if necessary?
Does the lens you picked have a built-in IR filter and is it removable?
Have you tested or would you recommend a color wheel for the unit? (It would be nice to standardize on one if this is an open project)
Have you compared notes with Andre' on external memory? (He is working on a RAM module for the HYDRA that may be perfect for image processing)
Can you share with us the camera module you are using?
It has been a couple of weeks, any update on progress, cost, or availability date?
Thanks in advance, I am interested in adding (stereo?) vision to some Bioloid robots I am planning
Len
Thanks, Len, and everyone, for your continued interest and patience!
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 2/2/2007 4:36:00 AM GMT
I have been desperately trying to understand how to interface with an OV6620 Camera, or something similar, would you be willing to help me with the communication protocol. I've read the data sheet but I still don't inderstand how to communicate with the Camera.
With Regards,
Eric
As much as I'd like to help, I've never worked with the OV6620, so it would be a complicated and time-consuming undertaking for me as well. When I designed the PropCAM, I looked at this sensor briefly, but decided it wouldn't be as good a match for the Propeller as the one I eventually picked. Since the OV6620 has so many pixels, it would be necessary either to:
1. sample a small portion of the overall frame, 2. have some auxilliary RAM available to store the entire frame, or 3. process pixels on the fly.
I believe this is the same sensor used by the CMUcam and that they use method 3, above, with a 75MHz SX, in version 1 and method 2 (using an additional FIFO buffer) in version 2. The SX at this clock rate is capable of 75 MIPS, compared with 20 MIPS for each Propeller cog. Moreover, with method 3, it's not possible to separate image acquisition from image processing, which makes the necessary code trickier and more "brittle". I would definitely recommend method 2, as a result. In any event, if you want to pursue this with the Propeller, it may be helpful to consult the CMUCam docs for ideas on how to interface it.I'm sorry I can't be of more help, but I'm pretty saturated with work right now, and this would be a large undertaking for me. I would recommend taking an incremental approach. It will seem less formidible that way. For example, try:
1. reading and writing to the sensor's data registers. 2. generating the necessary clocking signals in sequence — not bothering to acquire any pixels. (An oscilloscope will be essential here.) 3. shifting in just the most-significant Y data line and see if you can draw a thresholded image.
This way you can create simple building blocks, perfecting each one before moving on to the next. If, once you get started, you have specific questions that could be addressed in the forum, I'll be happy to jump in when I can help.I wish you luck with your project!
Best regards,
Phil
Hey thanks for that... I just assumed you were using a similar camera. Maybe the OV6620 like on the CMUCam might not be my best choice.
Again thanks for your insight.
Best Regards,
Eric
Anyway, check out:
www.jrobot.net/Projects/AVRcam.html
and
www.jrobot.net/Download.html
for links to the embedded source code for interfacing to the camera.
Regards,
John Orlando
www.jrobot.net
P.S. I've been bitten by the bug to start working on a new vision project, and was poking around when I came across the PROPcam...pretty cool. I'll be interested to see how this progresses.
Thanks for that information...I had actually seen this information before... I'm still trying to find the stuff I need.. I'm having a hard time deciphering all of the code.
I just looking for the basics of setting a register on the camera. Can· you help with that?
Regards,
ERic
·
Is the procam for sale yet?
I am expecting a shipment of undocumented video chips any day now.
Do you know where I can get some really tiny alligator clips?
Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lets see what this does... KA BOOM (note to self do not cross red and black)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lets see what this does... KA BOOM (note to self do not cross red and black)
Thanks, but I was just needling Phil.
I have been looking at the Propeller... and am still a little dazzled by it all. So, here's what I'm thinking:
First, an incredible amount of work is being done a relatively few people... and if we really want to have products like the Propeller come around again, we should all make an effort to evangilze the product and company a little.
And we don't want to let these guys down.
I was looking at the educational program... and my first impression was that there should be directed at the 6th graders... sort of a "Propeller Shack."
And then at the other end of the spectrum there are a lot of really good scientists... stuck in their own sub-specialities... who look for brain toys so that they can understand what is going on at the other end of the campus...
I have absolutely no direct hands on electronic experience ... at all. I'm a hack programmer at best. But what I have found is that if I can figure out how to talk to people... in a particular specialty... the most amazing things can be made to happen. But... it requires the development of relationships... usually over long periods of time.
Long before I found the propeller I came across I saw some undocumented video chips... I actually don't need one... but there was a place that put out a challenge to see if anyone could make an undocumented video chip work... and it took a guy six months... but he got it done.
I used to have a company that produced digital angiography systems... sounds real complicated... but when you broke it down to the component level... it was actually really easy... it was mostly an integration problem. We solved it pretty easy because Kodak had some cameras on the shelf that they wanted to get rid of and told us basically where to go for advice. All we had to do was listen... then our marketing agreement with a local company got sold off to a company that Kodak just didn't like and the cameras disappeared. So I hired a micro-controller geek and tried to integrate a new camera... which actually was completely document... It was all Windows and C... I was a Mac and Pascal guy at the time... I had no time to help the guy and a year later we still didn't have a camera.
Then I came across Phil's stuff and was pretty impressed except that I don't know what is going on with him... But this thread has the second largest number of views on the entire forum.
Then I saw Eric's question... And I thought Phil gave him a fair and complete answer... didn't solve his question but gave some advice and was very nice about it.
So, my take on the problem is that I hate camera integration problems and I am thinking about doing something about it...but I would only do it if I could do it in full public view. I'm sure this is the right place but I'm not sure that this is the right time.
How you do things is sometimes more important than what you do... and I tend to beat a problem to death.
Anyway thanks for you replies.
For anyone trying to figure out how to make a hobby into a few bucks... write an intro to electronics... and implement every instrument on a Propeller ... and then sell the whole thing for $39.
Rich
What holds me back at this point is not wanting to disperse the efforts of the usual contributors to the forums...
What I most fear is starting something that everyone finds really interesting and thereby deflect their attention. So, if we just let everyone know that its ok to post questions to the thread but not answers from the usual sources... I think that takes care of my issues.
So, unless you have serious reservations about the timing... what I would do is put an open call for new contributors... what I would be looking for is a specialist with some reasonable amount of time on a regular basis, some electronics experience but no experience with video chips or micro-controllers... we would then interact with someone-- possibly Eric...who knows about micro-controllers but is struggling with video and do the whole thing so that folks learn something and we come up with an approach that is generally useful... and do it all in the public domain. I would try to make it as entertaining and informative as possible.
I wouldn't want Parallax engineers to have to respond at all...
Later?
Rich
Just wondering what bandwidth I'd need to send a PropCAM image serially? I understand that it's doing 30fps @ 4-bit grey-scale, and 128x96-pixel resolution, so am I correct with teh following?:
128 x 96 = 12288 pixels x 4-bit = 41952 bits x 30fps = 1474560 bps right? (You can tell I'm tinking out-loud!)
Hmmm, 1.5Mbps -- and that's assuming there's no over [noparse]:([/noparse]
OK, so will I be able to reduce the frame rate to (say) 5fps, or the even reduce then resolution?
I'm also assuming that the image data is held in hub RAM, so I'll be able to have a COG stream that data out using FullDuplex.spin?
Hmmm, lots of assumptions there!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
If your video interface can't grab a whole frame in one go, then the only option is to capture the whole frame in an external memory.
Martin (Mahjongg)
I would like tp buy one if I could.
When this thing is be sold?.
I heard so much about this and still nothing,
Looks like a vaporware so far.
Graham
I've been kinda quiet lately, I know. Yes, the PropCAM is real and ready from a technical standpoint. But I've hit a snag sourcing a critical component for production. It will get ironed out, but it will take a little more time, unfortunately.
Now to the other questions: The frame rate is entirely under user control. If you wanted to take a single snapshot, you could. The captured data is completely static and fits in the Propeller's RAM with room to spare. So you could take a snapshot and upload it to another processor at your leisure before taking another one. The captured data can also be superimposed on the video output, if you want to record it that way.
I hope to have more to say soon about availability. I know the wait has been tedious for all concerned — myself included! I apologize for that, and I'm working diligently to overcome the production obstacles that have recently arisen.
Thanks for your continued interest and patience!
-Phil
Shame about the added wait, but I just know it's gonna be worth it
Thanks for the extra info' (don't suppose you know of any way I could wirelessly transmit (say) 10fps do you?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
BTW: I type as I'm thinking, so please don't take any offense at my writing style
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
I won't pretend I'm an expert on digital camera modules, but I do know that they work with CMOS sensors. These sensors are like DRAM cells. Each "DRAM" cell is "filled" with a charge, and then exposed to light. When light shines on the DRAM cell the charge leaks away. So after a short exposure time unlit cells still have some charge left, and lit cells have their charge leaked way. After the exposure time a "bucket brigade" system is used to transport the charges of individual rows of cells to the output detector, where the charge is converted by a fast DAC to a digital signal.
All this, means that there is a finite time between the exposure to light and the moment you have to capture the exposed digital data.
In other words, the camera module does -not- have an internal static memory which holds a complete frame for you to download at leisure.
Yes, one frame is "completely still", but it only last for 1/60'th of a second!
If the video capture hardware can't capture this whole frame as it passes, it will need to wait for the next frame, which will have a -different- picture if the object you are filming is not completely "still".
In other words, capturing only a fraction of a video frame will work only if you have the camera pointing at a "still life" of some sort, but it won't work that way when you are filming a rapidly moving object.
martin de jong (mahjongg)
The best one stop shopping for camera issues is NASA. http://anserver1.eprsl.wustl.edu/merb/help/index.html?sources.htm
The Mars rovers have various cameras with various filters. In order to get the 3D info that NASA wanted out of the cameras, it had to account for the acquisition process, lens design & distortions, etc. The entire approach is completely documented...
I think that generalities about how CMOS sensors work are useful, but we have to remember that the advantage of CMOS sensors is that you can add pixel logic right onto the sensor... so exactly what any sensor can or cannot do is a function of exactly what the designer wants it to do.
That's why I'm so interested in the propcam... apparently it is a one-off design. I am very interested to see what supporting pixel logic it might have...
It used to be that a company had to be dedicated to camera chips... now anyone with a CMOS foundary can build a camera... so, I would be interested to know if there is a new kid on the block ... too!!!
Rich
you said "sample a small portion of the overall frame". This technique does not imply that the data needs to be read out at leisure. All you do it let all the data flow at its full speed but only store the part of it you need, so you might clock 1000 pixels but only commit 100 to memory.
Ah, now I think I understand the confusion, I assume Phil mean't use a small portion of the array, a region of interest. You have assumed he means read out a ROI then read out another and build up the image. Only Phil can say which he meant.
Rich, I assumed the silicon of the propcam was just a fairly standard CMOS device with a nice shutter, the product is the fact it is ready to go on a PCB with lens and complete with libraries. In capabilities its much like the arrays I have bought from Micron.
Graham
I'm lobbying.
Rich
ps... for Martin... for machine vision problems... if you can get complete control of all of the timing... you can stobe samples with structured light and do all kinds of interesting things... which is another strength of the prop... you can depend on timing and where critical... actually measure it.
Yes, my idea of the problem was that the prop just wasn't fast enough to transfer the video capture data to the internal RAM of the prop.
I remember a Video capture card for an Apple ][noparse][[/noparse] that used a technique like I described. They used some extra hardware, a crystal clocked counter synchronised to line sync, some programmable comparators, and some latches, they could set up this hardware to only latch every fourth pixel. So with this set-up the Apple ][noparse][[/noparse] hardware could keep up with the video stream. For example they would first capture pixels 1..5..9... etc then at the next frame they would capture the pixels 2..6..10 etc, so after 4 passes they could assemble the whole picture. p.s. I don't remember the exact details anymore, it could be they captured every eight pixel for example.
Capturing only a windowed area of the picture of course also makes perfect sense if you want to downgrade the memory used. However, the pixel resolution described is already quite small, but maybe you are right, it depends on the intended application.
Martin.
Graham