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.
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.
Last Update: January 20, 2007 at
1:32 PM PST
Copyright ©2006-2007 R. Kevin Watson