I’ve just about had it with the camera. When we first got it we couldn’t get it to power up but that was because we had a faulty backup battery. When we got the new battery the camera would power up but in the terminal window it kept saying “No camera data…”. We played around with it for about a week and decided to change the number of slow loops in tracking.h from the default value of 3, to 10. At first it didn’t work but then the camera magically started working and even tracked the light. I was working on the camera and was changing the search pattern. I built it and loaded it to the rc but the camera stopped working and all that was coming back was “No camera data…” even though the camera was on and the backup battery was charged. I undid my changes and built and downloaded again only to have the same result. So I took a .hex file I had saved to a flash drive that I knew worked and downloaded it to the rc only to have the same result. I came to the conclusion that it was a hardware issue and so I used the serial port diagnostic code to try and find the problem. I jumpered a pwm cable for the loop back test and it came back fine. When I plugged it into the camera it failed to return anything back to the terminal window. The backup battery is charged, the cables are connected properly, the camera’s green LED is on, and it was just working and tracking the light 20 minutes ago. What is wrong with the camera and why does it just mysteriously start working and stop working even when its hooked up properly.
I ran into a similar problem today. Our camera did not move, lights were on, servos were on, switches were on, but no data or tracking. It turned out that when the camera was moved form its bench testing setup to the robot I plugged in the serial cable backwards. Is it possible that this was your problem?
If it isn’t backwards, it may just be loose. I was having some issues with that today, too.
You may want to try running the Debug command found in camera.h if you haven’t already. This way if there is something wrong, such as an abnormal initialization, it will say so in the terminal.
// To view debugging information on the terminal screen, uncomment the
// "#define _DEBUG" line below.
// #define _DEBUG
Also, check the polarity of all your PWMs, and that if you have multiples connected to each other that the connection is secure. (This happened to us as the power light on the camera was coming on, but the camera wasn’t tracking. Upon further examination, we found that one of the pwms connecting the TTL board to the camera had come loose, and a simple fix with a piece of electrical tape solved the problem.)
Nothing is backwards or loose. I went and checked all the connections. The camera was up and tracking then I just hit the program button and it stopped. It started working just as mysteriously as when it started. Everything is connected properly but the terminal keeps saying “No camera data…”. In Kevin Watson’s instructions for the serial port diagnostic code, he said that if the camera test fails then the camera is either defective or the baud rate is wrong. Is it possible the baud rate somehow changed on the camera? If so, how do I change it back.
Thanks for your help you guys. The camera started working again but I cant igure out why. I did use that debug code and it did help. I still have no idea though why it just starts and stops.
-Thanks
I’m on round two of the same problem as reported in this thread.
The camera was originally functioning correctly using a variety of the sample camera code available. One afternoon after playing with labview and the camera it stopped tracking and red light remained on solid after initial power on. Calls to CaptureData() resulted in lengthy delays and then eventual timeout in our code. Labview also would no longer communicate with the camera.
We went through some standard troubleshooting. Power, cables, code, etc. Several hours later without any changes in the sample code nor in our hardware setup, it magically started working again. We had no clue what kicked in, but after the resolution was in place, we would power on the camera and the red indicater would go off until presented with the appropriate green light. CaptureData() would return quickly and all was happy.
The camera was working fine for several days perhaps a week. We implemented and tested our camera tracking code / servo control. Everything was performing correctly. We moved on to start working on other control functionality. However two days ago the same problem materialized again. We’ve not been able to recover from this one yet. Camera appears hung and calling capture data causes the robot controller to freeze for about 1/2 a second.
We hooked up a logic analyzer to the camera mother board rs232 transceiver and have verified the transceiver is receiving signals from our computer and is transfering data to the camera motherboard. The transceiver itself is at least not fried but no telling what the motherboard is doing. The motherboard, however, never responds. No ACK is ever sent. We have verified baud rate, cables, power, multiple times. Everything looks correct. Four of us have now double checked everything we are doing…
The only common thread seems to be that the failure occurs after hooking up and attempting to use labview… That was the last interaction with the camera before the problems were detected in both events.
We are ordering a new camera / motherboard tomorrow. It seems this is a common problem and the camera/motherboard is perhaps a very environmentally sensitive component. At least more than one of us seem to be having problems with stuck / non-responsive cameras. Is anyone else in a dry/arid climate experiencing problems with the camera hanging in this fashion?
Bob Potterveld
We (1094) have also had a problem with the camera just stopping, and in addition, have discovered another issue with it.
We noticed that the camera/tracking software would find the light, the camera would hold steady on the light for about 4-5 seconds and then lose the light. The pan would go to the starting position (same tilt) and start panning and re-aquire the light. It seems the camera would send a confidence of zero, causing the camere to think it has lost the light.
Using Labview to experiment, I removed the camera from the robot, loaded the 2006 Tracking configuration data and noticed something interesting. I was tracking the pixels and I would see the confidence values cycle from about 120-140 range, then go down and report a zero confidence. Neither the camera or the light was moving.
Using the exact same setup, I tested the 2006 camera and the confidence remained steady between 120-140.
Has anyone else witnessed this type of behavior? Is there a camera setting that could be modified (I am using all of the default values from Kevin’s code) that could cause the camera to behave this way. We are working in a warehouse, could cold temps adversely affect the camera?
Is there a warranty period on these cameras?
We are going to continue programming the robot with the 2006 camera to create the necessary alogrithms. Would it be FIRST legal to sustitute the 2006 camera for the 2007?
Any help would be appreciated.
I see exactly this behavior with our 2007 camera.
Our workaround is to change the search pattern so it starts from the “current” position instead of always resetting to the bottom left. The camera still reports that it lost tracking for a moment, but it reacquires the target immediately without taking extra time to go hunting for it.
The only time I’ve seen wacky behavior out of the 2007 camera is when the battery powering my green light discharges to the point where it can’t quite deliver enough power and the color of the light changes slightly. The camera will find the light and track it for a few seconds and then suddenly lose track, start searching, find the light, track it, lose track after a few seconds, …
I’ve also noticed (as others have) that if you don’t press the reset button for several seconds before releasing it, the camera will just sit there with both LEDs on with or without the green light present.
-Kevin
I ran into this once last night (both LEDs on, etc.) while using it with the LabView GUI. Stupid newbie question: which reset button are you referring to? The one on the RC or is the “User Input Switch” next to the power connector on the CMUcam a reset? (I’ve never seen anything refer to this pushbutton for anything)
I’ve held this “User Selection” button down for 10 seconds or more with no effect on the camera. Both led’s remain on solid. I’ve looked through most of the documentation for the camera but have not seen anything which refers to what this button does.
Interesting that you also noticed the hang after using labview with the camera. I wonder what might be going on here? I’ll probably do some more looking at our camera tonight but this remains a real mystery. Perhaps we are damaging the board somehow when plugging in the DB9 for labview use. I’m wondering if some sort of static discharge hit the board when we were plugging and unpluggin in the db9 cable. None of us recall any but who knows. We did look at the specs for the rs232 transciever on the camera and ttl board and it looks to be good enough to withstand a fairly substation static discharge.
Can anyone describe the proper sequence of the 3 lights on the camera board when the camera powers on? Both when connected via rs232 and when unconnected? The last I remember when ours was working it would show the green light on powerup and only show the red led when it was hooked up and actively transfering data through the rs323 port (IE had acquired a target).
Is the sold red light on all the time after powerup an indication of a significant problem on the camera? It seems to be in our camera.
We need a good definition of the proper hard reset of the camera. I’ve seen others refer to running debug code in the camera but if the camera is not responsive at all, is there a hard reset mechanism one can try?
Thanks,
Bob Potterveld
Is there a difference between the 2006 and 2007 camera that would account for the fact that while testing in LabView, with the same battery on the camera, and the same light I would receive two different results. With the 2007 Camera while pointed at the light, I would see the confidence level cycling through a series of numbers including zero, and when I use the 2006 camera, the confidence numbers remain above 120. It is the 2007 camera returning the zero confidence when a) the light hasn’t changed and b) the camera hasn’t moved that concerns me. It seems to be repeating the cycle of numbers in a set pattern (every 4-5 seconds the 0 confidence appears) that it might be an internal setting in the camera that could be causing the issue.
I just realized that I was using last year’s camera last night, not the 2007, so the problem I saw can’t be attributed to the camera version. My money is on ESD causing a latch-up. Even if the hardware can take a zap without damage, you can still get FETs to latch from ESD if the circuits aren’t clamped.
Similar problem. The camara will rind the light and the proper lights come on on the camera, but the camera won’t lock onto the light at all. I tried seeing what values are returned through easyc and printing all variables from the camera to the screen, and found that all values from the camera are consistently at 0.
Anyone have any idea why the camera will only report 0’s?
Thanks.
Well, we’re still not sure, but we had the camera working for a bit and then it didn’t recieve data. We’re checking if it’s working now, but we think that the TTL, which was loose and we hot-glued it, was the problem. It should work, we’re checking it out now.
We solve the problem of the camera
the problem is that the power cable released from his pwm connection and if it happend when the camera is working, it’s cause the problem that the camera stop moving and don’t start again untill reset.
we connect it properly, with some improvisation that won’t make the wire unstable and now the camera work properly.
If you don’t understand post here a replay and ill try to be more specipic with our improvisation. :yikes: :yikes: 
Just to close on this issue for our team. Our new camera arrived a couple of days ago. We determined that the original camera motherboard was fine but the orginal camera/lens was faulty. Whenever we used the old camera/lens plugged into our camera motherboard it would lock up the camera and never respond to serial commands. The green and red LEDs would stay on continuously. When we switched to the new camera/lens assembly the problem would go away and the camera would operate correctly. The serial port was active and would respond. The red LED would only come on when tracking a green light.
Apparently we had a defective camera/lens in the original 2007 kit. According to FIRST we can replace this camera/lens under warranty.
Bob Potterveld