Camera capture

[jefff]

I have discovered a few issues with the camera and the latest FRDM-TFC (perhaps I have a bad one). [And yes, I did cover the back of the camera PCB since light bleeds through the PCB into the array (also mentioned in ProTip #1 Line Scan Camera Use)

1. The sample rate of the camera data is too slow (1 Hz or so). I estimated the 1 Hz by watching the led lights change and seeing labview updates.

2. My particular camera seems to be off by 20 degrees (I have to point it to the right by 20 degrees or so to get it to show up in the middle of the labview (see attachment). I wonder if this might be a poorly mounted array or perhaps misaligned lens? I will ask John if I can try another one.

[danielhadad]

Need to recall where to get the CW code so I can compare with latest rev. I downloaded it off of google code I think.

Yeah, haven’t yet done anything to improve—just looking at basic functionality first then looking to improve later.

Thanks, will have to look at the API more closely as to what those 2 variables are doing.

[danielhadad]

I suspected camera as well this evening- but thankfully had scoped it first.  Some nice bugs thrown in that I had to fix--- Eli didn't want it to be too easy....  :smileywink:

[admin]

I  am pretty sure the bugs are not intentional. Keep reporting!  We will patch.

[jefff]

If you changed the demo code, can you share what you found?

[danielhadad]

Jeffrey,

Sorry-- turned in just after posting that.  Thought the bugs were intentional as a 'test' for students -- but maybe not.   In any case this is the 'private' forum so probably ok to share.

It appears that it attempts to grab data from 2 linescan cameras so I commented out the set of loops associated with TFC_LineScanImage1 for now as I don't have a 2nd camera.

Second, it looks like the argument being passed to TFC_LineScanImage0 was incorrect in that if you did the math then i*8+j would not result in sequential values 0 to 127 but skipping and overlapping indices.  The correction for that argument is "i*16+j".  

In fact the dual loop thing isn't needed unless it was a copy from CW intended for something else-- you could just have a single loop 0 to 127 and make it much simpler to access the data, but I left in just in case.

I copied over the end of line condition (where it selectively prints out "\r\n") to the loops associated with TFC_LineScanImage0 and corrected the if condition to be (i==7) && (j=15) as the condition (i*8)+j==127 was also in error.  (could have changed 8 to 16 here too but went a different more easy to read way).

So my final code for grabbing the data from camera and sending to terminal:

                         for(i=0;i<8;i++) // print one line worth of data (128) from Camera 0

                         {

                            for(j=0;j<16;j++)

                            {

                                 TERMINAL_PRINTF("0x%X",TFC_LineScanImage0[(i*16)+j]);

                                 if((i==7) && (j==15))  // when last data reached put in line return

                                     TERMINAL_PRINTF("\r\n",TFC_LineScanImage0[(i*16)+j]);

                                 else

                                     TERMINAL_PRINTF(",",TFC_LineScanImage0[(i*16)+j]);

                            }

                            wait_ms(10);

                         }

Also, I used TeraTerm to capture the data-- no need for LabView.  I copied over the values from the terminal display to a vi editor, saved as CSV, then in Excel converted the values to decimal.

Here is my Excel chart of 3 captures-- with line in field of view center, left and right:

Which pretty much matches my o-scope results.    On to data processing!!

[jefff]

Since I was having so much trouble with the mbed demo3, on a whim I decided to move to Code Warrior. Running with Eli's R0 release, I am now getting great results with demo3 camera capture (the sample rate is much much better. There must be a defect in the lastest mbed code for demo3.

Here are some screen shots using CW in demo3 mode:

Coming up to Start/Finish line (manually moving my car)

Passing Start/Finish line (manually moving my car at this point)

[david_dicarlo]

What were you pointing the camera at? 

I find that at home, using the center room light alone (three 60W equiv bulbs, I think), the exposure time is longer.  How long I don't recall.  Here at my desk, with the under flipper light illuminating an 11x17 paper with the starting gate printed on it, the exposure time is on the order of 25mS. The exposure is significantly longer in lower light, though.

Might the low rate be due to the USB connection to Labview blocking the application from running? If I add printf's in, it slows things down, particularly since I have not bothered to figure out how to use the buffering and interrupts the MODSERIAL library allows.  I'm also further hampered by using a 9600 baud serial LCD I have instead of a 115.2k baud connection to a PC.  (I use the little LCD for portability.)

Given the size of the sensor and how the lens mounts, it's hard to imagine how a 20 degree offset can occur. The directory lists that you're in Oak Hill. I sit in J2. If you don't have access to a scope and would like to hook one up over lunch sometime, I've got one at my desk; just give a shout.

[jefff]

I am pointing the camera at a white sheet of paper with a block 1 inch stripe down the middle. Even if I comment out the terminal_printfs, I still see the LEDs changing at about 1Hz. The demo 3 code waits until TFC_ticker[0] is > 1000 and has 2 wait_ms(10) statements in it. I need to study the code some more to understand the delays here, but I just wondered if anyone else is having a similar experience.

Regarding the 20 degress offset, it is hard for me to imagine as well; I may take you up on your offer to get some scope time. Also, I may see if John has a spare camera for me to try over lunch. Thanks!

[jefff · Accepted solution]

Ok. Thx for the above replies. Turns out that my camera is fine. Thx to David for offering to scope the camera for me at lunch today. My issue must have been due to sampling issue using the ADC code etc... I was just jumping the gun and wanting to see the camera output now that I have my car all put together.

My son and I are having a blast with this !