The PropCAM can definitely get the facial image into the Propeller's memory.The rest is up to the skill of the programmer. It's certainly not an application I would want to tackle!
Phil I am using a DB expander/sip to a Propeller PPDB using ports 0 - 7. In the end I want to display a picture on an LCD display like the one Parallax sells. With this code I get 255 back when the driver is started
and I get back -1 when the aquire method is run which I think means everything went ok. I tried many ways but as far as retrieving the longs (8 pixels each) from the buffer is this correct?
The line in question is - Pixels8 := long[@gray_buf_addr][i++]
P.S. Merry Christmas!!
Con
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
DATA0 = 0
DATA1 = 1
DATA2 = 2
DATA3 = 3
SCL = 4
SDA = 5
VSYNC = 6
MCLK = 7
Var
long Pixels8
Obj
cam : "propcam_parallel4"
fds : "fullduplexserial"
pst : "parallax serial terminal"
Pub Main | a, b, c, d, i, x, y
pst.start(57_600)
fds.start(9, 8, 0, 115200) 'start lcd
fds.tx($ff) 'clear lcd screen
fds.tx($cd)
fds.rx
gray_buf_addr := @gray_buf 'take picture
cam.start(cam#SNAPSHOT, @my_pins, @gray_buf_addr)
cam.acquire(cam#GRAB)
i := 1 'skip 1st long
x := 0
y := 0
repeat
Pixels8 := long[@gray_buf_addr][i++] 'IS THIS THE RIGHT WAY TO ACCESS THE GRAY BUFFER?
if i > 1535
quit
Dat
gray_buf long cam#PIXELS_PER_ROW << 16 | cam#ROWS_PER_FRAME, 0[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME]
gray_buf_addr word 0-0
left word 0 'Lefmost pixel in gray_buf for capture.
top word 0 'Topmost oixel in gray_buf for capture.
exp_type word cam#AUTOBOTH 'Set exposure mode to automatically adjust gain and exposure time.
sync_addr word 0-0 '@sync gets plugged in here.
exp_time word 20 'Start with minimum exposure time.
gain word $0f 'Start with medium gain.
target word 600 'Autoexposure target for avg_pix.
time_interval word -30 'Initial exporsure time = 1/30 sec.
avg_pix word 0-0 'Average pixel value from last capture * 100.
my_pins byte SCL, SDA, VSYNC, MCLK, DATA0, DATA1, DATA2, DATA3
When I try "Pixels8 := long[@gray_buf][i++]" I can see the first the first long if I start with i := 0 but the rest of the buffer comes back with 0's. I am wondering because the second long in gray_buf is the buffer and
starts with 0 before the brackets, something I've not seen before. So I am wondering what would be the proper way to access the pixel data?
The first long in gray_buf contains the dimensions of the buffer. So start the index at i := 1 to get the contents. Other than that, your pixel access statement is correct.
The reason you're getting zeroes is probably because exp_time and/or gain is set too low for your lighting conditions on the first call to acquire. If you're not using CONTINUOUS mode, I would recommend repeating acquire maybe 20 times or so first, before examining the pixel data so autoexposure can do its thing. You can query exp_time and gain during or after this loop to see what values the autoexposure settled upon.
Also, as a check on whether you're actually acquiring pixels, change
0[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME] to $aa[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME]
This will pre-fill the buffer with the value $aa, which will get changed on the first call to acquire if everything is working correctly.
A little farther along. I tried replacing 0 with $aa before the buffer and I get back $aa after starting the propcam_parallel4 object from the gray buffer. After an acquire though I get 0's. Using this code the exp_time shows 2047 and the gain rapidly climbs
to 31. I also started in CONTINUOUS mode then did 100 GRAB acquires while monitoring the exp_time and gain values. I noted the DB adapter letters in the Con section. And I made sure the lens cap isn't on! Any other ideas?
Con
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
DATA0 = 0 'a
DATA1 = 1 'b
DATA2 = 2 'c
DATA3 = 3 'd
SCL = 4 'e
SDA = 5 'f
VSYNC = 6 'g
MCLK = 7 'h
Var
long Pixels8
Obj
cam : "propcam_parallel4"
fds : "fullduplexserial"
pst : "parallax serial terminal"
Pub Main | a, b, c, d, i, x, y
pst.start(57_600)
fds.start(9, 8, 0, 115200) 'start lcd
fds.tx($ff) 'clear lcd screen
fds.tx($cd)
fds.rx
gray_buf_addr := @gray_buf 'take picture
cam.start(cam#CONTINUOUS, @my_pins, @gray_buf_addr)
Repeat i from 0 to 99
cam.acquire(cam#GRAB)
pst.char(pst#HM)
pst.dec(exp_time)
pst.char(pst#CE)
pst.char(pst#NL)
pst.dec(gain)
pst.char(pst#CE)
pst.char(pst#NL)
waitcnt(clkfreq+cnt)
pst.char(pst#CS)
i := 1 'skip 1st long
repeat
Pixels8 := long[@gray_buf][i++]
pst.char(pst#HM)
pst.dec(pixels8.byte[0])
pst.char(pst#CE)
pst.char(pst#NL)
pst.dec(pixels8.byte[1])
pst.char(pst#CE)
pst.char(pst#NL)
pst.dec(pixels8.byte[2])
pst.char(pst#CE)
pst.char(pst#NL)
pst.dec(pixels8.byte[3])
pst.char(pst#CE)
pst.char(pst#NL)
if i > 1535
quit
pst.str(string("Done"))
Dat
gray_buf long cam#PIXELS_PER_ROW << 16 | cam#ROWS_PER_FRAME, 0[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME]
gray_buf_addr word 0-0
left word 0 'Lefmost pixel in gray_buf for capture.
top word 0 'Topmost oixel in gray_buf for capture.
exp_type word cam#AUTOBOTH 'Set exposure mode to automatically adjust gain and exposure time.
sync_addr word 0-0 '@sync gets plugged in here.
exp_time word 20 'Start with minimum exposure time.
gain word $0f 'Start with medium gain.
target word 600 'Autoexposure target for avg_pix.
time_interval word -30 'Initial exporsure time = 1/30 sec.
avg_pix word 0-0 'Average pixel value from last capture * 100.
my_pins byte SCL, SDA, VSYNC, MCLK, DATA0, DATA1, DATA2, DATA3
I tried your program here, and it works okay. I would say double-check your wiring and make sure that SDA is pulled up to 3.3V. (It should be already if you're using the DB Expander, which has the pullups built in.)
I am trying to integrate two PropCams into my P2 project and am having a problem with HSYNC and Data.
To explore the issue, I set up a PropCam on an Propeller Activity Board... and wrote just enough code to configure, start and look at the signals. After confirming that I was getting all of the signals back on the PAB, I grounded the P2 and PAB and then jumped lines from the PAB to P2.
When I take MCLK out to the P2, I get a nice signal, but when I take the HSYNC and DATA signals out, the P2 isn't seeing them... even when I disconnect them from the PAB pins.
I'm thinking that the FPGA needs more signal strength and that the 680ohm resistors in the mix are limiting the signal from the PropCam to the P2 to the extent that the P2 isn't seeing them.
1. Does this make sense to you?
I have tried to tie the signals high with a couple of different resistors... without luck.
2. If this is the right idea... what value should I use for the resistors?
I finally got things working on the P2v, ~90FPS/8bit/serial/snapshot... very nice choice of hardware. In my opinion, for serious vision applications, the PropCam is the best value available to hobbyists.
Turns out my problem was solved by a couple of pull-down resistors. I was originally confused because I was mishandling the signal in software... and thought it was a hardware problem.
I am currently playing with the acquisition buffer, before adding a second camera... which will not increase my buffer size. I want to limit the buffer size before moving on to parallel mode. To get maximum performance, I am currently using 6 cogs... one for acquisition and 5 for signal processing.
I have a few questions.
1. Do you have any sensors left that have not been mounted to a board?
2. In parallel mode, we have four bits available, have you experimented with combining two images with different exposure settings to extend the bit depth of the image?
3. I want to precisely control the focus with the P2... do you know of a motorized lens that is available with the same footprint?
5. Me either... so if I'm not going to do it and you don't do it...
1. Fabulous:) Gives some thought as to what you want to do with them. I think P2 users are going to want a PropCam2!!!
I have two reasons for the focus issues... In normal stereoscopic vision (human) the stereo matching problem is limited (reduced to human capacity) by the act of convergence, which also triggers accommodation (focusing).
In normal machine stereo-analysis... the way everybody else is doing it... to make a match you have to look at all possible matches. The bigger the images... the more you have to look, the longer it takes. I have been told... but don't really know, that the in the human system there are only about 15-20 levels of actual depth perception, used most effectively by altering the point of convergence and total accommodation. When we point the two cameras a the same point in space... we can limit the amount of work the P2 has to do to consider what is going on in the area.
The second reason is that we can actually get depth information out of dynamic focusing algorithms. Which I have done in the past... and it looks like the current optics are really nice for this kind of application. I can add an external motor, but it is going to be really ugly.
I can't recall ever pushing the PropCAM to those limits. Unfortunately, my teaching duties prevent me from investigating this issue further at the present time.
I have the PropCam hooked up to an Activity Board, and I WAS taking all of the signals out to the P2v.
Since everything is timing... any little phase difference has a chance to blow up the process. Once I started
generating the clock from the P2... then simple transliteration of your PASM code did the trick.
SO... we now have PropCam working at 500+ frames per second. In normal daylight, I am getting very nice
images at 150FPS+, which I find absolutely amazing.
I haven't gone back to fix the 8bit serial stuff yet.
By the way, I was messing around with Chip, I hope I didn't offend you.
Comments
Can PropCAM be used for Facial Recognition?
The PropCAM can definitely get the facial image into the Propeller's memory.The rest is up to the skill of the programmer. It's certainly not an application I would want to tackle!
-Phil
and I get back -1 when the aquire method is run which I think means everything went ok. I tried many ways but as far as retrieving the longs (8 pixels each) from the buffer is this correct?
The line in question is - Pixels8 := long[@gray_buf_addr][i++]
P.S. Merry Christmas!!
Con _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 DATA0 = 0 DATA1 = 1 DATA2 = 2 DATA3 = 3 SCL = 4 SDA = 5 VSYNC = 6 MCLK = 7 Var long Pixels8 Obj cam : "propcam_parallel4" fds : "fullduplexserial" pst : "parallax serial terminal" Pub Main | a, b, c, d, i, x, y pst.start(57_600) fds.start(9, 8, 0, 115200) 'start lcd fds.tx($ff) 'clear lcd screen fds.tx($cd) fds.rx gray_buf_addr := @gray_buf 'take picture cam.start(cam#SNAPSHOT, @my_pins, @gray_buf_addr) cam.acquire(cam#GRAB) i := 1 'skip 1st long x := 0 y := 0 repeat Pixels8 := long[@gray_buf_addr][i++] 'IS THIS THE RIGHT WAY TO ACCESS THE GRAY BUFFER? if i > 1535 quit Dat gray_buf long cam#PIXELS_PER_ROW << 16 | cam#ROWS_PER_FRAME, 0[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME] gray_buf_addr word 0-0 left word 0 'Lefmost pixel in gray_buf for capture. top word 0 'Topmost oixel in gray_buf for capture. exp_type word cam#AUTOBOTH 'Set exposure mode to automatically adjust gain and exposure time. sync_addr word 0-0 '@sync gets plugged in here. exp_time word 20 'Start with minimum exposure time. gain word $0f 'Start with medium gain. target word 600 'Autoexposure target for avg_pix. time_interval word -30 'Initial exporsure time = 1/30 sec. avg_pix word 0-0 'Average pixel value from last capture * 100. my_pins byte SCL, SDA, VSYNC, MCLK, DATA0, DATA1, DATA2, DATA3starts with 0 before the brackets, something I've not seen before. So I am wondering what would be the proper way to access the pixel data?
The reason you're getting zeroes is probably because exp_time and/or gain is set too low for your lighting conditions on the first call to acquire. If you're not using CONTINUOUS mode, I would recommend repeating acquire maybe 20 times or so first, before examining the pixel data so autoexposure can do its thing. You can query exp_time and gain during or after this loop to see what values the autoexposure settled upon.
Also, as a check on whether you're actually acquiring pixels, change
$aa[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME]
-Phil
to 31. I also started in CONTINUOUS mode then did 100 GRAB acquires while monitoring the exp_time and gain values. I noted the DB adapter letters in the Con section. And I made sure the lens cap isn't on! Any other ideas?
Con _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 DATA0 = 0 'a DATA1 = 1 'b DATA2 = 2 'c DATA3 = 3 'd SCL = 4 'e SDA = 5 'f VSYNC = 6 'g MCLK = 7 'h Var long Pixels8 Obj cam : "propcam_parallel4" fds : "fullduplexserial" pst : "parallax serial terminal" Pub Main | a, b, c, d, i, x, y pst.start(57_600) fds.start(9, 8, 0, 115200) 'start lcd fds.tx($ff) 'clear lcd screen fds.tx($cd) fds.rx gray_buf_addr := @gray_buf 'take picture cam.start(cam#CONTINUOUS, @my_pins, @gray_buf_addr) Repeat i from 0 to 99 cam.acquire(cam#GRAB) pst.char(pst#HM) pst.dec(exp_time) pst.char(pst#CE) pst.char(pst#NL) pst.dec(gain) pst.char(pst#CE) pst.char(pst#NL) waitcnt(clkfreq+cnt) pst.char(pst#CS) i := 1 'skip 1st long repeat Pixels8 := long[@gray_buf][i++] pst.char(pst#HM) pst.dec(pixels8.byte[0]) pst.char(pst#CE) pst.char(pst#NL) pst.dec(pixels8.byte[1]) pst.char(pst#CE) pst.char(pst#NL) pst.dec(pixels8.byte[2]) pst.char(pst#CE) pst.char(pst#NL) pst.dec(pixels8.byte[3]) pst.char(pst#CE) pst.char(pst#NL) if i > 1535 quit pst.str(string("Done")) Dat gray_buf long cam#PIXELS_PER_ROW << 16 | cam#ROWS_PER_FRAME, 0[cam#LONGS_PER_ROW * cam#ROWS_PER_FRAME] gray_buf_addr word 0-0 left word 0 'Lefmost pixel in gray_buf for capture. top word 0 'Topmost oixel in gray_buf for capture. exp_type word cam#AUTOBOTH 'Set exposure mode to automatically adjust gain and exposure time. sync_addr word 0-0 '@sync gets plugged in here. exp_time word 20 'Start with minimum exposure time. gain word $0f 'Start with medium gain. target word 600 'Autoexposure target for avg_pix. time_interval word -30 'Initial exporsure time = 1/30 sec. avg_pix word 0-0 'Average pixel value from last capture * 100. my_pins byte SCL, SDA, VSYNC, MCLK, DATA0, DATA1, DATA2, DATA3I tried your program here, and it works okay. I would say double-check your wiring and make sure that SDA is pulled up to 3.3V. (It should be already if you're using the DB Expander, which has the pullups built in.)
-Phil
regards,
Custodian of #11 and #12 of 1500.
I am trying to integrate two PropCams into my P2 project and am having a problem with HSYNC and Data.
To explore the issue, I set up a PropCam on an Propeller Activity Board... and wrote just enough code to configure, start and look at the signals. After confirming that I was getting all of the signals back on the PAB, I grounded the P2 and PAB and then jumped lines from the PAB to P2.
When I take MCLK out to the P2, I get a nice signal, but when I take the HSYNC and DATA signals out, the P2 isn't seeing them... even when I disconnect them from the PAB pins.
I'm thinking that the FPGA needs more signal strength and that the 680ohm resistors in the mix are limiting the signal from the PropCam to the P2 to the extent that the P2 isn't seeing them.
1. Does this make sense to you?
I have tried to tie the signals high with a couple of different resistors... without luck.
2. If this is the right idea... what value should I use for the resistors?
Thanks,
Rich
I finally got things working on the P2v, ~90FPS/8bit/serial/snapshot... very nice choice of hardware. In my opinion, for serious vision applications, the PropCam is the best value available to hobbyists.
Turns out my problem was solved by a couple of pull-down resistors. I was originally confused because I was mishandling the signal in software... and thought it was a hardware problem.
I am currently playing with the acquisition buffer, before adding a second camera... which will not increase my buffer size. I want to limit the buffer size before moving on to parallel mode. To get maximum performance, I am currently using 6 cogs... one for acquisition and 5 for signal processing.
I have a few questions.
1. Do you have any sensors left that have not been mounted to a board?
2. In parallel mode, we have four bits available, have you experimented with combining two images with different exposure settings to extend the bit depth of the image?
3. I want to precisely control the focus with the P2... do you know of a motorized lens that is available with the same footprint?
4. Is the lens mount glued to the PCB?
5. Do you intend to do another camera for the P2?
2. No.
3. I can't recall having seen any, but I'd bet that someone out there has such a beast.
4. No, just screwed on with #2 sheet-metal screws.
5. No plans as yet.
-Phil
1. Fabulous:) Gives some thought as to what you want to do with them. I think P2 users are going to want a PropCam2!!!
I have two reasons for the focus issues... In normal stereoscopic vision (human) the stereo matching problem is limited (reduced to human capacity) by the act of convergence, which also triggers accommodation (focusing).
In normal machine stereo-analysis... the way everybody else is doing it... to make a match you have to look at all possible matches. The bigger the images... the more you have to look, the longer it takes. I have been told... but don't really know, that the in the human system there are only about 15-20 levels of actual depth perception, used most effectively by altering the point of convergence and total accommodation. When we point the two cameras a the same point in space... we can limit the amount of work the P2 has to do to consider what is going on in the area.
The second reason is that we can actually get depth information out of dynamic focusing algorithms. Which I have done in the past... and it looks like the current optics are really nice for this kind of application. I can add an external motor, but it is going to be really ugly.
Amazing what you did with the P1:)
I'm having problems pushing the PropCam above 275fps hooked up to a P2v in parallel/snapshot mode.
Was this your experience?
Thanks,
Rich
-Phil
-Phil
I have the PropCam hooked up to an Activity Board, and I WAS taking all of the signals out to the P2v.
Since everything is timing... any little phase difference has a chance to blow up the process. Once I started
generating the clock from the P2... then simple transliteration of your PASM code did the trick.
SO... we now have PropCam working at 500+ frames per second. In normal daylight, I am getting very nice
images at 150FPS+, which I find absolutely amazing.
I haven't gone back to fix the 8bit serial stuff yet.
By the way, I was messing around with Chip, I hope I didn't offend you.
Regards
Rich
https://www.parallax.com/product/28320
-Phil