Kevin's CMUcam2 FAQ

CMUcam2 Frequently-Asked-Questions

Q1: AAAHHHhhh! We're spazzing because we can't get the #%*$@&! camera to do anything. What do we do?
A1: Make sure you've done everything on the checklist below. For reference, here is an illustration of the 2007 CMUcam2 and 2005/2006 CMUcam2.

Make sure that when you built the camera, you used the insulating washers between the camera and the aluminum gimbal plate it's mounted to. Once built, visually inspect the assembly to make sure no part of the camera is touching the aluminum.
Plug-in a freshly charged 7.2 volt backup battery into the robot controller. Power for the camera and servo motors are derived from the backup battery, not the main 12 volt battery.
Attach the pan servo to the robot controller's PWM output 1. The CMUcam2's PWM outputs will not work.
Attach the tilt servo to the robot controller's PWM output 2. The CMUcam2's PWM outputs will not work.
The male end of the PWM cable used for power is plugged into the 3- pin female socket next to the CMUcam2's power switch. Make sure the black wire in adjacent to the "B" label printed on the circuit board.
Attach the other end of the camera's power cable to a spare robot controller PWM output. The digital and analog connectors don't provide the correct voltage and will not work.
The male end of the PWM cable used for serial data is plugged into the 3-pin RS232 socket next to the larger DB9 RS232 connector on the camera. Make sure the black wire in adjacent to the "B" label printed on the circuit board.
Attach the female end of the camera's serial data cable to the little rectangular TTL to RS232 converter circuit board included in the kit. Make sure the black wire is adjacent to the "BLK" label printed on the circuit board.
Securely mount the TTL to RS232 converter circuit board to your robot controller's TTL serial port. It should look like this photo.
Make sure that nothing is attached to the CMUcam2's DB9 RS232 serial port. You cannot use both ports at once.
Tether the robot controller to the operator interface using the provided red serial cable.
Take the lens cap off.
Make sure the CMUcam2's power switch is in the on position.
For bonus points, use the CMUcam2 GUI to focus your lens.

Q2: We managed to build the green light without sending anyone to the emergency room. Do we need to calibrate the camera before using it?
A2: No, in most cases you should be able to load the pre-compiled camera.hex file from camera.zip or camera_s.zip into your robot controller and your camera should automatically find and track the green light.

Q3: All we see on the terminal screen is Searching... Searching... Searching...
A3: Did you modify the default calibration? If so, see question two.

Q4: Where do we plug in the pan and tilt servos?
A4: By default the pan servo is attached to the robot controller's PWM 1 output and the tilt servo is plugged into the the robot controller's PWM 2 output. These assignments can be changed in tracking.h.

Q5: Does your software expect color calibration data in RGB or YCrCb color space?
A5: YCrCb.

Q6: Okay, if the default mode is YCrCb, where do I enter the calibration parameters?
A6: The code adheres to the protocol established by CMU's documentation where Cr maps to red, Cb maps to blue, and Y maps to green. So, your minimum Cr calibration parameter is entered into camera.h on the #define R_MIN_DEFAULT line, maximum Y calibration parameter on the #define G_MAX_DEFAULT line, etc. Of course, these changes can also be made using the camera menu.

Q7: How do I get the camera to use RGB color space?
A7: As far as I can tell, it's as easy as changing the value in camera.h, line #define COMA_DEFAULT from 32 to 40. Of course, these changes can also be made using the camera menu.

Q8: Were do we find documentation for the camera registers (COMA, COMB, COMI, etc)?
A8: These are documented in the OV7620 camera module data sheet, which can be found here: http://kevin.org/frc.

Q9: We've built the camera and tried it with your software, but when the camera detects the green light it quickly rotates away from it. It's almost like it doesn't want to see the green light.
A9: This is probably because you diligently followed the instructions and mounted the camera upside-down. The optimum orientation for the camera is for the tilt axis to extend through the camera module. Rotate the camera within the mount so that the power switch is down. If you're too lazy to do this, or you did mount it correctly, but one of the freshmen messed-up the settings, just flip the signs of the #define PAN_ROTATION_SIGN_DEFAULT and #define TILT_ROTATION_SIGN_DEFAULT values in tracking.h or through the tracking menu.

Q10: We're using the "bells and whistles" version of your code. How do we know where the software is getting the camera and tracking configuration parameters?
A10: You can see where the software gets the configuration data by enabling debug messages in camera.h. With debug messages enabled, the next time the camera software initializes, you'll see some diagnostic information on your terminal as it boots.

Q11: How does the software determine where to get the configuration data?
A11: If the software finds a valid camera and/or tracking configuration in EEPROM it will use that information for configuration. If the EEPROM data is corrupted or missing, values from camera.h and/or tracking.h will be used. To save values from the header file into EEPROM, select load default values from the menu and then hit the save changes key.

Q12: Is there a way to clear the EEPROM of configuration data?
A12: Yes, download frc_eeprom.zip and use the included eeprom_wipe.hex file to clear your EEPROM.

Q14: When the camera is searching, it momentarily sees the green light (the red LED on the camera turns on), but the camera doesn't lock on to the target and continues to search. What gives?
A14: If you're using the "bells and whistles" version of the code, enter the tracking menu and adjust the search delay up by one, which will slow down the search and give the camera more time to let the RC know that it found the green light. Don't forget to save the new value to EEPROM when you get it dialed in. For the streamlined code, open tracking.h and look for #define SEARCH_DELAY_DEFAULT and increase the number to the right of it by one, compile the code and try it out. Repeat if necessary.

Q15: We're sure we've got the camera hooked-up correctly, but it doesn't do anything. What do we do?
A15: Enable debugging messages in the camera code by following the embedded instructions in camera.h and run the camera code. If you don't get any debugging information sent to your terminal screen when the code executes, there is a problem with your robot controller or the USB to RS232 converter you may have used to load the code into the robot controller. Call the InnovationFIRST support line at (903) 453-0802. If you get a message that says "Camera: Initialized abnormally with code 131", this means that the serial communications link to the camera isn't working properly. In this case, download the serial port diagnostics software from http://kevin.org/frc and follow the included instructions.

Q16: I ran the serial port diagnostics, but nothing gets echoed back to the terminal. What does this mean?
A16: This indicates that your TTL-RS232 converter board, PWM cable, or the TTL serial port itself is messed-up. To discount the TTL serial port as the source of your problem, remove the converter board from the TTL serial port and short the RX and TX pins with a piece of wire, jumper block etc. Use this illustration to identify the RX and TX pins. Once you've done that, reload the serial port diagnostics and perform test one, the loop back test. If you get characters echoed back to the terminal, your problem is either the converter board or your cable. Remove the jumper and plug the converter board back in and short the two upper pins that connect to the red and white wires. Perform the loop back test again. Do you get the characters echoed? If not, your converter board is toast. If you do get echo, your PWM cable is bad.

Q17: Will the "bells and whistles" camera code run on the nifty EDU-RC?
A17: Yes, in fact the code was developed on a EDU-RC. Here's a link to the EDU-RC version: http://kevin.org/frc/edu_camera.zip.

Q18: We're running the camera code on a EDU-RC, but there doesn't seem to be any communication between the camera and the EDU-RC programming port. Any ideas?
A18: Yes, You need to use a null modem cable as opposed to a straight through cable.

Q19: Once the camera locks onto the green light, it slowly oscillates. Is it spastic?
A19: No, it's not spastic. If you're using the "bells and whistles" version of the code, enter the tracking menu and, depending on which servo is oscillating, adjust the pan or tilt gain up by one, which will help dampen the oscillation. Don't forget to save the new value to EEPROM when you get it dialed in. For the streamlined code, open tracking.h and look for #define PAN_GAIN_DEFAULT and #define TILT_GAIN_DEFAULT and increase the number to the right of one or both by one, compile the code and try it out. Repeat if necessary.

Q20: Well, the camera tracks really well except the pan and tilt servos start twitching when the 'bot moves.
A20: If you're using encoders, a gyro, or anything else that generates a lot of interrupts, it's best to avoid using PWM outputs 13 through 16 because their outputs can have quite a bit of jitter when lots of interrupts are firing-off in the background. Try moving the pan and tilt servos to PWM outputs lower than 13. Update: This problem only applies if you're using Generate_Pwms() to generate the PWM pulses. Download and install the code in frc_pwm.zip to correct this problem. Here's a link: http://kevin.org/frc/frc_pwm.zip.

Q21: Well, we read question 19 and 20, but our camera is REALLY spastic and adjusting the gain(s) had no effect and we're not using PWMs 13 through 16. Got any clues as to what else can cause this?
A21: Make sure that your code isn't also changing the PWM outputs assigned to the pan and tilt servos. IFI's default code also uses PMW output one and two, so make sure you re-assign them to another output.

Q22: Why isn't there a question thirteen?
A22: When was the last time you got the correct answer on question thirteen of a test? That's right, it's bad luck to have a thirteenth question and I didn't want to give you the wrong answer.

Q23: We loaded the IFI default code and the joysticks controlled the motors just fine, but when we load the camera code the motors stopped working. What gives?
A23: For safety reasons, the call to Default_Routine( ) in Process_Data_From_Master_uP is commented out. If you want to use the Default_Routine( ) you'll need to call it after Getdata(&rxdata), but before Putdata(&txdata). As noted in question nineteen above, you'll also need to re-assign PWM channels one and two because Default_Routine( ) also uses them.

Q24: Well, we started with your gyro code and added the camera and encoder code to the project, and everything works fine, but we don't seem to be able to communicate with the camera. We can load the camera.hex file from frc_camera.zip and the camera works just fine. We've read all the FAQ entries, but none of them apply to us. Our programmer has given up and is currently in a catatonic state over in the corner of the room. Please help us.
A24: A common problem that teams have when they don't start with the camera code is they forget to change the serial port baud rate from it's default 9600 baud to the 115,200 baud the camera expects. Open up serial_ports.c and change the baud rate in Init_Serial_Port_Two( ) from BAUD_9600 to BAUD_115200. Also change the BRGH bit to a 1. Sorry, I'm not sure what to do about your programmer.

Q25: We noticed that you show how to convert PWM units to degrees in terminal.c, but the comments are a little light in explaining how this works.
A25: The first part of the equation, PAN_SERVO - 124, converts the pan PWM value to a signed value where positive PWM values are on one side of the zero point(124) and negative PWM values are on the other side. The second part, * 65/124, converts PWM angular units to degrees. I measured a rotation of 65 degrees when I commanded the servo to rotate from 0 to 124 in PWM units, which means for every PWM unit increase, the servo rotates 65/124 degrees. Because I'm using integer arithmetic, I use the parentheses to tell the compiler the order I want the operations to take place to prevent over/underflow of the variable and maximize precision.

Q26: We'd like to use the Virtual_Window( ) function, but don't know how the image is oriented.
A26: If you've mounted the camera in the orientation I suggested, with the power switch down, the image is upside down with pixel 1,1 located in the lower right corner. If you mounted the camera per the manual, with the power switch up, the image is right side up with pixel 1,1 in the upper left corner. More information can be found in the command dictionary under the VW command.

Q27: What happened to the PWM headers on the 2007 CMUcam2?
A27: The servo PWM headers went away because the microcontroller used on the 2005/2006 CMUcam2, the Ubicom SX52, is no longer available and IFI was forced to transition to the SX48, which has fewer I/O pins. As it doesn't make sense to use the on-board PWM outputs for our application anyway, they were removed to aid in the transition to the SX48.

Q28: Why do we have to use a PWM header for camera power when the digital I/O and analog input headers seem to work just fine.
A28:The camera must be powered from a 7.2 volt RC PWM header. Using power from any other header, which supply 5 volts, won't work because the camera has its own voltage regulator which needs an input voltage greater than 5 volts to function reliably.

Q29: I sent you an e-mail and you didn't bother to reply. Why?
A29: I've written a heuristic Bayesian e-mail filter that immediately disposes of e-mail containing questions covered above, in the Chief-Delphi forums, FIRST or InnovationFIRST-provided documentation, or in the various readme files included with the software. The filter is also trained to dump any e-mail that includes any hax0r l33t-speak. If you've searched through the above resources and haven't gotten a reply in the Chief-Delphi forums then go ahead and send me an e-mail with your question.