Camera Light

[DavidGitz]

Thanks all for the suggestions. I think the final verdict is going to be replacing the white LED's out of a small LED flashlight with green ones, just for the sake of having a built housing, unless we can find one local, and then putting in the appropriate power regulation and connections.

Originally Posted by apalrd

1. The vision code is very very slow

Very true, which is why you shouldn't design your program to use the vision processing algorithm you design continuously. Instead, use it to give you a rough angle (whatever parameter you are going with), decrease the error of that parameter, and continue. We are planning on going through no more than 3 stages of this any time we enter our auto-score mode, and use PID control for our robot/manipulator movements, i.e. Rough, Middle, Fine correction.

Originally Posted by apalrd

and can cause great control lag to other systems. Think about this while manipulating your images.

Can you explain why it would cause lag in your other systems? I know why it should cause lag (because you are trying to move your robot/manipulator with to obsolete commands) but it should not cause lag due to communications or from the vision processing resources being used. If they are, you should make sure that all your vision processing is done (if you're using LabView, I have no experience with WindRiver) in the Vision Processing.vi and you are passing that data to global variables. If you don't do it this way you are much more likely to have lag issues.

When not in auto-scoring mode, the vision processing algorithm will be completely disabled. I haven't been able to do much testing yet but I assume this will reduce lag. Now we are getting around 4-6 frames per second I believe, and are shooting for around 12 without the vision processing, which is about what we were getting about last year if I'm not mistaken.

[apalrd]

Originally Posted by DavidGitz

Can you explain why it would cause lag in your other systems? ...

Those other systems rely on P control, which requires a consistent loop time to work. As soon as vision processing runs, the cRio CPU load goes to 100% and every loop gets behind, causing inconsistent loop times for the rest of the code. By attempting to do any vision processing, the change in loop time will cause the control loops to behave unpredictably.

Plus, in the tests I did with the Axis 206 camera, any significant movement while processing images causes the image to be blurry, and useless. (probably because of a long exposure time on the camera).

[rwood359]

This link is a LED Resistor Calculator.
Give it the LED operating voltage and the current you want. It returns the theoretical resistor value, the nearest higher standard resistor and the resistor wattage. It works for single LEDS and multiple serial or parallel LEDS.
http://www.hebeiltd.com.cn/?p=zz.led...tor.calculator

[gnunes]

Has anyone tried infrared? We have an Axis 206, and I thought it would be nifty to try one of these infrared (850 nm) flood lights. The camera can't see it!! They must have a pretty darn good IR filter in that camera, and it seems to be glued right to the CCD. (In other, non FRC, cameras I have used, the IR filter was easily removable...)

[Greg McKaskle]

At least on the 206, the filter is on the lens, not the sensor. If you purchase a new lens, say from Edmunds, you can get monochrome ones without a filter.

From the tests I've done in the past, the sensor definitely sees the IR, but the floodlight is VERY bright. I'd be concerned that it would wash out and would blind other cameras.

Greg McKaskle