Camera capture

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Camera capture

Jump to solution
8,912 Views
jefff
NXP Employee
NXP Employee

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.Capture.JPG.jpg

1 Solution
6,776 Views
jefff
NXP Employee
NXP Employee

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 !

View solution in original post

0 Kudos
29 Replies
5,490 Views
danielhadad
NXP Employee
NXP Employee

Jeffrey,

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

Daniel

0 Kudos
5,490 Views
jefff
NXP Employee
NXP Employee

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

0 Kudos
5,490 Views
jefff
NXP Employee
NXP Employee

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.

0 Kudos
5,490 Views
david_dicarlo
NXP Employee
NXP Employee

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

0 Kudos
5,490 Views
danielhadad
NXP Employee
NXP Employee

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.

0 Kudos
5,490 Views
danielhadad
NXP Employee
NXP Employee

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

0 Kudos
5,490 Views
jefff
NXP Employee
NXP Employee

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

0 Kudos
5,490 Views
danielhadad
NXP Employee
NXP Employee

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:

main_diffs.PNG.png

5,490 Views
jefff
NXP Employee
NXP Employee

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:

MBEDCode Warrior
Trigger for ADC Hander
TPM1PIT running at 20 Hz or 50 ms
TPM0(Motors)4000 Hz or 0.25 ms5000 Hz or 0.2 ms
TPM1(Servo)50 Hz or 20ms50 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:

imageFile.jpg

Default MBED code with camera capture at 50Hz:

imageFile.jpg

Default MBED code with camera capture at 20Hz:

imageFile.jpg

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?

0 Kudos
5,489 Views
ftornado7
Contributor I

hello sir,

can you please describe the way to capture the data from camera the way you have done.

i have NI Labview but its not working.

then i switched to putty terminal but it shows data only not graphically.

can you tell me how to plot the graph of data ??

Thank you

Azaj Vahora

0 Kudos
5,491 Views
jefff
NXP Employee
NXP Employee

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

0 Kudos
5,489 Views
danielhadad
NXP Employee
NXP Employee

I can give you a tip: got a $3 flashlight from Harbor Freight that has over 24 leds in it with batteries! Hacked it apart and mounted it.

Daniel

0 Kudos
5,489 Views
jefff
NXP Employee
NXP Employee

Assuming you connected directly to battery, did you use current limiting registers or a LM317 regulator/(POT or PWM) for the mounted lights?

0 Kudos
5,489 Views
danielhadad
NXP Employee
NXP Employee

I brought over the battery from the flashlight as well.  The lights have 'dark patches' so I plan to remove them from the PCB that came with the flashlight to mount them myself.

That said, supposedly a good line processing algo doesn't need good lighting :smileywink:

Here's a pic of my car showing the lights in front with separate battery pack.   Note the o-scope mounted on the camera mast to review camera data.

IMG_20130910_132240.jpg

0 Kudos
5,489 Views
jefff
NXP Employee
NXP Employee

Very cool picture of your car!

I did not realize you brought the battery pack with it. I actually wired mine into the main regchargeable battery hence my question.

0 Kudos
5,489 Views
r6aanf
NXP Employee
NXP Employee

Hi Daniel:

Thanks, that is looking really slick. Well built.

We might doing the same, racing day probably toss in brand new set of batteries.

Thao.

5,489 Views
danielhadad
NXP Employee
NXP Employee

Jeffrey,

Another tip-- don't use the "I" in the PID.  The steering servo already had integration built-in...     Most you should do is PD ;-)

I made a paper track as well in the living room.  Wife doesn't seem to mind... yet.

Daniel

0 Kudos
5,487 Views
jefff
NXP Employee
NXP Employee

Daniel,

Regarding the PD tip above, thanks. I was doing a PID even though the steering servo has one too because lecture #4 of the 5 part lecture from India by Prof. Umanand implied it. However, I am guessing that there is a problem with the lecture. At the end of the lecture, it also indicates that the speed does not seem to feed into the steering control. I don't see how this is correct.

0 Kudos
5,493 Views
danielhadad
NXP Employee
NXP Employee

I recall Prod. Umanand saying that double integration control was bad (has to do wtih .  Servos have integration built in by definition (at least from what he's saying).   Any motor control is ultimately speed control (as motor speed is what is proportional to voltage).

My understanding from the lectures was that the current speed of the servo motor is sensed, integrated to get position, and that "actual position" compared against the 'target position' given from outside the servo to determine the error.  The error is then used with some factory set KI parameter to determine the new speed of the servo motor.

0 Kudos
5,495 Views
jefff
NXP Employee
NXP Employee

Yes, he says double integration is bad - in fact in lecture #3 at the beginning he has a PD controller and middle of lecture #4. However, at the end of lecture #4, he replaces it with a PID (see the green I in the slide). Very confusing to me.

0 Kudos