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]

Jeffrey,

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

Daniel

[jefff]

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

[jefff]

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.

[david_dicarlo]

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

[danielhadad]

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.

[danielhadad]

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

[jefff]

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

[danielhadad]

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:

[jefff]

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?

[ftornado7]

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

[jefff]

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

[danielhadad]

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

[jefff]

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

[danielhadad]

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.

[jefff]

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.

[r6aanf]

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.

[danielhadad]

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

[jefff]

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.

[danielhadad]

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.

[jefff]

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.