AAH I'm spazzing out because I can't get our camera to do anything!!!

Sorry about the general thread title; it’s meant as a joke–that’s one of the questions in Kevin’s FAQ.

But this one’s different. I’ve got a bit of a puzzle here.

I use Kevin Watson’s default camera code, and it works like a charm. I use my modified code, and it…doesn’t. It "error 131"s over and over again.

I spliced an RS232 connector onto a PWM cable to test my TTL converter, camera, and cables in between. All of my hardware works great. I receive “CR>” and some odd character in my terminal window when connected from the TTL converter out to my com port. I get the same thing on the very end of the PWM cable I had plugged into the camera. I can talk to the camera through this port too, but only if I switch TX and RX. I’m too brain-fried to think that through; don’t read too much into it because I could be wrong. The camera responds like I think it should.

My code is receiving the bytes I send it. I put a simple printf of the byte count every loop and saw it change when I sent it bytes.

Kevin’s serial port diagnostics indicate that communication from and to the computer and from and to the camera are all good.

I am not getting any bytes back from the camera itself, however. My byte counter never lifts off 0.

I would post my code, but I have some confidential stuff in there–I’d have to strip it to make it neutral before I post it.

So, any ideas? Do you really need to see my code (I think you probably will ask for this, I’ll post it tomorrow if you do)?

Thank you so much.


Figured this out myself today. The serial_ports.h by default has the TTL port set at 9600 baud; the camera expects 115200. I haven’t tested with the robot yet, but I’m sure this is my problem.

Thanks, Kevin Watson’s FAQ!


Your quote from Kevin’s website hit close to home! Our team really can’t get the camera to do anything! It doesn’t lock onto the target…

We’ve been using Kevin Watson’s Bells and Whistles code (though I also tested the Streamlined code). We have the pan/tilt servos connected to PWM01 and PWM02. We have the power connected to another PWM output, and we have the TTL cable connected between CMUCam and RC. We see the output “searching… searching… searching…” We’ve read Kevin’s FAQ (#3) on this symptom, but we didn’t modify his camera settings or calibrate; we don’t think that’s the problem. We tried increasing the search delay by one, as Kevin suggests (FAQ #14). We have our camera mounted such that the lens is in the bottom half of the camera.

Does anyone have any ideas? Did you do any configuration to the camera or the code to get things working? We’ve learned a lot in the process of all our debugging, but we haven’t gotten beyond “searching… searching… searching…”

Thanks for any suggestions you may have to offer!

Does the camera actually search for the light, i.e. do the servos move? Or does it just print “Searching…”?

Also, does the red LED on the camera light up when you put the green target light in front of it?

Good luck,

Yes, the pan and tilt servoes have worked all along-- I forgot to mention that in my earlier post.

The camera’s red light blinks constantly as the camera searches… but it **does **seem to be on when the green lightbox is in the camera’s field of view.

New development today: the camera reported pan angle, tilt angle, blob size, confidence for the instant that the light box is in the camera’s field of view. Then, it changes direction and keeps searching. This sounds like Kevin’s FAQ #9, but our camera power switch is on the bottom. I tried switching the signs on the PAN_ROTATION_SIGN_DEFAULT and the TILT_ROTATION_SIGN_DEFAULT. I also slowed increased SEARCH_DELAY_DEFAULT by one.

If anyone has any other suggestions, I’d be grateful to have them!

I’ve seen this wacky behavior when the light isn’t getting enough power; the camera will find the light and start to track, but after a second or so, the camera will start a new search. Use a freshly charged robot battery to power the light (not some ~12 volt wall-wart left over from a toy your little brother destroyed long ago). Also consider modifying the search algorithm to better meet your needs.


Hey! We’re tracking now! Thanks, gnirts and Kevin!

Wiring the green light box to a freshly charged 12 Volt battery definitely helped!


It looks like the red LED blinks even when the green target is not in view, but tracking works… :yikes:

Hi, I’m having a problem that would occur earlier than the problem you just had. I can’t get the servos on my camera to function at all. They moved for a second the first time I plugged it into the RC and a green light (i think it was green) came on. Then I downloaded the most recent version of my code and forever more the camera would not turn on. My servos are mapped to PAN_SERVO pwm06 and TILT_SERVO pwm07, and in the default routine() I commented out the joystick mappings for those servos. I also commented those servos out in the User_Initialization() when the pwm’s are all set to 127. So, Why is my camera not working? (I read somwhere that it has to be mounted upside down? With the camera and the power button on the bottom of the tilt? That shouldn’t affect this though.)

Not to threadjack, but just out of curiosity, will the power supplied from a digital/analog input (supposed to be 5 volts) be sufficient to reliably power the camera? I have been using it, and maybe 1 out of 20 power-ups the initialization fails and I have to power-cycle, but you say 12 volts; I can have our electrical team wire another circuit breaker and run 12v out to the camera if you think it would be better.

Just wanted someone else’s opinion…


He is talking about using 12V to power the target light, not the camera. You should use 7.2V to power the camera, which you can pull from a PWM port. I wrote about this issue at length here.

We’re having problems with our camera also. The story is that the camera worked, then it didn’t. While the robot was being driven for practice it started working again and worked well. To our dismay, it stoped working again. We (not me, I’m not our tech person) have done all the troubleshooting that we can think of. I’m thinking it might be some kind of firmware issue although I’m told that it probably isn’t. Oh… By the way… this is our third camera for the third year running that has, to the best of our knowledge, been hosed. Luckly We’ve not needed it untill this year, depending on how you judge luck. We’re in desperate need of help and would be eternally grateful.

The servos should drive the camera frame to scan its field of view even when the green light is not on. Hm… Does your Process_Data_from_Master() function still call Camera_Handler() and Servo_Track()?

Also, do you have your joysticks plugged in as you test the camera? The default routine makes calls to the joysticks, even if you’re not planning to drive while testing the camera.

I don’t think you need to comment out any pwm initialization code in User_Initialization(), as the Main() function only calls User_Initialization() once.

Hey, I prefer banging my head on the wall to spazzing out, and I’ve been doing it all today… and yesterday… and the day before…

I’m not sure why, but the Kevin’s camera project wont compile, error in streamlined version: plcxxx.h not found even though it should be auto included, and in bells version: stdio.h not found even though it should be auto included). The pre-compiled hex file works perfectly enough, so this might be a problem with our compiler… With only one week left it gets kind of frustrating, but the answer is here somewhere… somewhere…

Go to Projects -> Build Options… -> Project -> General tab. Make sure the last three paths are correct. Your paths may be different, but on my laptop, the include path is c:\mcc18\h, library is c:\mcc18\lib, and linker scripts is c:\mcc18\lkr.


We were perplexed a couple of times when our camera stopped, even though its lights were still on. Replacing the backup battery with a fresh one did the trick for us.


Our camera is working, but we are having trouble driving towards the light. First of all, it drives intermittently with a jerky motion. Secondly, it turns in the right direction only from one side, and then it keeps turning. If we reverse the signs, it does the opposite. Our code looks something like this

if camera is on target {
calculate error based on tilt servo
left side = speed + error
right side = speed - error
} else {
turn motors off

You’re trying to turn the robot to one side or the other based on the tilt servo? Unless you have your camera mounted sideways, I’d have expected the pan servo to be more applicable.

Oops, I meant to write “pan servo”. (btw, the first time we wrote the code we did put tilt servo, and it took a bit of head scratching before we noticed).

Any other ideas?

My error calc looks like this
error = (PAN_SERVO - 127) / gain;

where I have tried 1 and 2 for gain. I also limit the error between -20 and 20.


I’m also having trouble with my camera. Actually it doesn’t even track the light properly. It locked onto the light once, but most times it cant track the light. Its tilt min is 94, max is 194 (center is 144), at 50 step intervals. Pan is 0 to 248 at 62 step intervals (center at 124). The camera doesn’t really see the light (by the way Im using Kevin’s default Streaming code).

Do the servos go through the search pattern? If so, make sure your batteries are fresh, especially the backup battery and the battery powering the light. See what happens if you turn the room lights down or off. Make sure you have the camera mounted with the tilt axis pointing through the lens (i.e. upside down from the assembly instructions). The default color configuration works fine, so don’t change it.