camera trouble,cant tell the green-light from regular white light

[ahecht]

Originally Posted by Nimmy

I was also thinking to put a layer of some whitish plastic on the light to make it less bright.

The light should have a sheet of whitish plastic mounted in front of it. There was a piece of HDPE in the kit (shrinkwrapped with the cold cathodes) that is designed to be used as a diffuser.

[Eldarion]

Originally Posted by Athenian Roboti

We have found theat the camera sensors are overdriven. To remedy this, we have (temporarily) put sunglasses over the camera, and this seems to have worked. We may put a dark filter over it in the future. Good luck.

Team 852-- The Athenian Robotics Collective

I also ran into this problem. To fix it (without filters, anyway), write a value of 2 to the saturation control register (register 3), I.E. send a "CR 3 2" to the camera.

[AV_guy007]

Originally Posted by Nimmy

our programming team has been working all week on the camera
and they can't seem to be able to tell apart the green light we got
for FRC from the regular light from lightbullbs in the room,
we tried it from diffrent distances but the green-light seems to just
be so powerful that the camera gets "blinded" by it and sees it as white

anyone else have this problem?
is it possible our green-light is to powerful? thanks in advance

(sorry for typos, in a hurry)

my team was working on the camara today and had the same problem we have not found a solution to the problem. ours was reading 240 240 240 and did the same with the floresent lights in the room. we thought we could mabey have it track the wite light but then soon remembered how bright the arenas are.

let me know if you find a solution thanks

[AV_guy007]

Originally Posted by ahecht

The light should have a sheet of whitish plastic mounted in front of it. There was a piece of HDPE in the kit (shrinkwrapped with the cold cathodes) that is designed to be used as a diffuser.

thats how ours is set up but we still have the same problem

[devicenull]

Take a loot at the workbook here, page 6-7.. it tells you exactly how to fix that problem. (Or you can copy the values from the default code to the GUI and see how that works)

[Greg Marra]

Originally Posted by Mike

I was talking to Greg Marra today, who had the same problem. He finally fixed it. The problem was that he was using RGB instead of YCbCr.

Hope that helps
-Mike

Yea, what we were doing was using last year's Java GUI to try to calibrate the camera. Of course, if I had read a little bit more before I started I would have known that the Java GUI is by default in the wrong color space, and thus no wonder it was acting differently than the default code.

(Interestingly, Track White in RGB tracks the vision target brilliantly. It also tracks the flourescent lights and paper ).

Next time I get my hands on the camera, I just need to fix some pan/tilt backwardness and we should be in business.

[drinkdhmo]

I remedied the tilt problem for our camera by doing a little digging into the user manual. Somewhere in there it talks about the demo mode and the pan and tilt invert jumpers. It mentions that the tilt invert jumper needs to be installed while it is trying to track. We did this and it inverted the tilt axis, just as we wanted. The weird part is, ever since we did that, the board now responds to a jumper that is installed or removed while the power is off, where it did not before. I know this fix is counterintuitive, that is why I was a little hesitant at first. Make sure you do everything in your power to fix the inverted axis before trying this remedy. Then you can try this method at your own risk.

Also, concerning the difference between white lights and the supplied green light from the KOP, we are experimenting with different filters for the lense. We have more research to do, but at this point we are looking at using a polarizing filter and a neutral density filter. When we finish our testing, I will post the filter arrangement we find to be best. Good luck!

[Eldarion]

Originally Posted by drinkdhmo

Also, concerning the difference between white lights and the supplied green light from the KOP, we are experimenting with different filters for the lense. We have more research to do, but at this point we are looking at using a polarizing filter and a neutral density filter. When we finish our testing, I will post the filter arrangement we find to be best. Good luck!

You really don't need to bother with that; I've been there and while it works, it is much easier to just do what I described in my earlier post.

When you crank the saturation control register way down, flourescent lights look red, the target looks green, and arc-lights look bluish.

We had to go into the camer code that Kevin supplied and changed the sign bit in tracking.h. otherwise the camera woul look away form the light.

BC

Originally Posted by Smithvillefirst

I am Anthony Peck from team1806 and My camera is not working properly the camera has Inverted Servos and WILL NOT be changed via jumpers, Is it fried?

We are developing code on an EDUbot while our team builds up the base of the robot. We had code from last year that works great with last year's camera. We use TTL to TTL port communications for this prototype. When we replaced the camera with this years model it doesn;t work. It searches but never finds the light. All the information in the T-packet is zero. I checked for the obvious like baud rate. I assume with no jumpers its 115200 baud. I get the impression from the assmbley drawing (the only docs IFI provided this year for the new camera) that the TTL port may be disabled.

As mentioned earlier, last years camera works fine on the prototype.

ANy Clues or do we have a bad camera?

PS we are using Kevin Watson's camera code.

BC

[itsme]

If you're calibrating the camera using the labview CMUcam2 demo file, then try to lessen your tolerance over there, maybe that's the problem.

[JSonntag]

If you are using the labview program that was supplied last year, select there should be an option to load light parameters from an external file. One of the files (there should only be one or two) holds the default color values for the lights supplied by First and will distinguish between green and white light.