Camera Light

[DavidGitz]

We are working on tracking the VISION TARGET with our Axis Camera, and are investigating what kind of light source should be used for the retro-reflective fabric.
White - Easiest, but we are worried that we will get false positives with our vision processing algorithm at an event. We get minor false positives with our current algorithm in our build area (using a fairly bright white LED flashlight), though they may be able to get tuned out (for the most part they are usually a lower score than the real target).
Red/Blue/Yellow - May get extraneous results from the LOGO PIECES.
Green - 1st choice, as this would probably be the brightest, but we may get false results from the Tower Lights and:
Rule 02, Part C: Any devices or decorations specifically intended to jam or interfere with the remote sensing
capabilities of another robot,including vision systems, acoustic range finders, sonars, infrared proximity detectors, etc.(e.g. including imagery on your robot that, to a reasonably
astute observer, mimics the VISION TARGET

Though not specifically called out, this could* cause a distraction to another robot's vision algorithm.
Purple - 2nd choice, I don't see any issues with the field, but intensity is less than a comparable green light, all things being equal.

What are other teams doing? Did you make your light or buy it? We will probably end up making a ring light surrounding the camera using this current supply and led's.

Obviously safety is an issue, so we will make sure that it isn't too bright that it will cause harm to people. The only other rule that I can find to guide us is this GDC response:
"There are no rules that prohibit a light source on the ROBOT. Note that the light source must not be a violation of Rule R02."

[Alan Anderson]

Originally Posted by DavidGitz

What are other teams doing? Did you make your light or buy it? We will probably end up making a ring light surrounding the camera using this current supply and led's.

350 milliamps is probably a lot more than you should be using. There's no need for a "blindingly bright" light. A simple four-LED flashlight module running at only 10 mA gives us enough response from the retroreflective target to almost saturate the camera.

[DonRotolo]

The 1 watt LEDs are, as Alan wrote, blindingly bright. You want something a lot less powerful. I can't say if a 10 mA LED will be bright enough, but look for something in the 2000-5000 mCd range. That's about as bright as a micro (one AAA) flashlight, which will be plenty.

Try Here

[BJC]

While our programmer was experimenting he found that a wider beam light (think shop light) gave a much cleaner image over the camera then a narrower beam (like a flashlight).

Hope this helps.

[G33K]

How about something like a 1 watt IR LED? Wouldn't blind anybody, and you could control TVs from miles away!

[apalrd]

Originally Posted by BJC

While our programmer was experimenting he found that a wider beam light (think shop light) gave a much cleaner image over the camera then a narrower beam (like a flashlight).

Hope this helps.

Being the programmer, I have some more input and more detail:

1. The vision code is very very slow, and can cause great control lag to other systems. Think about this while manipulating your images.

2. The light source I used first was a 12v drill flashlight. It didn't really work at all, because the code would just find a white circle (including the vision target, the wall, and the PVC) and nothing else. It might get the target if it wasn't in the direct beam of the light, but not work very well.

3. The light source I used second was a 60w incandescent bulb in a shop light (with a half-sphere reflector, you know what kind I mean, right?). It worked very well, sorta. The image detection worked fine, but nothing else did (the driver complained about lag, even at 2hz, and the control loops freaked out because of lack of consistent loop time).

4. We haven't decided what light to use yet. We might try colors, but colors require processing of the image in RGB or HSL mode, while white can be processed in greyscale.

[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.

[Tom Line]

Originally Posted by Alan Anderson

350 milliamps is probably a lot more than you should be using. There's no need for a "blindingly bright" light. A simple four-LED flashlight module running at only 10 mA gives us enough response from the retroreflective target to almost saturate the camera.

Alan - you're probably the right person to ask. We were also considering using a flashlight of some sort, however, you can't get the actual resistance of LED's with a multimeter, so I don't know how to go about voltage dividing them with a resistor so they get the proper voltage from a spike.

Is it possible to run them off a digital output pin? What's the allowable amperage out on one of the pins? I can't find that in the digital sidecar documentation.

[Al Skierkiewicz]

Tom,
In general, calculate needed series resistance on the LED drop of 1.2 volts and 20 ma. If you have high brightness LED or certain blue and white LEDs, the current may be higher. Small, surface mount LEDs will be in the order of 5 to 10ma. You will need to read the specific data sheet for the device you wish to use. Simply subtract 1.2 volts from your power supply to determine the voltage dropped by the series resistor. That voltage divided by .02 (20ma) will give you the resistor value.

[Alan Anderson]

Originally Posted by Tom Line;1006944...

Alan - you're probably the right person to ask. We were also considering using a flashlight of some sort, however, you can't get the actual resistance of LED's with a multimeter, so I don't know how to go about voltage dividing them with a resistor so they get the proper voltage from a spike.

LEDs don't have a resistance. Being diodes, they have a specific voltage drop. That's something you can measure. If your multimeter doesn't have a "diode" scale that goes high enough, you can try a 12 volt supply through a 1k series resistor and the LED. That will limit the current to no more than 12 milliamps, and you can measure the voltage across the LED directly.

[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