I probably would’ve asked this earlier, but I just followed the diagrams and instructions blindly last year.
I’ve searched and can’t find any relevant threads, so here’s my question.
After reading over the CMUcam documentation, I see that the camera board has a TTL port. I remembered this from the RC, so I read the docs for it, and sure enough, we have a TTL port there. So, I have to know, why do we use a TTL to RS-232 converter? Is it a matter of convenience (3 wires to run instead of four)? I’ll keep using the converter, but I just found this curious.
Weird things happen when you read the manual… :ahh: you might actually think!
JBot
EDIT: Also, why are auto white balance and auto gain on by default? They must mess with RGB thresholds. Does FIRST measure the color thresholds with the auto settings on? If so, how can I be sure they are reliable? I had a vapor light above our test field bleach the light white. How can I be so sure this won’t happen at a competition?
When the camera first appeared in 2005, I wanted to use the TTL capability of the camera. Unfortunately, when I inspected the camera back then, it appeared that the jumper on the original CMUcam2 design which allowed you to switch from RS232 levels to TTL was omitted, making it impossible to use the TTL port. I didn’t check to see if this was fixed on the 2006 version of the camera but I don’t believe it was.
A good reason to use RS232 levels over TTL is noise immunity. Using RS232 levels will give you better noise immunity which could be important when running with all those noisy motors all over a robot. That being said, we’ve used TTL serial for things on our robot in the past and have never had a problem.
Also, regardless of which method you use, you only need 3 wires. The fourth wire on the TTL serial port is +5v which doesn’t need to be connected (assuming your camera is already getting power from the PWM port).
Okay. That’s good to know–we were having problems with the TTL converter staying in and making good contact, and I just wanted to know if I could use it without the converter.
You say a jumper was omitted, but I am looking at the CMUcam manual and I don’t see anything about a jumper to change to TTL levels. I just assumed that the TTL levels would come out of the TTL port and RS232 levels would come out of the other port. Am I missing something?
The TTL port on the CMUCAM2, both 2005 & 2006 KOP releases, works just fine. No jumper is required, but you can only have one of the three CMUCAM serial ports hooked up at any one time. Even loose wires connected to a TTL port, for example, will make that port look active and the CMUCAM2 board will get too confused to communicate properly.
You just have to make a special 4-pin connector that avoids the +5v pin on the CMUCAM TTL port and gets the Rx/Tx in the right order.
The TTL port got better coverage in the Vex forum: http://www.chiefdelphi.com/forums/showthread.php?p=507128&postcount=7
Just modify the Vex controller side of the discussion to reflect the TTL pins on the FRC.
I’ll echo Dave’s comments on TTL & noise, actually any PWM cable and strong electrical fields. I’d suggest using shielded cable for TTL or any communication, but in any case monitor your final solution looking for susceptibility to noise especially if the cable is routed anywhere near magnetic fields such as those around the CIMs or alongside power lines.
We communicate with the CMUCAM via it’s TTL port on our 2006 FRC robot, and we use the 2005 KOP CMUCAM (TTL port) on a Vex demonstrator robot. Several other teams I know also communicated through the direct TTL connection.
P.S. This thread would be more useful in the CMUCAM sub-forum.
I’ll admit I never tried it myself. The original CMUcam2 design included a “serial bypass” jumper which I believe was used to disconnect the RX line from the MAX232 chip (so that the MAX232 would not be driving the pin in conflict with the TTL port). I didn’t see this jumper on the IFI version of the CMUcam2 so I figured it was omitted, but perhaps the RS232 chip they used tri-states without valid input. I planned on sticking with RS232 levels anyway so I didn’t worry too much about it. Good to hear that it works though.
I’ll echo Dave’s comments on TTL & noise, actually any PWM cable and strong electrical fields. I’d suggest using shielded cable for TTL or any communication, but in any case monitor your final solution looking for susceptibility to noise especially if the cable is routed anywhere near magnetic fields such as those around the CIMs or alongside power lines.
As an interesting note about noise, we actually have the opposite problem on our 2006 robot: the serial communications lines are run (unshielded) right next to some PWM wires, and when the robot is disabled (which tri-states the PWM outputs) the noise from the RS232 communications causes the servos which control the tilt on our camera to twitch. It causes the case of our camera to bang into the frame of our robot and sounds like a woodpecker ;). We decided it wasn’t enough of an issue to justify re-running shielded wire but it gets annoying when the robot is disabled for any length of time!
Team 40 used direct TTL to TTL cables on the 2006 robot. We also held a camera workshop with ten teams. We gave each team a TTL to TTL cable and every team got the camera working. Also , this runs the camera off the 12v supply instead of the backup battery.
The only problem is if you want to run the JAVA APP or NI you have to disconnect the RX port from the camera or it won’t communicate with
the DB-9 rs-232.
