University Programs中的主题 Re: Camera capture

Camera capture

jefff — Thu, 29 Aug 2013 11:13:05 GMT

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.

Re: Camera capture

david_dicarlo — Thu, 29 Aug 2013 13:10:01 GMT

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.

Re: Camera capture

jefff — Thu, 29 Aug 2013 14:43:38 GMT

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!

Re: Camera capture

jefff — Thu, 29 Aug 2013 18:52:23 GMT

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 !

Re: Camera capture

danielhadad — Fri, 30 Aug 2013 02:10:10 GMT

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:

Re: Camera capture

jefff — Fri, 30 Aug 2013 03:03:51 GMT

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

Re: Camera capture

jefff — Fri, 30 Aug 2013 07:59:41 GMT

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)

Re: Camera capture

danielhadad — Fri, 30 Aug 2013 13:18:16 GMT

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!!

Re: Camera capture

danielhadad — Fri, 30 Aug 2013 13:33:59 GMT

Jeffrey,

You may want to adjust the focus on your camera as well. The dips should look nice and square.

Daniel

Re: Camera capture

jefff — Fri, 30 Aug 2013 18:50:43 GMT

Daniel,

Yeah, my focus was off. thx.

I had not looked at the code in detail as I had just assumed it was verified and checked in and matched the CW code. I got rid of the inner j loop and it works better,

BTW, the code is capturing camera data from one camera, but it uses double buffering TFC_LineScanImage0, and TFC_LineScanImage1.

Here are some other differences/observations:

- Both don't properly print the TFC_LineScanImage1 properly

- The mbed code does not include the TFC_SetLineScanExposureTime routine that the CW code has.

- The CW code uses the PIT timer to initiate the camera line scan. The mbed code uses the servo TPM. Thus, there is a scheduling difference between the codes.

- The camera capture is not as fast in mbed versus Code Warrior. This is probably configurable with timers and such, but just an observation.

Regarding using Excel versus Labview, that is a good idea, however, I prefer the realtime display. I think Eli mentioned something about a free graphical processing alternative.

Jeff

Re: Camera capture

danielhadad — Fri, 30 Aug 2013 18:56:16 GMT

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.

Re: Camera capture

admin — Fri, 30 Aug 2013 19:42:24 GMT

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

Re: Camera capture

jefff — Sat, 31 Aug 2013 02:42:28 GMT

I was wrong. I thought TFC_LineScanImage1 was the double buffer. But it turns out that it is for the 2nd camera as you suspected. There are 3 videos that talk about his google code.

Re: Camera capture

david_dicarlo — Sat, 31 Aug 2013 03:32:54 GMT

I guess I saved myself a whole lot of grief by not even attempting to use the line sensor code...

Re: Camera capture

danielhadad — Tue, 03 Sep 2013 19:50:43 GMT

Wasn't a big deal-- just saw the "has issues..." comment and thought the bugs were intentional. But having scope data to tell me something was wrong was key. Will try to check in update in mbed soon.

Re: Camera capture

danielhadad — Wed, 04 Sep 2013 15:29:35 GMT

Update made in mbed-- up to 4.0 on the library now which has the fixes.

Re: Camera capture

jefff — Wed, 04 Sep 2013 15:46:51 GMT

Thx. Just curious. Do you have a summary of the changes you had to make?

Re: Camera capture

danielhadad — Wed, 04 Sep 2013 15:56:23 GMT

1) make # cameras an option so it doesn't run second set of loops if only 1 camera

2) fix '8' to '16' everywhere (i*16+j)

3) put in end of line stuff for first camera (if there is only 1 camera).

4) condition for end of line made to be ((i==7) && (j==15))

If you want code diffs- just check out library as separate thing in mbed and you can do version compare between 3 and 4 (file revisions...)

Here is the diff screenshot:

Re: Camera capture

jefff — Tue, 10 Sep 2013 03:42:23 GMT

For the mbed code, I was wondering what frequency the servo should be run since the camera exposure time is based on the servo frequency (unlike the CW code).

Here is a comparison of MBED code and CW:

	MBED	Code Warrior
Trigger for ADC Hander	TPM1	PIT running at 20 Hz or 50 ms
TPM0(Motors)	4000 Hz or 0.25 ms	5000 Hz or 0.2 ms
TPM1(Servo)	50 Hz or 20ms	50 Hz or 20ms

Attached are camera captured data where I used Eli's terminal printf to an excel program on the fly (my alternative to the expensive Labview).

CodeWarrior with camera capture at 20Hz:

Default MBED code with camera capture at 50Hz:

Default MBED code with camera capture at 20Hz:

Notice that there is a lot more light intensity and the edges are much, much sharper when the servo frequency is decreased.

Here is my question:

Why is the MBED running the capture so fast and why is the CodeWarrior code using the PIT instead of the TPM1 to do the ADC handler?

And what frequency should we be running the servo?

Re: Camera capture

jefff — Tue, 10 Sep 2013 05:48:11 GMT

I need to design some lights myself. My son and I made an oval paper track this past weekend. It covers our living room (my wife hopes it is temporary. lol). I have been messing with a steering PID controller trying to get the right parameters to keep the car on the track at speed. I am not going to be able to make it tomorrow as I have a lunch appointment. But I will probably come the following Monday. - Jeff