We’re experimenting with the CMUCam and have everything hooked up. There are no problems other than that the image recieved by the GUI app is completely messed up. We have gotten it to show the basic shape of an opject held in front of it, but no real image like that in the getting started guide. Any ideas?
sorry to say, but ours works fine, really good quality too, i suggest that you report that your cam is defective ASAP.
don’t mess with it, just tell them it’s not in working condition, and ask for a replacement (also i think it’s obvious that you should mention that you are not responsible for the fault!)
-Leav
oooh! I had this same problem, check the baud rate and stuff on your serial port, go into the device manager and find the entry for com devices, then right click on the com port and go to properties, then under I think the second tab (sorry, not on my windows machine atm), make sure those setting correspond with the ones they give you on like the third page of the start here manual. this fixed my problems, the com port defaults are probably NOT what CMU cam requires
I thought I had tried this, but hearing the same problem from someone else — I’m trying again. Thanks.
From the troubleshooting part of the manual:
I get wavy lines or a distorted black and white image when I call
dumpframe:
This is most likely due to power. Make sure that you have a high enough voltage
and that you are getting a clean signal. Running the camera off of fresh batteries
not an AC adaptor) is a good way to test if this is the problem.
I don’t know if that helps. I havent been able to get our teams camera up and running yet.
Ours is working fine, but we cannot connect when it is also connected to the robot, so make sure something like this is not happening. Also, as mentioned before, check all power cables and make sure your baud rate is set right. If you have one, try testing the camera through a usb-serial adapter. While I have had problems with these when programming the robot before, we used another team members laptop equipped with an adapter today for the GUI, and it worked fine (although it was not COM1, rather COM4 but this probably varies). If this way of communication works, you will know that your standard serial connection is malfunctioning or not set properly.
Ah yes, I also changed the battery, both of which may help. Run a volt meter to it and make sure the battery is giving you at least 7 volts. (The backup battery of course)
We weren’t having quite the same image problem but our images were very hard to distinguish.
We found that you can change the camera resolution to high if you go to the config tab in the software. I hope that helps.
From what I can tell, the CMU cam software is really cobbled together, I am hoping we can get the source, and try to fix it.
when my teammates and I hooked the camera up for the first time, everything worked, but the image was really blurry. we found out that the camera has a manual focus, as in you just twist the camera lens. I don’t know what kind of object you’re trying to “see” there, however, and with those lines there I’m not really sure that this will help at all. but, if you run out of options, you can try to change it and see if it helps.
You recieved it when you downloaded CMUcam2GUI.zip in the src subdirectory.
I have not had any problems with it as long as you stop one task before starting another…
exactly the most annoying part! plus, if you press stop twice, it will crash.
I think this is one of those times where an open source advocate somewhere mutters “Well, you’ve got the source…”
Seriously, though, if the double-press issue (or any other GUI glitch) is giving you a hassle, it shouldn’t be too hard to fix. As a hack, you could probably throw a little finite state machine into the GUI interface software that either hides or ignores the stop button if the system is not in a state where stopping makes sense.
As a student at CMU, I wish I could say “That bug shouldn’t be there,” but I’ve worked on too many projects like this to say that with a straight face :D. Not having been involved with the CMUCam project, my guess would be that it sounds like the hardware people assumed the software people wouldn’t do something “obviously incorrect,” and the software people assumed the hardware people wouldn’t allow the camera to choke on “meaningless but well-formed input.” Control system design teams, take note: there’s a lesson here… 
As for me personally, given that the CMU cam is pretty awesome, and has the distinct advantage over other solutions of existing right now, I’m willing to forgive the design team for missing the “totally awesome” mark. If anyone decides to tidy up the software, share the fixes with the rest of us!
Best of luck to everyone,
Mark
if i get around to it, and if i understand the code, and if i learn how to execute java code, i promise to share the results with the community
:rolleyes:
We still have yet to experience problems with the camera, aside from the fact that our color recognition is tenuous at best. And from what I’ve been seeing, we’re not the only ones experiencing this problem. At least we still have decent motion detection, once you increase the threshold. We still haven’t looked at the robot code implementing the camera yet, so we have no idea how that will run.
A lot of replies!
I just got home from today’s meeting, and am happy to say that the cam now works. We tried a different computer. We thought that it was some kind of unknown fix, but after reading this thread the real problem is clear: battery! We had been using a backup battery with an unknown charge state, but we charged it today during school. Now we can take horribly-colored photos of everyone on the team (only in bad light)!
I’m still not a programmer, so I can’t help with software improvements, but good luck to everyone else. Thanks for your replies.
Sidney,
The picture you show is a classic example of a camera that has been dropped. If you try all of the suggestions above and still have the problem, I would suspect the the CCD has been damaged or the connections have moved due to an impact with a hard surface. Check (with power off please) that the camera is seated properly on the mother board and no pins are bent in any of the connectors. The picture is an indication that there is no sync between the pickup pixels and the output. Does the image change with objects moving in front of the lens? If it does than I would suspect the camera.
Thanks for your suggestion, Al, but I posted yesterday that the problem was fixed by charging the backup battery. We were beginning to think it was the CCD, but thankfully the issue wasn’t that permanent.
where do I find the manual for the CMUcam, the one that tells me how to hook it up to my computer. and what am I reading about a battery needed to run it?
Ryan, the manual can be found here. The manual is in the “getting started” zip file.
Dan